Re: [PROPOSAL] Input module calling convention.

[so...@apache.org]

> {<module-name>:<pub-id>:<area>:<doc-id>:<doc-lang>:<p1>:<p2>:<...>:<px>}
> {<module-name>:<pub-id>:<area>:<doc-lang>:<doc-id>:<p1>:<p2>:<...>:<px>}

I prefer extendable parameters after defined parameters, so I prefer
the last, but this is a cosmetic decision.

The pub-id should be before the module name.  A publication can
override a global module, and can have publication-specific modules.

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 suggest:
{<pub-id>:<module-name>:<doc-lang>:<doc-id>:<p1>:<p2>:<...>:<px>}

> This raises the question if we should even use the URL snippet for
> the document locator, or rather a globally unique ID (either generated
> by the system, or assigned upon document creation). This would allow
> to match the document locator using a single asterisk, which would
> probably simplify pipelines.

Other platforms wrap global identifiers in braces {}.  So a document could be:
/hr/benefits_en.html
or
{2005120120070766}  (Global identifiers are usually time-based to
prevent duplicates.)

Using braces could be a problem if the braces in this proposal are
meant to be the specification.

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [PROPOSAL] Input module calling convention.

[Andreas Hartmann <an...@apache.org>]

solprovider@apache.org wrote:

<snip what="reasonable comments how to deprecate the area concept"/>

This sounds reasonable, but actually I'm still hesitant whether
the tag / version approach is superior to the area concept.
I'd like to know what Felixand the others think about your comments.

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [PROPOSAL] Input module calling convention.

[so...@apache.org]

On 1/5/06, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@apache.org wrote:
> > 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.

First, 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.  Isn't that why we are
moving to JCR?

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [PROPOSAL] Input module calling convention.

[Andreas Hartmann <an...@apache.org>]

solprovider@apache.org 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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [PROPOSAL] Input module calling convention.

[so...@apache.org]

On 12/2/05, Felix Röthenbacher <fe...@wyona.com> 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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [PROPOSAL] Input module calling convention.

[Felix Röthenbacher <fe...@wyona.com>]

solprovider@apache.org wrote:
>>{<module-name>:<pub-id>:<area>:<doc-id>:<doc-lang>:<p1>:<p2>:<...>:<px>}
>>{<module-name>:<pub-id>:<area>:<doc-lang>:<doc-id>:<p1>:<p2>:<...>:<px>}
> 
> 
> I prefer extendable parameters after defined parameters, so I prefer
> the last, but this is a cosmetic decision.

If the syntax with colons ':' is used, "extendable" parameters aren't
any issue any more. Andreas proposed to have the language parameter
before the doc-id. I would argue, that it's better to have it other
way round (<pub-id>:<area>:<doc-id>:<doc-lang>) to use the same
parameter order used in many (Java) interfaces. As said before,
the parameter order of the lenyadoc: protocol was set because of
technical limitations when '/' was used as parameter separator.

> 
> The pub-id should be before the module name.  A publication can
> override a global module, and can have publication-specific modules.

I don't think overwriting modules in publications is the way to go
because this adds a lot of complexity. What I would propose is to make
configurable which module is used, sort of component software.

> 
> 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 suggest:
> {<pub-id>:<module-name>:<doc-lang>:<doc-id>:<p1>:<p2>:<...>:<px>}
> 
> 
>>This raises the question if we should even use the URL snippet for
>>the document locator, or rather a globally unique ID (either generated
>>by the system, or assigned upon document creation). This would allow
>>to match the document locator using a single asterisk, which would
>>probably simplify pipelines.
> 
> 
> Other platforms wrap global identifiers in braces {}.  So a document could be:
> /hr/benefits_en.html
> or
> {2005120120070766}  (Global identifiers are usually time-based to
> prevent duplicates.)
> 
> Using braces could be a problem if the braces in this proposal are
> meant to be the specification.

IIRC braces '{', '}' have a special meaning in Cocoon sitemaps.

- Felix

> 
> solprovider
> 

-- 
Felix Röthenbacher                  felix.roethenbacher@wyona.com
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org