[EMAIL PROTECTED] wrote:
I have almost made this suggestion many times over the last few
months, but there are many changes in 1.4, and I have no idea if it is
relevant. I believe I can finally phrase the suggestion so it does
not harm anything, and it seems to add to your (Andreas') current
thoughts about "revisiting the Area concept".
My first impression of Lenya was Authoring should have been
implemented as a Usecase. (which you state is now the case.)
Not quite so - the "info" area has been dropped in favor of a
set of usecases. Authoring itself isn't a usecase (yet?).
I later
realized Authoring and Live need to use the same Pipelines so the
results are processed the same, because Cocoon has limited ability to
hook into another XMAP's processing specifying a different source in
the parent XMAP. In other words, it would cause major headaches for
developers if Authoring and Live were handled by separate XMAPs.
This does not apply to the Admin tab, which can easily be handled by a
Usecase without impacting anything else.
Login is another good candidate for a Usecase; the 1.2.2 hardcoded
Pipeline caused problems when overloading it. My Login Usecase is
named "session", and there are issues of nothing being displayed when
Lenya tries to bypass it and use the normal Login.
--- Usecases
Area is currently used for a boolean value: Authoring or Live. It
should be easy to check the Area for those two values and process them
normally, but assume any other Area refers to a Usecase (with the Area
set to "Live".)
IMO that should me more flexible - e.g., areas like "staging", "archive"
and "trash" should probably still be supported.
That changes the "Area" part of the URL to define the "Sitemap", with
Authoring being a special case. The filenames could eventually
reflect this.
- publication-sitemap.xmap -> live.xmap
- usecase-whatever.xmap -> whatever.xmap
Use automatic fallback from the pubs/{pub} directory to the lenya/xmap
directory, so if a publication does not overload something, it uses
global pipelines. Keep backwards compatibility by using
"publication-sitemap.xmap" if "live.xmap" does not exist, and
"usecase-whatever.xmap" if "whatever.xmap" does not exist.
That is the easy part and fixes the long URLs by eliminating
"&lenya.usecase=". Another possible improvement is to add a
"revision" parameter to Authoring editing old versions. I am
uncertain which would be better:
- http://server/pub/authoring/path/docID/200508151514.html
- http://server/pub/authoring/path/docID.html?lenya.revision=200508151514
I would prefer the first because the URL is shorter, but it may be
more difficult to implement. Maybe "rev" needs to be added to the URL
to prevent conflicts with documents named like revisions?
Please let me know if this post was useful or completely obsolete,
solprovider
I'm not yet sure if usecases and the actual website should be mixed.
Mixing CMS functionality and webapp functionality certainly lowers the
entry barrier of implementing web application logic (because existing
Lenya mechanisms can be used), but on the other hand it might cause
the usecase mechanism to become too flexible and complex, because people
want to build "everything" with usecases ...
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
