Andreas Hartmann wrote:
Joern Nettingsmeier schrieb:(yeah, i'm still trying to fix the proxying issue. some clown has written stylesheets that generate stylesheets to generate menus...I guess that clown was me (at least some parts of the clownery) :)
evil!talk about not allowing broken windows and at the same time sell throwing bricks... ;)
Meta stylesheets can be a beast to understand, but there are not many ways to implement hooks to call in arbitrary sitemaps. A major problem with this approach is that it becomes slow because we can't cache anything. I'm tempted to replace it with a different technology (see my note about JSF etc. in the 1.6 roadmap mail). But maybe we find a way to simplify it without abandoning the pipelines.
i think the whole shebang can be simplified a great deal, and existing cocoon techniques are just fine for that. just XSLT. no XSPs anymore, and please pretty please not another java-based buzzword-of-the-week template atrocity. angle brackets are good, curlies are bad. :)
and the core sitemaps completely fail to use the base-url module, which is apparently the only one that is proxy-aware...)That's because the core sitemaps are much older than the base-url module. Is there something particular I could help you with? A test case / setup description would be great. I'll take a look at the docs and wiki pages.
well, after 2 days of digging around, i've come to the conclusion that lenya proxying support is broken beyond repair, at least for $area != live. which is ok, since we can provide our customers with sane urls most of the time. they will just have to provide a dedicated ssl server where lenya runs in the root context. oh well.
it's not worth trying for a quick fix. nothing short of a complete rewrite will do. the fact that we'd have to patch the entire core and almost all modules in both pipelines and xslts is a sure sign that url rewriting (both for proxy and non-root servlet contexts) should be done in a central post-processing pipeline in the core. <map:serialize type="xhtml"/> should be forbidden in all places but one, and that's where we do the final link munging.
i'd say we should document proxying as currently unsupported and throw the entire bunch of xslts and pipelines in core away and rewrite them from scratch for 1.5. i'm not saying there's not a lot of useful code in there, but the cruft has accumulated so thick that we'll be better off starting with a clean slate and pasting the useful old stuff over, rather than trying to clean up the existing code base in-place.
sorry to be so negative, but i think we have painted ourselves in a corner big time. it's nothing that would endanger 1.4 or reduce its usefulness, but we are at a dead end now wrt URL handling. just look at the mess:
{page-envelope:document-url}
{page-envelope:document-path}
{page-envelope:document-id}
[page-envelope:area}
{base-uri:<pubid>:<area>:<useSSL>}
{proxy-url:<pubid>:<area>:<useSSL>}
{request:contextPath}
...
and then there's a shitload of hard-coded path magic and java string
munging all over the place.
we need one canonical way of treating output URLs inside lenya that disregards servlet context and proxy. while we're at it, we should throw away the areas rsn.
all but one the URL handling methods listed above have to go.when that is accomplished, we will have reduced our core pipeline code by at least 60%, many obsolete input modules will be gone for good, performance will improve *a lot*, and lenya will finally be a pleasure to hack on and much easier to learn....
i'll try to come up with some docs for rudimentary proxying by the end of the week, after i've returned from a job on saturday...
-- Jörn Nettingsmeier Kurt is up in heaven now. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
