Document Aliases

Last modified by Vincent Massol on 2024/02/26 17:57

 XWiki
 Feature
 Idea
 

Description

  • UC1: Be able to have more than 1 Entity Reference for a Document
  • UC2: Be able to not break an existing bookmark when renaming a Document
  • UC3: Be able to have a short URL for a Document, for SEO reasons (for example). This is being made more important since Nested Documents might generate long URLs
  • UC4: Be able to relocate pages in XWiki without breaking code using a reference to the old location

Also note that Document Aliases is a feature that we wanted to have in the Model v2.

Database Level

  • Add a alias (or link) column in xwikidocs table for storing the Reference to another Document. When this field is left empty, it means the Document is a Standard Document but when filled it means the Document is an alias to another Document and its content and metadata should not be used. When loading it from the DB, it should actually be the linked Document that is loaded and returned.
  • From a Performance POV, loading a Document though an alias will cost a bit more since it means loading a first Document (almost empty though so should load fast) and then loading the target Document. However, once loaded it'll be put in the Document cache. Maybe there's a way to still do this in a single DB query with some inner query.

API Level

  • A new XWikiDocument.setAlias(DocumentReference) (and Document.setAlias(DocumentReference) or Document.setAlias(String) should be added
  • (optional) Provide a new Query Filter to filter out Documents which are linked to other Documents. Note that in the default Index (AllDocs), I think we should list all the Documents, including aliases.

UI Level

Several ideas:

  • Idea 1: More Actions > Manage Aliases... and then screen which allows to add, edit and remove aliases
  • Idea 2: A new Aliases Tab in docextra (next to Comments, Attachment, History and Information) to list existing aliases but also to be able to edit and delete existing ones. Or reuse the Information tab (with a UIX)
  • Idea 3: Use the existing Rename and Delete menu actions to rename and delete aliases (viewing an alias document renders the Document pointed to and doesn't redirect). When clicking Edit on an alias, we would have a message saying that it's an alias with a link to the aliased Document for editing it. And/Or simply edit the target document and when saving, save the target document and not the alias doc.

Note that Idea 3 is interesting because it requires only a very minor change to the UI.

Notes

  • UC2 & UC3 could be implemented at the URL level only but UC1 & UC4 require it at the store level.
  • Having another Table for storing Document References (i.e separate them from the xwikidocs table) and having unique ids for Documents would cause performance problems with Hibernate since we would need to always have 2 queries when loading a doc: one query to find the Document id from a Document Reference and another query to load the Document from its id.
  • This doesn't preclude also having the ability to set up URL redirects. For example use the URL Rewrite Filter and write a generic Class Rule that would find Rewrite definitions in XObjects.
  • HQL Executor would also need to be modified to support aliases so that we don't need to change existing XWQL/HQL queries
  • What about the SOLR QL?
  • Maybe it's enough to support load/save operations on an alias doc (load would load the target doc and save would save the target doc). And for queries (HQL, XWQL, SOLRQL) the user would need to query the target document and not the alias one. Most, if not all, extensions would either point directly at a given doc (like some config doc) or when doing a query would search for an xobject and the location wouldn't matter. This is not fully true since the query could search for docs having a given xobject type but inside a given space... (and this space could have been moved and aliased)...
  • The only solution I can think of so far is to have one or more table containing the list of document and space aliases (maybe even wiki aliases), i.e. not use what's suggested above by reusing the xwikidocs table, and load them in memory for high performance, and use that in the Store code (for load/save) + in the query implementations (e.g. the SOLRQL & HQL parsing code would check if an alias exist for doc and spaces and swap them for the target if they are aliases).
    • This has the additional advantage to not have to modify any UI to exclude aliases, which would be a PITA.

 


Tags:
    

Get Connected