Jörn Nettingsmeier schrieb:
> 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... ;)
I take this as irony :)
The menu generation might be complex, but AFAIK there's no orphaned
or unnecessary code.
>> 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,
The menus contain a lot of functionality. The usecase framework has
improved this a bit, but has also brought a performance penalty.
I wouldn't like to put more logic in XSLTs. I agree that XSPs are bad,
we have to find a way to move the logic to Java classes or another
reasonable language.
> and please pretty please not another java-based buzzword-of-the-week
> template atrocity. angle brackets are good, curlies are bad. :)
Well, that has to be decided for our project.
History seems to show that XML is in general not the best choice
for DSLs. The Cocoon people also considered to move away from XML
for sitemaps.
>>> 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.
Thanks for diving into the details. I have to admit that I'm not
familiar enough with the proxying to judge this ATM.
What do the others think?
> 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.
That sounds reasonable.
> i'd say we should document proxying as currently unsupported
IMO this sends a wrong message. There are many 1.2.x sites running
behind a proxy. We should support at least a certain level of proxying
in 1.4.
> 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:
IMO that's not a mess, the only thing I don't like is that the
page-envelope module mimics the behaviour of other modules,
violating orthogonality. We already started to improve this situation,
but it needs more work.
> {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.
I agree.
> while we're at it, we should throw away the areas rsn.
+1, but I've no idea about the implications yet ...
> 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....
So let's hope we'll find a lot more committers :)
> 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...
OK, that would be great. Maybe we can do the RC1 next week?
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
