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 // \\
\_\\ //_/ [EMAIL PROTECTED] _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
