Solprovider Lenya Kongregate Registration for Free Flash Games and Chat with solprovider

Improvement: Use Area for XMAP

I suggest using the "Area" for the XMAP.  It would make adding a "webdav" (or any other) Sitemap/XMAP/Usecase/Publet/Module [choose your favorite name] easy.  So the URLs would be:

{pub}/authoring.xmap should just pass control to {pub}/live.xmap so they can share code.

In a post, Torsten Schlabach asks for an easy method for closing the "authoring" area for production servers.  Replacing the "area" with the "XMAP" would do that.  To keep the current maintainability, "authoring.xmap" should pass control to "live.xmap". For the production server, just replace "authoring.xmap" with one that returns "sorry.html".  An "authoring.xmap" could be written to check the name of the current server against a configurable list to decide whether to pass control to live.xmap or return the error page.

I think this change would require:
1. Changing/adding some files:
publication-sitemap.xmap -> live.xmap (or have one redirect to the other.)
authoring.xmap (new, just redirects to live.xmap)

2. Minor changes to the global XMAPs:
Check for "{pub}/{area}.xmap", then "{pub}/usecase-{area}.xmap", then
the same for global files.  This is so we do not need to remove
"usecase-" from many filenames, but that naming convention would be
deprecated.  Use "lenya.usecase=" querystring would also be
deprecated, but should have priority over the "area" for backwards

3. May require changing the PageEnvelope code.

Are there any other considerations?

With the move to JCR, structuring content by workflow state will add complexity to the repository without adding any value. I expect the structure to be Content/Document/Version. Workflow state is just a property. Document has CurrentLiveVersion and CurrentEditVersion properties. Versions have Created, LastEdited, and LastPublished and other properties for Workflow. Publishing is just changing the CurrentLiveVersion. Approval Workflow is implemented by approving/rejecting specific versions, which changes properties on the Version, and the approval could be revoked later to prevent obsolete information from being published. Workflow will probably be implemented in Doctype Modules. "XHTML Document" must be approved by someone in the "Reviewer" Group, maybe with the requirement the reviewer is not the last editor. "Legal Document" requires approval from someone in the "Legal" Group.

The "Area" part of URLs should indicate the function, represented by the module name. "live" displays the last published version of the specified document. "edit" (or "authoring" for backwards compatibility) opens the current editing version. "login" displays the login page, but remembers which document was requested. "admin" displays the admin page (or more likely, there will be modules for "people", "person", "groups", "group", "tools".)

I do not expect administrative tasks to be implemented differently from workflow tasks. Some functions take a document as a parameter. Some do not. All should be supported by the module framework.

Areas will be obsolete; the data structure supporting them will not exist. Modules need to be specified in the URLs. It would be easier to use the Area part of the URL for the Module name than continue with Lenya1.2's convention of using the querystring for Usecases/Modules.

FILE: {pub}/usecase-contact.xmap
URL: http://server/pub/live/document?lenya.usecase=contact
Notice that Area="live" is useless. It does not affect anything.

URL: http://server/pub/contact
or http://server/pub/contact/document if you want to know which page excited the visitor.

It should be even more rare when "something bad happens during publishing", since publishing changes a property rather than copying files, but just change the Document's CurrentLiveVersion to a different version (basically publishing an older version, possibly bypassing the history functions.)

Restoration/Rollback has many options with this approach.
1. OS Backups
2. Documents have history of live versions.  Publish the one that was live on the desired date.
- There could also be a history of "edit" versions.  Even if we do not store the "edit" history, it could be recreated from the history information stored in the Versions.  There will be several Views of versions of a Document: Live history, Edit History, By CreationDate, even Threaded Views that shows the relationships: each Version is the parent or child of the Version it was based.  For most Documents, the thread is linear, but this could be useful for a Document that often is replaced from older Versions, like the "Next Holiday" page.  This year's "Easter" version could be based on last year's "Easter" version rather than the current page.  This View would make the forking obvious.
3. To rollback the entire (or a section of a) publication, Publish all documents based on the live date.  This must decide what to do if the previous version was deleted: should it use the next older or newer document (and log the issue)?  Also, what if approval was revoked for a Version?  Are we rolling back for historical purposes, or should the workflow rules be obeyed for production?  I can design the RollbackAll function, but I cannot think why it would be used.
4. Snapshots of "live" and/or "authoring" can be created easily with the new "Process Multiple Documents" framework.  CreateSnapshot() creates a new repository with just the desired Documents.  Or exports them as XML files.  Or whatever.

Removing the concept of Workflow Areas makes the structure much more flexible.  It should also be more stable.

<< Old: Content StructureOld: Assets >>

Contact Solprovider
Paul Ercolino