On 8/15/05, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > The only disadvantage to using Usecases is the URLs. It is nice to
> > advertise Lenya, but "?lenya.usecase=" is long. I may change it to
> > "?use=". A good website management system should make it impossible
> > for a visitor to tell what system is being used.
> This is a valid concern. I'm -1 on restricting the URL space.
> It should be possible to mimic an existing URL space when a
> site is migrated to Lenya. Maybe we can add a mechanism to
> make URL space and usecases orthogonal, for instance to map
> URLs to usecases ...
>
> > My project has Usecases for "Login", "Contact Us", "Website Map", and
> > "Search". I am adding a Usecase for administering Newsletters. It
> > feels like editing of documents will be moved from the current Area
> > system to Usecases eventually.
>
> Actually this has already happened in 1.4.
>
> > "Login" can return to the page blocked by security. "Contact Us"
> > sends the URL that caused the visitor to decide to write. "Website
> > Map" puts a star next to the document that called it. Remembering the
> > calling page is not important for Search, but using a Usecase kept the
> > code clean.
> I agree that it would be great to use the usecase concept (or even
> framework) to implement the search functionality.
>
> Maybe we could require a hook / callback which is provided by a publication
> and generates the page (navigation components etc.) so that usecases
> can be embedded in pages?
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.) 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".)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
