> >> 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. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
