Proposal for a Link Management System for Alfresco WCM

Here's my proposal draft description thing of a possible Link Management System for Alfresco WCM:

--------------------------------------

Link Management System

The WCM should provide away to manage intra-site links.  If an HTML document within a managed site contains a link to another document within the site, the WCM should take care of this, not the content author.  If a document is moved within the site or renamed, any links to it should be updated automatically. 

This may represent a large shift in the way the Alfresco WCM product is implemented, or it may be just a module which could be easily turned on or off. 

The following is a sketch of how this might work.  Keep in mind that this is not the only way to accomplish this goal, and that details may be slightly or even wildly inaccurate. 

---

The WCM needs to maintain a set of Link Objects.  Each Link would contain the following properties:
        name: a unique human-readable name by which this Link can be identified.
        target: the target document of this resource, if the resource is an intra-site document managed by the WCM, or null, if it is an external document not managed by the WCM.
        url: the location of the resource
        title: the title of the document at the URL
        dependencies: a list of documents managed by the WCM which refer to this Link.

Sometimes Links will be created automatically.  For example, whenever a new document is created in the WCM, it will generate an associated Link (with the document as its target property).  The properties of this Link are also maintained automatically.  If the document is renamed or moved, this would trigger a change in the Link's url.  If the document is retitled, this would trigger a change in the Link's title. 

There will also be a Link creation user interface, which is accessible during content authoring.  If a user wants to refer to an intra-site document which has not yet been created, this UI will collect the required information and would create both the Link and the target document.  Also, if the user wants to refer to an external document (that is, link.target == null), the UI will collect the required information and would create just the Link object.

---

Documents managed by the WCM may refer to Links within their content.  The files stored in a managed website are not necessarily the exact files to be previewed or published.  They may be blueprints from which the published files are built.  This could be accomplished by allowing all managed documents to be stored as, say, Freemarker templates, which may assume that appropriate Link variables exist:

For example, the document "something.html" would be stored with embedded FTL tags:
       To find out more about our products, see <a href='${links["Products"].url}'>${links["Products"].title}</a>.

The exact methods of doing the templating could be hidden from the content author, who instead is presented with a editor UI allowing the selection of or creation of Links.  If the content author selects an existing Link, the underlying template document would include the necessary markup, but the content author would not need to know about it.  If the content author creates a new Link, the WCM would additionally create an associated target document if one is required.  The content author should be allowed but not required to be involved in the details of the templating.

---

Documents declared to be templates in this way would then need to be transformed into their final static form by the WCM prior to previewing or publishing.  Continuing with the Freemarker example, this transformation would generate the corresponding html file:

     To find out more about our products, see <a href='http://oursite.com/store/products.html'>Oursite's Products</a>.

This transformation step could be triggered by preview or publish, in which case Link dependencies may not need to be maintained.  Only at preview/publish time would the Links actually be resolved.  This is the easiest way to maintain consistency, but may cause previewing and publishing to be slow.

Or, transformation could be triggered immediately upon document creation, which would presumably add the document to the dependency lists of the referenced Links.  When any of a document's referenced Links are subsequently updated, the document would be re-transformed.  This pushes the load onto document creation.  Publishing is quick, but Link updates are slow.

A third, hybrid option is where the transform takes place upon document creation, and updating a Link would only cause all the dependencies to be -marked- for future retransformation.  This future retransformation could happen during spare cycles or, at the latest, upon preview/publish.

---

That is a rough sketch of a Link Management System.  Some of the details seem well-suited to Alfresco's framework.  The event triggering mentioned could be implemented via workflow.  The Link objects themselves would probably reside in the repository as either separate objects or as aspects of documents.  The transformation and all-documents-are-templates components may be more of a hassle to implement as a module. 

---