cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Spoerri <j...@basit.com>
Subject Re: xsl params deficient !
Date Fri, 18 Aug 2000 09:24:32 GMT
On Fri, Aug 18, 2000 at 06:44:54PM +0100, Robin Green wrote:
> >so now we're stuck with either the xsl knowing about all of parameters
> >of the xml (so that _it_ can build the "next page" link), or else the
> >xml knowing about this pageN parameter so that it can strip it out.
> 
> I would recommend the latter. The job is better suited for XSP, especially 
> if the page can be requested either through GET or POST, which complicates 
> the issue somewhat - and it works for us.

this is actually what i'm currently using, because i didn't get around to
writing the generic doo-dad i described. i think that using such a doo-dad
should be the standard way of doing this.

having the xsp pass a munged query string is gross, because the feature
is really implemented entirely in xsl. it breaks clean separate of layers.

it is entirely possible that i might not have implemented the paging feature,
and rather an unaffiliated user might want to implement it, and make the
translation in his browser. does he somehow have to use an xsp proxy?


> >it's evil: mixing of content and presentation.
> 
> I wouldn't say that. An URL is not really part of the presentation - it is 
> not directly displayed to the user. And this (avoiding duplicate parameters) 
> is not the kind of thing that a non-programmer web designer would want to 
> get their hands dirty with, I don't think. It's a logic issue, really.

xsl itself is not something that a non-programmer web designer would want
to get their hands dirty with.

i assert that the separation of content and presentation is not solely about
splitting authoring roles (programmer and designer), but about splitting
layers of information (raw data and its visual embellishment).

so xsl should have tools to do it right. it translates xml based on any part
of the xml data tree. why should user inputted data be a second class citizen?
why should it be restricted to the puny param?

> Indeed - this is the sort of thing that a generalised FP-type taglib would 
> be good for.

where can i find information regarding the fp taglib?
i suppose its in the cocoon2 cvs? is there any additional documentation?
does it run under cocoon1?

btw, thanks for your other help with learning cocoon.

josh

Mime
View raw message