[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.
OK, but that would mean that the search usecase can only be
applied to the default publication.
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.
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 ...
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.
OK, maybe the term "resource type" shouldn't be applied here, but
the concept remains valid. IMO a resource can be seen as a black box,
it doesn't matter if it is embodied by a document or an application.
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.
Just a random thought:
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?
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.
OK, I see your point.
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.
That would be a good place to start, because it can add significant
performance boost (Xalan -> XSLTC sometimes up to 50%) and (theoretically)
doesn't require changes to the code.
Reducing the number of XSLT processings is another issue, especially
if incremental processing can't be used (which is hard to achieve
anyway).
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
