You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Jörn Nettingsmeier <ne...@apache.org> on 2007/05/09 16:39:11 UTC
proxying woes...
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Richard Frovarp wrote:
[...]
>> We
>> might want to strip out the SSL checkbox option from the pages, as
>> this isn't going to do anything and will just be confusing.
Would that mean either everything is served with SSL or nothing?
Well, I guess that's OK for the authoring environment.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Richard Frovarp wrote:
> Like you said, the live side is fine, so long as you don't try to
> protect anything behind SSL.
have you succeeded in hiding the <pubname>/live from the URLs?
> It is unfortunate that for authoring Lenya
> has to run in the root context, but it is at least a solution. One could
> work with the Apache config to support other items on the ssl server. I
> am not familiar with the code, but I know from my experience there is a
> ton of stuff that needs to be changed.
> We
> might want to strip out the SSL checkbox option from the pages, as this
> isn't going to do anything and will just be confusing.
+1
wdot?
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
>>>> 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?
>
>
Like you said, the live side is fine, so long as you don't try to
protect anything behind SSL. It is unfortunate that for authoring Lenya
has to run in the root context, but it is at least a solution. One could
work with the Apache config to support other items on the ssl server. I
am not familiar with the code, but I know from my experience there is a
ton of stuff that needs to be changed.
>
>> 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.
>
From my experience, proxying the live side works just fine under HTTP.
Proxying the authoring side under SSL is limited to being the root
context on the ssl server. This is unfortunate, but it does work. We
might want to strip out the SSL checkbox option from the pages, as this
isn't going to do anything and will just be confusing.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-05-10 at 12:07 +0200, Jörn Nettingsmeier wrote:
> Thorsten Scherler wrote:
> > I agree totally with you. A trivial example is doing string operations
> > in xsl is total nightmare.
>
> which i think is a big bonus. string operations should hurt. you should
> think twice before munging strings, and then it should be a royal pain.
totally agree, I just used it as example. Like you state in another
message xsl is event based, but presentation logic most of the time is
more efficient in traditional programming.
...
> >>> should be done in a more flexible way via a template that will get the
> >>> parts it needs.
> >>> This way it would be as well possible to extend it more
> >>> easy without touching the sitemap.
> >> Big +1.
> >
> > Will have a look and try to come up with something simple.
>
> with your twins and all that goes with it, there is no chance that you
> could make it to zurich i guess? it would be great to talk about this
> f2f... (and to maybe have a beer among old flame-buddies ;)
jeje, for sure I am always good for a good Pils. ;)
I need to see how I can manage to come to Zürich, I may arrange it and
do some happy hacking with you guys (hopefully sponsored by Bitburger,
jeje)
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Thorsten Scherler wrote:
> I agree totally with you. A trivial example is doing string operations
> in xsl is total nightmare.
which i think is a big bonus. string operations should hurt. you should
think twice before munging strings, and then it should be a royal pain.
no. i'm not trolling. look into our java code. we have totally wild
string operations all over the place, and many are wrong or duplicate
semantics that should be defined in just one place.
9 out of 10 times, string operations in lenya are just lazyness hacks or
consequences of design mistakes.
that said, string operations are a lot more comfortable in XSLT2, but
i'm not going to tell anyone that XPath2 has full regexes, because then
people will start doing ugly things in stylesheets as well. :-D
>>> should be done in a more flexible way via a template that will get the
>>> parts it needs.
>>> This way it would be as well possible to extend it more
>>> easy without touching the sitemap.
>> Big +1.
>
> Will have a look and try to come up with something simple.
with your twins and all that goes with it, there is no chance that you
could make it to zurich i guess? it would be great to talk about this
f2f... (and to maybe have a beer among old flame-buddies ;)
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Josias Thöny schrieb:
[...]
> The menu generation is slowed down considerably by all the precondition
> checks of the usecases in the menu.
> Some time ago I noticed that in the "authoring" view, the usecases which
> appear only in the "site" view are checked, too. This is probably not
> necessary.
> One example is the delete usecase whose precondition check is quite
> expensive because it checks the whole subtree (IIRC). This check is also
> executed in the "authoring" view, although the delete usecase is not
> available in the "authoring" menu.
> Or has this been changed recently? I'm not quite up to date...
Unfortunately it hasn't changed. I did some optimization for the publish
usecase (missing links are only generated when the view is displayed),
but there is much room for improvement.
Maybe it would be an option to filter the XSPs before evaluating
them, i.e. do the menu aggregation and filtering before the
ServerPagesGenerator is executed. But this would require to compile
the classes for every request, which is certainly expensive as well.
-- Andreas
>
> josias
>
>
>>
>>> Yes, agree that is even better since it is more efficient.
>>>
>>>>> 3) Populate the file from step 2 with java objects that are in the
>>>>> request.
>>>>>
>>>>> Where 1 is a match of its own (for caching reasons) and 2 and 3 in one
>>>>> match.
>>>>>
>>>>> The menu should be independent from the main aggregation. Actually the
>>>>> whole main aggregation
>>>> [...]
>>>>
>>>>> should be done in a more flexible way via a template that will get the
>>>>> parts it needs.
>>>>> This way it would be as well possible to extend it more
>>>>> easy without touching the sitemap.
>>>> Big +1.
>>> Will have a look and try to come up with something simple.
>> When should we change this? RC1 / RC2 / 1.4.1 ?
>>
>> -- Andreas
>>
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Josias Thöny <jo...@wyona.com>.
On Thu, 2007-05-10 at 11:38 +0200, Andreas Hartmann wrote:
> Thorsten Scherler schrieb:
> > On Thu, 2007-05-10 at 10:57 +0200, Andreas Hartmann wrote:
> >> Thorsten Scherler schrieb:
> >>> On Wed, 2007-05-09 at 23:01 +0200, Jörn Nettingsmeier wrote:
> >>>> Andreas Hartmann wrote:
> >>>>> Joern Nettingsmeier schrieb:
> >>> ...
> >>>>> Our menu is a special case - it has a basic structure (which XML is
> >>>>> fine for), but there's some logic to control the details. We have to
> >>>>> find a way to separate these aspects, maybe by introducing a generic
> >>>>> mechanism to show/hide/enable/disable menu items.
> >>>> hmm. especially for trivial things such as menu enabling/disabling, xsl
> >>>> is suited fine. and i'm quite sure the menu2xhtml can be simplified *a
> >>>> lot*. most of the confusion in there comes from our URL handling problems.
> >>>>
> >>> Right now in the menu we can decide when and which item to show. I agree
> >>> that the xsp approach needs rethinking but why not use jx instead.
> >> The problem with JX is that you can't access arbitrary Java objects
> >> without passing them from a flowscript. We'd have to define which
> >> set of objects we pass, and that wouldn't be extensible without
> >> overriding the flowscript.
> >
> > Actually they have changed that. I found the mail on cocoon-dev where
> > they told me so, it was about the JXGenerator and caching.
> > thread: http://marc.info/?t=115834950000002&r=1&w=2
> > answer: http://marc.info/?l=xml-cocoon-dev&m=115866670503538&w=2
>
> Thanks for the info, I'll take a closer look at this.
>
> [...]
>
> >> Maybe we could even refine this so that we don't have to aggregate the
> >> full menu and filter it, but have different cached menus, depending on
> >> the modules needed for a request.
> >
> > You mean, the pub defines x modules and we just aggregate this x menus?
>
> Yes, or maybe even based on the resource type. If a pub has 10 resource
> types, and only the "edit" menu for the current resource type has to be
> generated, there's certainly room for optimization.
The menu generation is slowed down considerably by all the precondition
checks of the usecases in the menu.
Some time ago I noticed that in the "authoring" view, the usecases which
appear only in the "site" view are checked, too. This is probably not
necessary.
One example is the delete usecase whose precondition check is quite
expensive because it checks the whole subtree (IIRC). This check is also
executed in the "authoring" view, although the delete usecase is not
available in the "authoring" menu.
Or has this been changed recently? I'm not quite up to date...
josias
>
>
> > Yes, agree that is even better since it is more efficient.
> >
> >>> 3) Populate the file from step 2 with java objects that are in the
> >>> request.
> >>>
> >>> Where 1 is a match of its own (for caching reasons) and 2 and 3 in one
> >>> match.
> >>>
> >>> The menu should be independent from the main aggregation. Actually the
> >>> whole main aggregation
> >> [...]
> >>
> >>> should be done in a more flexible way via a template that will get the
> >>> parts it needs.
> >>> This way it would be as well possible to extend it more
> >>> easy without touching the sitemap.
> >> Big +1.
> >
> > Will have a look and try to come up with something simple.
>
> When should we change this? RC1 / RC2 / 1.4.1 ?
>
> -- Andreas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-05-10 at 11:15 -0500, Richard Frovarp wrote:
> Thorsten Scherler wrote:
...
> >> When should we change this? RC1 / RC2 / 1.4.1 ?
> >>
> >
> > I am not sure, but I would not make it a blocker, since it would need
> > much testing. I would first test it local and if it works I will ask to
> > lift the code freeze.
> >
> > In theory we can reuse the forrest dispatcher, but that as well means we
> > would need to use the locationmap (not bad as all).
> >
> > http://forrest.apache.org/docs_0_80/locationmap.html
> >
> > salu2
> >
>
> Why don't we wait until 1.4.1? Let's clear up the real bugs and get
> 1.4.0 out the door. If I'm following the conversation correctly, this
> will change core parts of how things work. Especially for those that
> have done their own custom menus or customized existing menus.
> Therefore, it shouldn't be an update to an RC. We really need to stop
> adding features and refactoring code. We need a stable final 1.4.0 release.
Actually the match I was talking about is publication specific, the
dispatcher approach is not the replacement of the menu generation.
I agree that we need to get 1.4.0 out and the menu refactoring would be
for 1.4.1. That is why I said it should not be a blocker.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Thorsten Scherler wrote:
> On Thu, 2007-05-10 at 11:38 +0200, Andreas Hartmann wrote:
> ...
>
>>> Yes, agree that is even better since it is more efficient.
>>>
>>>
>>>>> 3) Populate the file from step 2 with java objects that are in the
>>>>> request.
>>>>>
>>>>> Where 1 is a match of its own (for caching reasons) and 2 and 3 in one
>>>>> match.
>>>>>
>>>>> The menu should be independent from the main aggregation. Actually the
>>>>> whole main aggregation
>>>>>
>>>> [...]
>>>>
>>>>
>>>>> should be done in a more flexible way via a template that will get the
>>>>> parts it needs.
>>>>> This way it would be as well possible to extend it more
>>>>> easy without touching the sitemap.
>>>>>
>>>> Big +1.
>>>>
>>> Will have a look and try to come up with something simple.
>>>
>> When should we change this? RC1 / RC2 / 1.4.1 ?
>>
>
> I am not sure, but I would not make it a blocker, since it would need
> much testing. I would first test it local and if it works I will ask to
> lift the code freeze.
>
> In theory we can reuse the forrest dispatcher, but that as well means we
> would need to use the locationmap (not bad as all).
>
> http://forrest.apache.org/docs_0_80/locationmap.html
>
> salu2
>
Why don't we wait until 1.4.1? Let's clear up the real bugs and get
1.4.0 out the door. If I'm following the conversation correctly, this
will change core parts of how things work. Especially for those that
have done their own custom menus or customized existing menus.
Therefore, it shouldn't be an update to an RC. We really need to stop
adding features and refactoring code. We need a stable final 1.4.0 release.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-05-10 at 11:38 +0200, Andreas Hartmann wrote:
...
> > Yes, agree that is even better since it is more efficient.
> >
> >>> 3) Populate the file from step 2 with java objects that are in the
> >>> request.
> >>>
> >>> Where 1 is a match of its own (for caching reasons) and 2 and 3 in one
> >>> match.
> >>>
> >>> The menu should be independent from the main aggregation. Actually the
> >>> whole main aggregation
> >> [...]
> >>
> >>> should be done in a more flexible way via a template that will get the
> >>> parts it needs.
> >>> This way it would be as well possible to extend it more
> >>> easy without touching the sitemap.
> >> Big +1.
> >
> > Will have a look and try to come up with something simple.
>
> When should we change this? RC1 / RC2 / 1.4.1 ?
I am not sure, but I would not make it a blocker, since it would need
much testing. I would first test it local and if it works I will ask to
lift the code freeze.
In theory we can reuse the forrest dispatcher, but that as well means we
would need to use the locationmap (not bad as all).
http://forrest.apache.org/docs_0_80/locationmap.html
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler schrieb:
> On Thu, 2007-05-10 at 10:57 +0200, Andreas Hartmann wrote:
>> Thorsten Scherler schrieb:
>>> On Wed, 2007-05-09 at 23:01 +0200, Jörn Nettingsmeier wrote:
>>>> Andreas Hartmann wrote:
>>>>> Joern Nettingsmeier schrieb:
>>> ...
>>>>> Our menu is a special case - it has a basic structure (which XML is
>>>>> fine for), but there's some logic to control the details. We have to
>>>>> find a way to separate these aspects, maybe by introducing a generic
>>>>> mechanism to show/hide/enable/disable menu items.
>>>> hmm. especially for trivial things such as menu enabling/disabling, xsl
>>>> is suited fine. and i'm quite sure the menu2xhtml can be simplified *a
>>>> lot*. most of the confusion in there comes from our URL handling problems.
>>>>
>>> Right now in the menu we can decide when and which item to show. I agree
>>> that the xsp approach needs rethinking but why not use jx instead.
>> The problem with JX is that you can't access arbitrary Java objects
>> without passing them from a flowscript. We'd have to define which
>> set of objects we pass, and that wouldn't be extensible without
>> overriding the flowscript.
>
> Actually they have changed that. I found the mail on cocoon-dev where
> they told me so, it was about the JXGenerator and caching.
> thread: http://marc.info/?t=115834950000002&r=1&w=2
> answer: http://marc.info/?l=xml-cocoon-dev&m=115866670503538&w=2
Thanks for the info, I'll take a closer look at this.
[...]
>> Maybe we could even refine this so that we don't have to aggregate the
>> full menu and filter it, but have different cached menus, depending on
>> the modules needed for a request.
>
> You mean, the pub defines x modules and we just aggregate this x menus?
Yes, or maybe even based on the resource type. If a pub has 10 resource
types, and only the "edit" menu for the current resource type has to be
generated, there's certainly room for optimization.
> Yes, agree that is even better since it is more efficient.
>
>>> 3) Populate the file from step 2 with java objects that are in the
>>> request.
>>>
>>> Where 1 is a match of its own (for caching reasons) and 2 and 3 in one
>>> match.
>>>
>>> The menu should be independent from the main aggregation. Actually the
>>> whole main aggregation
>> [...]
>>
>>> should be done in a more flexible way via a template that will get the
>>> parts it needs.
>>> This way it would be as well possible to extend it more
>>> easy without touching the sitemap.
>> Big +1.
>
> Will have a look and try to come up with something simple.
When should we change this? RC1 / RC2 / 1.4.1 ?
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-05-10 at 10:57 +0200, Andreas Hartmann wrote:
> Thorsten Scherler schrieb:
> > On Wed, 2007-05-09 at 23:01 +0200, Jörn Nettingsmeier wrote:
> >> Andreas Hartmann wrote:
> >>> Joern Nettingsmeier schrieb:
> > ...
> >>> Our menu is a special case - it has a basic structure (which XML is
> >>> fine for), but there's some logic to control the details. We have to
> >>> find a way to separate these aspects, maybe by introducing a generic
> >>> mechanism to show/hide/enable/disable menu items.
> >> hmm. especially for trivial things such as menu enabling/disabling, xsl
> >> is suited fine. and i'm quite sure the menu2xhtml can be simplified *a
> >> lot*. most of the confusion in there comes from our URL handling problems.
> >>
> >
> > Right now in the menu we can decide when and which item to show. I agree
> > that the xsp approach needs rethinking but why not use jx instead.
>
> The problem with JX is that you can't access arbitrary Java objects
> without passing them from a flowscript. We'd have to define which
> set of objects we pass, and that wouldn't be extensible without
> overriding the flowscript.
Actually they have changed that. I found the mail on cocoon-dev where
they told me so, it was about the JXGenerator and caching.
thread: http://marc.info/?t=115834950000002&r=1&w=2
answer: http://marc.info/?l=xml-cocoon-dev&m=115866670503538&w=2
>
>
> > This
> > would make it possible to keep presentation logic in an easy way. From
> > my experience xsl it is not very suitable to implement presentation
> > logic which are based on java objects.
>
> Yes, this is exactly the problem.
I agree totally with you. A trivial example is doing string operations
in xsl is total nightmare.
>
>
> > Further if we switch from xsp to jx we can reuse the pipelines for now
> > since we would just switch the way how we call it.
> >
> > To the xsl generating xsl I once had done a similar thing in the
> > dispatcher but then wrote a custom transformer since this reduces
> > complexity of the code and put it into one java component.
> >
> > If we break down the menu generation process like:
> > 1) Core looks up all menu extensions from the module and aggregate them
> > in one file (done once since from there we can use the cached match).
> > [1a] optional: filter the menus that are not needed for the publication
> > 2) Url specific filter which connects the menu file and gets all menus
> > that are needed. Returning a subset of menus and pass it to the next
> > step.
>
> Sounds reasonable.
> Maybe we could even refine this so that we don't have to aggregate the
> full menu and filter it, but have different cached menus, depending on
> the modules needed for a request.
You mean, the pub defines x modules and we just aggregate this x menus?
Yes, agree that is even better since it is more efficient.
>
> > 3) Populate the file from step 2 with java objects that are in the
> > request.
> >
> > Where 1 is a match of its own (for caching reasons) and 2 and 3 in one
> > match.
> >
> > The menu should be independent from the main aggregation. Actually the
> > whole main aggregation
>
> [...]
>
> > should be done in a more flexible way via a template that will get the
> > parts it needs.
> > This way it would be as well possible to extend it more
> > easy without touching the sitemap.
>
> Big +1.
Will have a look and try to come up with something simple.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler schrieb:
> On Wed, 2007-05-09 at 23:01 +0200, Jörn Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Joern Nettingsmeier schrieb:
> ...
>>> Our menu is a special case - it has a basic structure (which XML is
>>> fine for), but there's some logic to control the details. We have to
>>> find a way to separate these aspects, maybe by introducing a generic
>>> mechanism to show/hide/enable/disable menu items.
>> hmm. especially for trivial things such as menu enabling/disabling, xsl
>> is suited fine. and i'm quite sure the menu2xhtml can be simplified *a
>> lot*. most of the confusion in there comes from our URL handling problems.
>>
>
> Right now in the menu we can decide when and which item to show. I agree
> that the xsp approach needs rethinking but why not use jx instead.
The problem with JX is that you can't access arbitrary Java objects
without passing them from a flowscript. We'd have to define which
set of objects we pass, and that wouldn't be extensible without
overriding the flowscript.
> This
> would make it possible to keep presentation logic in an easy way. From
> my experience xsl it is not very suitable to implement presentation
> logic which are based on java objects.
Yes, this is exactly the problem.
> Further if we switch from xsp to jx we can reuse the pipelines for now
> since we would just switch the way how we call it.
>
> To the xsl generating xsl I once had done a similar thing in the
> dispatcher but then wrote a custom transformer since this reduces
> complexity of the code and put it into one java component.
>
> If we break down the menu generation process like:
> 1) Core looks up all menu extensions from the module and aggregate them
> in one file (done once since from there we can use the cached match).
> [1a] optional: filter the menus that are not needed for the publication
> 2) Url specific filter which connects the menu file and gets all menus
> that are needed. Returning a subset of menus and pass it to the next
> step.
Sounds reasonable.
Maybe we could even refine this so that we don't have to aggregate the
full menu and filter it, but have different cached menus, depending on
the modules needed for a request.
> 3) Populate the file from step 2 with java objects that are in the
> request.
>
> Where 1 is a match of its own (for caching reasons) and 2 and 3 in one
> match.
>
> The menu should be independent from the main aggregation. Actually the
> whole main aggregation
[...]
> should be done in a more flexible way via a template that will get the
> parts it needs.
> This way it would be as well possible to extend it more
> easy without touching the sitemap.
Big +1.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler schrieb:
[...]
> Actually for me that "every non-trivial operation requires offloading to
> java code" is a benefit since it keeps the heavy logic out of the
> templates. I guess we all have seen once in our life a jsp that
> contained an actual java class within, well let alone jsp and look in
> some of our xsp that are nearly doing it.
>
> The benefit "outsourcing" this operation to java objects is the
> re-usability and the reduction of complexity. I lately developed some
> components for a customer in java flow and must admit it is heaps
> cleaner then js. Sure you can use java objects in js, but who really
> wants to program in js if you can do it directly in java.
>
> Having my flow in java I followed a bean approach to pass the objects to
> the view and could test all the non trivial operations with junit. If we
> allow too much in the view we have not the benefit of testing with
> junit.
I'd love to read more mails like this. :)
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-05-10 at 11:28 +0200, Joern Nettingsmeier wrote:
> Thorsten Scherler wrote:
> > Right now in the menu we can decide when and which item to show. I agree
> > that the xsp approach needs rethinking but why not use jx instead. This
> > would make it possible to keep presentation logic in an easy way. From
> > my experience xsl it is not very suitable to implement presentation
> > logic which are based on java objects.
>
> i must confess i don't like jx very much... its control structures are
> totally crippled and every non-trivial operation requires offloading to
> java code, even if it is just view-related and thus be in the template
> code....
Actually for me that "every non-trivial operation requires offloading to
java code" is a benefit since it keeps the heavy logic out of the
templates. I guess we all have seen once in our life a jsp that
contained an actual java class within, well let alone jsp and look in
some of our xsp that are nearly doing it.
The benefit "outsourcing" this operation to java objects is the
re-usability and the reduction of complexity. I lately developed some
components for a customer in java flow and must admit it is heaps
cleaner then js. Sure you can use java objects in js, but who really
wants to program in js if you can do it directly in java.
Having my flow in java I followed a bean approach to pass the objects to
the view and could test all the non trivial operations with junit. If we
allow too much in the view we have not the benefit of testing with
junit.
...
> > Further it would be possible to have url specific extension of extra
> > content and/or extra functionality. Imagine I do not want the breadcrumb
> > or the lanuageselector on some pages but on other I do. Now I always get
> > this parts, paying the price that Dominique has described.
>
> let's be careful not to stash too much into the URL space.... the
> flexibility would be a bonus, but awkward URLs can be a problem. plus if
> we export too many internal features to the outside via URLs, we might
> open ourselves to exploits and DoSes.
> for instance, the SVG flag rendering is a potential DoS already, because
> it's so expensive in terms of cpu cycles. we need to avoid a situation
> where a malicious site visitor can trigger all kinds of cpu hogs by
> tinkering with the request URL.
Actually the url space e.g. in the dispatcher is untouched, it is only
used to trigger the corresponding template.
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/how/howto-dispatcher-structurer.html
and
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/int/index.html
see "structurer templating"
wdyt?
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-05-10 at 11:55 +0200, Joern Nettingsmeier wrote:
> Andreas Hartmann wrote:
> > Joern Nettingsmeier schrieb:
> >> Thorsten Scherler wrote:
> >
> > [...]
> >
> >>> Further it would be possible to have url specific extension of extra
> >>> content and/or extra functionality. Imagine I do not want the breadcrumb
> >>> or the lanuageselector on some pages but on other I do. Now I always get
> >>> this parts, paying the price that Dominique has described.
> >> let's be careful not to stash too much into the URL space.... the
> >> flexibility would be a bonus, but awkward URLs can be a problem. plus if
> >> we export too many internal features to the outside via URLs, we might
> >> open ourselves to exploits and DoSes.
> >> for instance, the SVG flag rendering is a potential DoS already, because
> >> it's so expensive in terms of cpu cycles. we need to avoid a situation
> >> where a malicious site visitor can trigger all kinds of cpu hogs by
> >> tinkering with the request URL.
> >
> > IIUC Thorsten didn't mean to code anything in the URL, but choose a
> > different template and thus different navigation elements depending on
> > the current URL, resource type, or whatever (e.g., display /news/*
> > withouth the news sidebar).
>
> ah, i see. thorsten, can you explain a bit more? are you thinking of
> location-to-feature maps? is that comparable to the locationmaps of
> forrest you mentioned before? if yes, could you post an example of such
> a location map if it's not too much trouble?
Did you see my other post where I posted some links? There are some
examples, if they are not sufficient, sure.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Andreas Hartmann wrote:
> Joern Nettingsmeier schrieb:
>> Thorsten Scherler wrote:
>
> [...]
>
>>> Further it would be possible to have url specific extension of extra
>>> content and/or extra functionality. Imagine I do not want the breadcrumb
>>> or the lanuageselector on some pages but on other I do. Now I always get
>>> this parts, paying the price that Dominique has described.
>> let's be careful not to stash too much into the URL space.... the
>> flexibility would be a bonus, but awkward URLs can be a problem. plus if
>> we export too many internal features to the outside via URLs, we might
>> open ourselves to exploits and DoSes.
>> for instance, the SVG flag rendering is a potential DoS already, because
>> it's so expensive in terms of cpu cycles. we need to avoid a situation
>> where a malicious site visitor can trigger all kinds of cpu hogs by
>> tinkering with the request URL.
>
> IIUC Thorsten didn't mean to code anything in the URL, but choose a
> different template and thus different navigation elements depending on
> the current URL, resource type, or whatever (e.g., display /news/*
> withouth the news sidebar).
ah, i see. thorsten, can you explain a bit more? are you thinking of
location-to-feature maps? is that comparable to the locationmaps of
forrest you mentioned before? if yes, could you post an example of such
a location map if it's not too much trouble?
--
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier schrieb:
> Thorsten Scherler wrote:
[...]
>> Further it would be possible to have url specific extension of extra
>> content and/or extra functionality. Imagine I do not want the breadcrumb
>> or the lanuageselector on some pages but on other I do. Now I always get
>> this parts, paying the price that Dominique has described.
>
> let's be careful not to stash too much into the URL space.... the
> flexibility would be a bonus, but awkward URLs can be a problem. plus if
> we export too many internal features to the outside via URLs, we might
> open ourselves to exploits and DoSes.
> for instance, the SVG flag rendering is a potential DoS already, because
> it's so expensive in terms of cpu cycles. we need to avoid a situation
> where a malicious site visitor can trigger all kinds of cpu hogs by
> tinkering with the request URL.
IIUC Thorsten didn't mean to code anything in the URL, but choose a
different template and thus different navigation elements depending on
the current URL, resource type, or whatever (e.g., display /news/*
withouth the news sidebar).
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Thorsten Scherler wrote:
> Right now in the menu we can decide when and which item to show. I agree
> that the xsp approach needs rethinking but why not use jx instead. This
> would make it possible to keep presentation logic in an easy way. From
> my experience xsl it is not very suitable to implement presentation
> logic which are based on java objects.
i must confess i don't like jx very much... its control structures are
totally crippled and every non-trivial operation requires offloading to
java code, even if it is just view-related and thus be in the template
code....
> The menu should be independent from the main aggregation. Actually the
> whole main aggregation
> <map:part
> src="cocoon:/navigation-element/breadcrumb/{2}/{3}/{5}/{6}/{7}"/>
> <map:part src="cocoon:/navigation-element/tabs/{2}/{3}/{5}/{6}/{7}"/>
> <map:part src="cocoon:/navigation-element/menu/{2}/{3}/{5}/{6}/{7}"/>
> <map:part src="cocoon:/navigation-element/search/{2}/{3}/{5}/{6}/{7}"/>
> <map:part
> src="cocoon://modules/languageselector/text-none/flagsize-13"/>
>
> should be done in a more flexible way via a template that will get the
> parts it needs. This way it would be as well possible to extend it more
> easy without touching the sitemap.
+1
> Further it would be possible to have url specific extension of extra
> content and/or extra functionality. Imagine I do not want the breadcrumb
> or the lanuageselector on some pages but on other I do. Now I always get
> this parts, paying the price that Dominique has described.
let's be careful not to stash too much into the URL space.... the
flexibility would be a bonus, but awkward URLs can be a problem. plus if
we export too many internal features to the outside via URLs, we might
open ourselves to exploits and DoSes.
for instance, the SVG flag rendering is a potential DoS already, because
it's so expensive in terms of cpu cycles. we need to avoid a situation
where a malicious site visitor can trigger all kinds of cpu hogs by
tinkering with the request URL.
--
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2007-05-09 at 23:01 +0200, Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
> > Joern Nettingsmeier schrieb:
...
> > Our menu is a special case - it has a basic structure (which XML is
> > fine for), but there's some logic to control the details. We have to
> > find a way to separate these aspects, maybe by introducing a generic
> > mechanism to show/hide/enable/disable menu items.
>
> hmm. especially for trivial things such as menu enabling/disabling, xsl
> is suited fine. and i'm quite sure the menu2xhtml can be simplified *a
> lot*. most of the confusion in there comes from our URL handling problems.
>
Right now in the menu we can decide when and which item to show. I agree
that the xsp approach needs rethinking but why not use jx instead. This
would make it possible to keep presentation logic in an easy way. From
my experience xsl it is not very suitable to implement presentation
logic which are based on java objects.
Further if we switch from xsp to jx we can reuse the pipelines for now
since we would just switch the way how we call it.
To the xsl generating xsl I once had done a similar thing in the
dispatcher but then wrote a custom transformer since this reduces
complexity of the code and put it into one java component.
If we break down the menu generation process like:
1) Core looks up all menu extensions from the module and aggregate them
in one file (done once since from there we can use the cached match).
[1a] optional: filter the menus that are not needed for the publication
2) Url specific filter which connects the menu file and gets all menus
that are needed. Returning a subset of menus and pass it to the next
step.
3) Populate the file from step 2 with java objects that are in the
request.
Where 1 is a match of its own (for caching reasons) and 2 and 3 in one
match.
The menu should be independent from the main aggregation. Actually the
whole main aggregation
<map:part
src="cocoon:/navigation-element/breadcrumb/{2}/{3}/{5}/{6}/{7}"/>
<map:part src="cocoon:/navigation-element/tabs/{2}/{3}/{5}/{6}/{7}"/>
<map:part src="cocoon:/navigation-element/menu/{2}/{3}/{5}/{6}/{7}"/>
<map:part src="cocoon:/navigation-element/search/{2}/{3}/{5}/{6}/{7}"/>
<map:part
src="cocoon://modules/languageselector/text-none/flagsize-13"/>
should be done in a more flexible way via a template that will get the
parts it needs. This way it would be as well possible to extend it more
easy without touching the sitemap.
Further it would be possible to have url specific extension of extra
content and/or extra functionality. Imagine I do not want the breadcrumb
or the lanuageselector on some pages but on other I do. Now I always get
this parts, paying the price that Dominique has described.
wdyt?
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier schrieb:
>>> Andreas Hartmann wrote:
>>>> Joern Nettingsmeier schrieb:
>>>>> i think you may be a little biased against xslts...
>>>> I used to like it a lot, and I still like it for certain purposes, but
>>>> it tends to get in your way when you try to increase the performance.
>>> i don't really buy that argument. granted, the best way to make an xslt
>>> fast is not to do it (again). but since menus don't change much, there's
>>> a lot of room for optimization. i don't think menu transformations are a
>>> performance bottleneck atm, and cocoon is all about pipeline caching.
>>
>> The state of the menu items has to be computed for every request,
>> since it depends on the AC permissions and the current state of
>> the document. I don't think there's much to cache.
>
> true. i was already dreaming of ajax :)
That would certainly be an option, we could make the calls only
when the drop-down menu is opened.
> still, until i have run a few benchmarks, i'm not convinced that the
> performance bottleneck is in the XSLT. i'd like to convert all input
> module calls to NOOPs and look at the timing differences...
I did quite a lot of profiling, most time seems to be eaten up by
pipeline processing and XSLT transformations. Even checking the
cache validity needs a significant amount of time.
>>>> IMO XML is good for data, but not for the description of processes.
>>> can't see why. can you give me an example of a domain-specific language
>>> that can't be done in XML?
>>
>> The question is not if it can be done, but if it is comfortable
>> to work with.
>
> but that depends on the semantics of the language, and only marginally
> on the syntax.
>
> maybe your discomfort is caused by XSL?
> much of the awkwardness of XSL comes from the fact that it's an
> event-based functional language (which sure takes some getting used
> to...),
Well, the declarative nature makes it perfect for transformations
of structured data. But (without extension functions) it is not suitable
for serious computations.
> and that it includes a second syntax (XPath) for addressing.
> it's not a consequence of the XML format it's represented in.
>
>>>> Our menu is a special case - it has a basic structure (which XML is
>>>> fine for), but there's some logic to control the details. We have to
>>>> find a way to separate these aspects, maybe by introducing a generic
>>>> mechanism to show/hide/enable/disable menu items.
>>> hmm. especially for trivial things such as menu enabling/disabling,
>>
>> It's not really trivial - you might have to access data about the
>> document, the current session etc. A simple example - you want to
>> enable/disable a menu item depending on the return value of a method
>> call. You can't do this in XSLT easily.
>
> well, you could. saxon for instance has a very slick java extension
> mechanism. but i'm not really advocating it - it would mix stuff that
> should stay separate.
Extension functions create a lock-in effect. I use them in customer
projects, but we should keep them out of the open source project
if possible.
> the way i would tackle the issue is to have a generator that exports all
> needed information as XML, which should have a lot less overhead that
> the 10 or so input modules we are calling now,
Why would that be the case? Maybe optimizing the modules would also
help.
And with JX templates, you won't need the modules anymore because
you can access the services directly from the template.
> each with the whole avalon shebang attached to it.
I don't think that the service selection and setup is a really
significant factor here.
> with an XML snippet, it's just a matte of picking out the information,
> and that's where XSL can shine.
We had that earlier - the infamous page envelope. Every piece of
information that could potentially be needed was passed into the
presentation chain as XML. This is very expensive up front. Input
modules improved the situation.
> i still believe that the fundamental interface between java core and
> sitemaps should be xml,
I don't think so, this approach has proved wrong.
> and not those many little text snippets we now produce.
They allow to produce particular information on demand.
But doing this in templates would be even better.
> that's where our complexity comes from, and i'm sure that's
> also burning a lot more cycles than strictly necessary.
>
>>>> XML has its fields of application. But I wouldn't like to implement
>>>> an OS core in an XML-based language :)
>>> gotcha: you wouldn't want to implement an OS core in java either. :-D
>>
>> True, but that's not a pro-XML argument :)
>
> no, it just shows that your initial point is not particulary waterproof.
>
> you could easily express C in XML. it does not make much sense, because
> the plain-text representation of C is a user-interface (the programmer
> interacts with the compiler) and needs to be nice because people have to
> type huge amounts of code.
Exactly, XML is not a markup which is particularly suitable for humans.
> if the code were machine-generated, it wouldn't make much difference.
> and if you only needed short snippets of C code, it wouldn't make much
> difference either.
> sitemaps are small. and if they're awkward, that's because of
> inconsistencies and lack of powerful control structures, not because of
> its tree structure or the angle brackets...
Yes, there are certainly more important aspects than the difference
between angle and curly brackets.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier schrieb:
>> Andreas Hartmann wrote:
>>> Joern Nettingsmeier schrieb:
>>>> i think you may be a little biased against xslts...
>>> I used to like it a lot, and I still like it for certain purposes, but
>>> it tends to get in your way when you try to increase the performance.
>> i don't really buy that argument. granted, the best way to make an xslt
>> fast is not to do it (again). but since menus don't change much, there's
>> a lot of room for optimization. i don't think menu transformations are a
>> performance bottleneck atm, and cocoon is all about pipeline caching.
>
> The state of the menu items has to be computed for every request,
> since it depends on the AC permissions and the current state of
> the document. I don't think there's much to cache.
true. i was already dreaming of ajax :)
still, until i have run a few benchmarks, i'm not convinced that the
performance bottleneck is in the XSLT. i'd like to convert all input
module calls to NOOPs and look at the timing differences...
>>> IMO XML is good for data, but not for the description of processes.
>> can't see why. can you give me an example of a domain-specific language
>> that can't be done in XML?
>
> The question is not if it can be done, but if it is comfortable
> to work with.
but that depends on the semantics of the language, and only marginally
on the syntax.
maybe your discomfort is caused by XSL?
much of the awkwardness of XSL comes from the fact that it's an
event-based functional language (which sure takes some getting used
to...), and that it includes a second syntax (XPath) for addressing.
it's not a consequence of the XML format it's represented in.
>>> Our menu is a special case - it has a basic structure (which XML is
>>> fine for), but there's some logic to control the details. We have to
>>> find a way to separate these aspects, maybe by introducing a generic
>>> mechanism to show/hide/enable/disable menu items.
>> hmm. especially for trivial things such as menu enabling/disabling,
>
> It's not really trivial - you might have to access data about the
> document, the current session etc. A simple example - you want to
> enable/disable a menu item depending on the return value of a method
> call. You can't do this in XSLT easily.
well, you could. saxon for instance has a very slick java extension
mechanism. but i'm not really advocating it - it would mix stuff that
should stay separate.
the way i would tackle the issue is to have a generator that exports all
needed information as XML, which should have a lot less overhead that
the 10 or so input modules we are calling now, each with the whole
avalon shebang attached to it.
with an XML snippet, it's just a matte of picking out the information,
and that's where XSL can shine.
i still believe that the fundamental interface between java core and
sitemaps should be xml, and not those many little text snippets we now
produce. that's where our complexity comes from, and i'm sure that's
also burning a lot more cycles than strictly necessary.
>>> XML has its fields of application. But I wouldn't like to implement
>>> an OS core in an XML-based language :)
>> gotcha: you wouldn't want to implement an OS core in java either. :-D
>
> True, but that's not a pro-XML argument :)
no, it just shows that your initial point is not particulary waterproof.
you could easily express C in XML. it does not make much sense, because
the plain-text representation of C is a user-interface (the programmer
interacts with the compiler) and needs to be nice because people have to
type huge amounts of code.
if the code were machine-generated, it wouldn't make much difference.
and if you only needed short snippets of C code, it wouldn't make much
difference either.
sitemaps are small. and if they're awkward, that's because of
inconsistencies and lack of powerful control structures, not because of
its tree structure or the angle brackets...
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Joern Nettingsmeier schrieb:
>>> i think you may be a little biased against xslts...
>>
>> I used to like it a lot, and I still like it for certain purposes, but
>> it tends to get in your way when you try to increase the performance.
>
> i don't really buy that argument. granted, the best way to make an xslt
> fast is not to do it (again). but since menus don't change much, there's
> a lot of room for optimization. i don't think menu transformations are a
> performance bottleneck atm, and cocoon is all about pipeline caching.
The state of the menu items has to be computed for every request,
since it depends on the AC permissions and the current state of
the document. I don't think there's much to cache.
[...]
>> IMO XML is good for data, but not for the description of processes.
>
> can't see why. can you give me an example of a domain-specific language
> that can't be done in XML?
The question is not if it can be done, but if it is comfortable
to work with.
>> Our menu is a special case - it has a basic structure (which XML is
>> fine for), but there's some logic to control the details. We have to
>> find a way to separate these aspects, maybe by introducing a generic
>> mechanism to show/hide/enable/disable menu items.
>
> hmm. especially for trivial things such as menu enabling/disabling,
It's not really trivial - you might have to access data about the
document, the current session etc. A simple example - you want to
enable/disable a menu item depending on the return value of a method
call. You can't do this in XSLT easily.
>> XML has its fields of application. But I wouldn't like to implement
>> an OS core in an XML-based language :)
>
> gotcha: you wouldn't want to implement an OS core in java either. :-D
True, but that's not a pro-XML argument :)
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Joern Nettingsmeier schrieb:
>> i think you may be a little biased against xslts...
>
> I used to like it a lot, and I still like it for certain purposes,
> but it tends to get in your way when you try to increase the
> performance.
i don't really buy that argument. granted, the best way to make an xslt
fast is not to do it (again). but since menus don't change much, there's
a lot of room for optimization. i don't think menu transformations are a
performance bottleneck atm, and cocoon is all about pipeline caching.
dominique has identified some real problems with the sitetree, and i
guess the huge number of input modules per xslt that we currently call
for parameter passing might be another one, but i haven't done any
metrics yet.
but i don't think that xslt per se is our bottleneck. we might be doing
too many transformations, though.
>> 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).
>
> IMO XML is good for data, but not for the description of processes.
can't see why. can you give me an example of a domain-specific language
that can't be done in XML?
> Our menu is a special case - it has a basic structure (which XML is
> fine for), but there's some logic to control the details. We have to
> find a way to separate these aspects, maybe by introducing a generic
> mechanism to show/hide/enable/disable menu items.
hmm. especially for trivial things such as menu enabling/disabling, xsl
is suited fine. and i'm quite sure the menu2xhtml can be simplified *a
lot*. most of the confusion in there comes from our URL handling problems.
>> 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...
>
> XML has its fields of application. But I wouldn't like to implement
> an OS core in an XML-based language :)
gotcha: you wouldn't want to implement an OS core in java either. :-D
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier schrieb:
[...]
>> 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...
I used to like it a lot, and I still like it for certain purposes,
but it tends to get in your way when you try to increase the
performance.
> 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.
+1
>>> 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?
Domain-specific languages
> 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).
IMO XML is good for data, but not for the description of processes.
Our menu is a special case - it has a basic structure (which XML is
fine for), but there's some logic to control the details. We have to
find a way to separate these aspects, maybe by introducing a generic
mechanism to show/hide/enable/disable menu items.
> 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...
XML has its fields of application.
But I wouldn't like to implement an OS core in an XML-based language :)
> i think the evil thing about sitemaps are the many custom components.
> the core sitemap language needs to be more powerful...
Yes, that's an important point. Virtual pipeline components could
improve this a lot.
[...]
>>> 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.
You got me there, that's really a broken-window issue.
But it's a long way to go, and we have to get 1.4 out ...
> "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'm afraid I don't know it well enough, otherwise I could help with the
proxy issue :)
Most things I know are in the docs:
http://lenya.apache.org/docs/1_4/concepts/urlMapping.html
http://lenya.apache.org/docs/1_4/reference/link-management.html
> 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.
+1
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: proxying woes...
Posted by Andreas Hartmann <an...@apache.org>.
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org