[EMAIL PROTECTED] wrote:
[...]
(I was randomly cleaning my Inbox and noticed I had not answered this concern.)
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.
<quote person="Felix Roethenbacher">
How is versioning of different areas handled? I think of a live
area which I can easily revert if something bad happend during
publishing. Same applies to the authoring area. I can't see
how it's accomplished to get a snapshot of both
live and authoring area with a certain time stamp.
</quote>
I also suggested the approach you're mentioning, but I share Felix'
concerns. It has to be possible to restore a certain state from the
history of the live area.
-- Andreas
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.
Example:
Lenya1.2
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.
Lenya1.4
FILE:{pub}/modules/contact/sitemap.xmap
URL: http://server/pub/contact
or http://server/pub/contact/document if you want to know which page
excited the visitor.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
