[EMAIL PROTECTED] wrote:
Usecases are rather orthogonal to CMS pages, by now they're not designed
to be used as normal pages. The search page should behave like a typical
CMS page, so it will be quite difficult to implement it as a usecase.
Um, I made Search a Usecase in 1.2.2. Did the purpose of Usecases
change for 1.4? There were advantages to using a Usecase:
My original thoughts were language would be easier to track since it
was already part of the current page's URL, but the final code changed
navigation/search.xsl to include the current language.
The big advantage was modular code. A Usecase meant
publication-sitemap.xmap did not require modification. Everybody
using the "Easy Download" appreciated that.
I passed the results through page2xhtml.xsl so it would match the look
of the rest of the website.
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. The only way to tell
my website is on Domino is to look at the URLs of the images, and I
may fix that if I get bored.
Using a resource type, you don't have to care about aggregating the
navigation components, because what you deliver is just a document
(content), not a complete page.
I like this concept, but I cannot justify it. ResourceTypes seem to be
overridden for many things other than their intended purpose. A
custom ResourceType should be documents using non-standard fields.
Usecases seem the appropriate choice for functionality, especially
when you want to remember the calling page. And there was (is?) that
caching bug for ResourceTypes, but that should not apply here.
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.
"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.
With the use of the cincludes, there is one xslt sheet that takes
care of the composition of the xml and one xslt sheet that takes care
of the xhtml rendering. IMO, the one thing cocoon suffers from is the
fragmented composition of the xml trees, something that must be
avoided whenever possible.
Why do you think so? IMO modularization of XML composition is rather
a good thing, if properly cached.
Caching and security are barely compatible. Lenya must add security
again to win acceptance. Caching should be almost useless for Search:
few people will be searching for the same terms, and if there is any
security, different people should get different results.
The sitemap is the place where the page flow happens.
Hiding page assembly in XSLTs makes it hard to understand.
I agree. CINCLUDEs sound faster than aggregation, but they break the
design methodology. The newsletter function could use a backend
database, but I am building it with XML files because it reduces
dependencies.
Lenya needs faster processing without relying on caching. I think I
saw a thread about replacing the XSL engine for better performance.
No suprise that i agree.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
