Andreas Hartmann wrote:
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.
not yet - but the grim code reaper is drawing near :-D
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.
i think you may be a little biased against xslts... sure, the language
is verbose, but it *is* possible to write quite elegant stuff with it.
even more so with xslt2. i think it is quite natural to implement menu
semantics in xslt. and what we currently do is not exactly rocket science.
if we're going to make any fundamental changes to how the GUI works, we
should rather introduce ajax and do the interesting stuff on the client.
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.
what are DSLs?
why debate XML? XML by itself means nothing and does nothing. it's just
an agreement on a very simple syntax with tried and true parsers and a
tree paradigm. that does not imply anything. every procedural or oo
language can be represented as a tree (think stack frames).
ok, it's tedious to type.
show me another nice syntax that comes with excellent parser
implementations for all major programming environments, a
turing-complete transformation language and a grammar description
language that allows for automatic validation. then let's count how many
people work on that compared to how many people work on xml...
i think the evil thing about sitemaps are the many custom components.
the core sitemap language needs to be more powerful...
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.
agreed. the problem is that we can only use proxies that have the lenya
stuff in their root context, which is a problem for many setups.
i have a running proxy setup atm, and so does richard, but it's not what
i'd call "proxy support". we should be honest and tell our users that it
can be made to work a little bit, but we have to rely heavily on
external request rewriting. our own proxy support is basically broken at
this point, and it's not easily possible to completely hide the
"<pubname>/live" part of the uris. (it works for simple pages, but not
if you use usecases or module resources in your live site.)
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.
i did not intend to bad-mouth the work spent on that. the problem is:
the moment we introduce a new, correct method to do something, the old,
deprecated stuff must be eliminated asap.
"there's more than one way to do it" is a nice fairytale from perl land.
on this planet, it usually becomes "there's more than one way to do it
subtly wrong".
everybody learns by example, and currently nobody but you seems to know
what the correct method for URL handling is. i only found out about it
because i tried proxying.
that means we cannot tolerate anything less than best practice code in
the core, else we risk that all user contributions and custom extensions
are fundamentally wrong and will easily break.
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 guess we have a chicken and egg problem here. but as soon as
everything's nice and shiny, they will come, i'm sure :)
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?
hopefully.
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
