Leszek Gawron dijo:
> On Sat, Apr 17, 2004 at 11:28:00AM -0700, Christopher Oliver wrote:
>> I think you can use a combination of session attributes and jx macros to
>> get the effect you want, e.g.
>>
>> // Flow script
>>
>> function toSAX(str, consumer) {
>> ...
>> }
>>
>> cocoon.session.setAttribute("stringToSAX", toSAX);
>>
>> function myPage() {
>> ...
>> sendPage("page.html", {...});
>> }
>>
>> // template
>>
>> <jx:macro name="output-xml">
>> <jx:parameter name="value">
>> <jx:set var="ignored" value="${cocoon.session.stringToSAX(value,
>> cocoon.consumer)}">
>> </jx:macro>
>>
>> Since both Flow script (cocoon.load()) and JXTemplateGenerator
>> (<jx:import/>) support including other files you can factor such code
>> into supporting "library" files and include them in your application
>> code.
> Another thought:
>
> Let me bring you an example (concerning SoC and software clarity) that
> Stefano
> brought up today:
>
> <citation>
> <flow language="javascript">
> <script src="sortOrder.js"/>
> </flow>
>
> <match pattern="table.html">
> <call function="getSortOrder"/>
> </match>
>
> <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!
> now assume you have your flowscript variable homePath set in the top level
> script:
>
> var homePath ="/myDirectory/myApplication";
>
> you need this value to be seen by both generated views (JXTG) and
> stylesheets -
> they both may create links to application screens.
>
> JXTG first. using your solution you insert homePath into user's session
> and
> access it via ${cocoon.session.homePath}
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.
> 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.
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.
Best Regards,
Antonio Gallardo
