cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <o...@wlkp.org>
Subject Re: flowscript bizData "AOP"
Date Mon, 19 Apr 2004 10:53:39 GMT
On Mon, Apr 19, 2004 at 04:28:52AM -0600, Antonio Gallardo wrote:
> > <match pattern="table-view">
> >   <generate src="table.xml"/>
> >   <transform src="table2html.xsl">
> >     <parameter name="sortOrder" value="{flow-attribute:sortOrder}"/>
> >   </transform>
> >   <serialize>
> > </match>
> >
> > sortOrder.js:
> >
> > function getSortOrder() {
> >   sendPage("table-view",
> >            {"sortOrder": cocoon.request.attibute.sortOrder}
> > }
> > </citation>
> 
> Maybe I am too much DB oriented guy. I prefer to let DB Engine make what
> they do the best: retrieve, store and sort data. DB easily kick any Java
> or XSLT techno in ther own stuff!
Yeah but that was only the example of a variable/constant that has to be
passed from flow to transformer

> JXTG can get the values from flow. This is the way we work now. I am aware
> JXTG allow you to call Java code from inside, but we prefer to avoid that.
> Because from our POV it is not a "view" concern.
> 
> > Stylesheets: you have to pass a parameter to the stylesheet so you do :
> >
> > <match pattern="table-view">
> >   <generate src="table.xml"/>
> >   <transform src="table2html.xsl">
> >     <parameter name="homePath" value="{session:homePath}"/>
> >   </transform>
> >   <serialize>
> > </match>
> >
> > Cannot express it other like: this does not feel right. The use of session
> > looks like a workaround for me and for someone who would read my
> > application code it would look unclear.
> 
> What about using CInclude or Xinclude in the XSLT? That way you don't need
> to send the parameter at all.
Imagine you have a navigation.xml that defines your menu in some kind of
markup. Your menu2html.xsl has to have acces to some application
constants/variables.

> > There is another solution: use global sitemap variables. I also do not
> > like it at all.
> >   - you have to put some of your code into sitemap (I'd prefer to keep all
> >     the variables in flowscript)
> >   - you have to pass this value to the function/continuation call and set
> >     it every time they are invoked - ugly!
> >
> > I would really love something like you mentioned - another context at
> > cocoon
> > root like ${cocoon.applicationWideVariables.homePath}
> 
> Hmm.... the type of "variables" of the sample are in fact constants.
> Something like the handler name in auth-fw. They have a fixed value and
> never change at runtime.
i.e. currently logged in user is a variable and you need those for all views.

> 
> BTW, HomePath is not a good sample. Anyway, there are other ways to get it
> if you need. We try to make relatives links everywhere. That allow to
> deploy your application no matter where the client need it.
> As pointed before as they are in fact constant and not variables, you can
> use XInclude too.
I prefer to use absolute paths and set the root somewhere. It gives you much
more control if you have complicated URIs for example:

http://myhost/myapp/document/1/show. If you assume http://myhost/myapp/ is
your root the you have to link everything on this page to ../../somethingElse
because all scripts are "run" at http://myhost/myapp/ level. Your solution is
good if you use one level uris only.
	lg
-- 
            __
         | /  \ |        Leszek Gawron            //  \\
        \_\\  //_/       ouzo@wlkp.org           _\\()//_
         .'/()\'.     Phone: +48(501)720812     / //  \\ \
          \\  //  recursive: adj; see recursive  | \__/ |


Mime
View raw message