On 12/2/05, Felix Röthenbacher <[EMAIL PROTECTED]> wrote:
> > I hope "area" will soon be replaced by modules. Are there any modules
> > that care about both "live" and "authoring"? Admin modules do not
> > care about either. Editing modules care about "authoring".
> > Functional modules (Search, Sitemap, Summaries) care about "live". If
> > a module does care about both, it can default to "live" unless a
> > module-specific parameter specifies "authoring".
> I don't understand why you want to replace areas with modules. Areas are
> an administrative structure related either to administrative tasks (
> (admin, site) or to the workflow whereas modules are software components
> which offers functionality to the application/publication.
> If you propose to clearly separate workflow areas from administrative
> areas I would give my +1.
(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. 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]
