Update a repository xml file using XSLT

[boneill]

Hi,

When a user creates a news article I am trying to update an existing xml document which holds a list of news items with the new news item.

Therefore, I need to update another node (xml file) from an xslt template executed from the news webform.  I know where the target node is in the repository (/home/news-list.xml) but it will never be associated with a webform. 

1) Using parseXMLDocument what is the correct virtual path to use if the target node is in the Staging Sandbox.
2)parseXMLDocument will give me the root node (set of nodes) to get values from.  How can I update the target document.  I have been through the examples I cannot seem to find this scenario anywhere.

Any help would be much appreciated.

Regards

Brian

[pmonks]

I believe this is possible by walking the AVM to find the second file, however this approach won't work in the presence of concurrent updates - the following sequence of steps illustrate the problem:

1. User A edits news item X, which (via XSLT) also modifies the "new news items" item.  Both item X and the "new news items" item are automatically locked by user A.


2. User B edits news item Y, which (via the same XSLT) attempts to modify the "new news items" item but fails since it's locked by user A.

At this point user B has two choices:

1. wait until user A's changes are promoted to staging (which releases the locks)


2. submit their changes anyway, in which case news item Y will be missing from the "new news item" item

I had raised a JIRA ticket last year requesting that it be possible to be able to configure renditioning templates to re-execute at the time content is promoted to staging, but I can't seem to find it now (it may have been lost in the recent JIRA reorganisation).  That avoids this problem by ensuring the content of the second "shared" item is regenerated every time anything changes in staging.

Cheers,
Peter

[boneill]

Thanks Peter for your response,  I should have thought of that.  I have had my head so stuck into how the technology works that I did not think the versioning part of the solution through.  The conclusion I have come to is that if I want to show an index of the news items I should create the index page as a jsp and let the jsp query the repository for all news items at request time.  From what I have been reading (I am relatively new to alfresco) this would be implemented as a restful webscript that returned the data as xml via ftl & json etc.  One of the things I am still unsure of is the architecture for this solution.  From what i can make out it means I have to have an ASR available for the webscript to connect to (I assume an ASR is an Alfresco WCM Repository server that the generated website/project is copied to at deployment ).  Is this architecture correct.   The reason I was trying to update an xml file with the index information during the creation of a new news item was so that I could have a totally static site (a lot of flash driven via xml).  If I use a webscript it means that I have a dependency on an ASR.  Is this correct or am I missing something.

Regards

Brian

[pmonks]

Yep you're spot on.  Another option would be to deploy out to a filesystem (via an FSR) then use a custom FSDeploymentRunnable to either regenerate the "new news item" page at deployment time, or push the content into some other kind of queryable repository (such as a relational or XML database).  Both of these approaches complicate preview however - only the ASR + Web Scripts approach readily supports preview (although it currently requires a little bit of customisation - see http://forums.alfresco.com/viewtopic.php?t=11845 and http://issues.alfresco.com/browse/ALFCOM-334 for details).

The basic challenge with purely static sites is that once you start pre-generating pages that are sourced from multiple content items, the dependency graph quickly become  extremely complicated (ie. it becomes difficult to know what to regenerate when items are created / updated / deleted).  Pushing that problem out to the delivery environment and solving it at request time (via dynamic queries to an ASR or database or whatever) is trivial in comparison (albeit with decreased performance, although in this day and age the techniques for implementing high performance dynamic websites are becoming reasonably well defined).

Cheers,
Peter