All kinds of links... how to manage?

[leviter]

In website we usually build there are all kinds of links:

- normal hyperlinks
- inline links
- crosslinks (links to other content pages)

How would you implement this for the website with Alfresco so that the links are manageable within Alfresco? A content editor should be able to create, place, edit and remove these links in the site with the Alfresco content management system.

Is this at all possible?

[kvc]

Yes, all possible.

Links are a form of reference.  It's important we distinguish the two, because we generally speaking support references - which is unique to Alfresco - and links as well.

By references, I mean that a sandbox is a true virtual file-system, with support for files and directories.  In a sandbox, you can use any dev tools and create any reference - a link, an include, an import statement, you name it - and when you store and preview the asset in Alfresco - everything just works.  This is good for site migration (you don't need to rewrite anything) to put things immediately under version control and workflow and great for building dynamic sites (for scripts, etc.).

When not using a dev tool against our CIFS interface - basically, when creating structured content using our forms - you can create references using our file browser control (datatype anyURI).  This can work to capture standalone references within your example (a list of related document links) or with our upcoming 2.0.1 maintenance release this March withing TinyMCE (for in-line linking).   Now, because we support references in a generic sense, the nice thing here is that these are all normal URls - human readable, generated by you when you created the underlying resource that's being referenced. 

Now, given that we provide this flexibility of supporting any directory structure, any arbitrarily existing or created reference using any tool with real paths that everyday sites and apps expect, the problem is this:  we allow you to delete, move, rename files and directories and actuall VERSION those changes and snapshot different states of your overall source tree.  This is important for audit trails, rollback, and recovery (not to mention ongoing development of long-lead projects, potentially in parallel, where you want to checkpoint work).  But this means that paths can change, and then references are invalid.  What to do?

There are many ways to handle this - one way to output links that are
actually fixed referenced that can be resolved at runtime to a path (basically what other systems do by using an objid, which is one type of fixed reference, which more generally should be any unique text string that can identify a unique resource - this is the type of referencing done by a wiki, and is much simpler and approachable for users).  This handles moves and renames, but doesn't neatly handle deletes.  A second way is to simply "catch" at the time a user is committing a delete, move or rename and identify the list of affected assets - and allow the user to take appropriate action (maybe the user is just checkpointing work at the end of the day for changes that aren't going live until end of week - they may want to check-in and version, and worry about determining what to do with the links at a later point). 

This approach is nice because it handles any reference - be it in some statically imported HTML page or some structure piece of XML authoried in our form - and handles deletes, which is imported for content you may wish to expire and purge from the site (remember, purges are super safe - you can always recover deletes!). 

Our intent is to integrate into the submit process an automatic check (which is configurable) to check for invalid reference both internal *and* external to the system - and fail the submit and assign the user a task to correct any broken references (for example, a user deletes a document, but that document is linked in-line in some text in an HTML page - just removing the link is the wrong thing to do potentially.  You can't assume ever what the right course of action is - the user once knowing where the document is linked may *not* want to delete, or may want to retarget the link to something else, or indeed may just want to remove).

We are currently exploring integration of this into our immediate roadmap plans.  In the interim, this capability can be integrated today on a custom basis by extending workflow with an additional task to callout to a 3rd open source links checking utility that can run through the submitted content via the virtualization server (nice having real URLs!) and once again fail a submit and assign a user task is broken references are found.

That's the today support.  And while we work on our own Alfresco implementation, we would love to see if anyone out there in the community was willing to contribute back just such a custom workflow to share with others.


Kevin

[edgar]

Also see: http://wiki.alfresco.com/wiki/Link_Management

cheers,


Edgar