Mark Lundquist-2 wrote:
> 
>> Now i understood, that the flow-script is indeed  
>> javascript, but it only regulates the when which page will be called, 
>> yes server side, and  no, thats not where
>> the business logic is placed, that is in the jx-templates served by the
>> JXTemplateGenerator
> 
> Actually no.  Business logic doesn't belong anywhere near JXTemplates.
> 
> ...
> 
> Flowscript should be the bridge to your Java stuff (the business  
> logic).  You use flowscript to program the controller layer.
> 
>> So i expect now, that i can feed my java based backend into the
>> JXTemplateGenerator
> 
> No, not directly.  Flowscript calls your Java backend objects and  
> injects data from them into the presentation templates via calls to  
> cocoon.sendPage().  (The sendPage() is called on some resources that  
> maps to a pipeline that starts with JXTemplateGenerator).
> 
>> and that is almost where i want to get... The last bit i need is, how to  
>> introduce my own classes.
>>
>> I guess it is sufficient to pack them into a jar file and then  
>> simply adress
>> them out of the *.jx files ?
> 
> No, call them from flowscript.
> 
>> My classes already conform to beans, so they have getters and  
>> setters. is
>> that enough ?
> 
> I don't know, I guess it depends, see below.
> 
>> or do i have to register my classes as beans to spring ? well... i  
>> will see
>> ;-)
> 
> I like to use Spring to create a "services layer" object.  Spring  
> takes care of all the plumbing and initialization and finding things  
> or whatever has to happen to get that services layer fired up at  
> initialization time (e.g., the first time the flowscript is invoked).   
> Flowscript asks Spring for the services layer bean and then calls its  
> methods.
> 

ah... ok, so is the following picture correct ?

+++++++++++++++++++++++++++++++++++++
The preferred approach is as follows:

1.) Create a flowScript (e.g. main.js). 
In that flowscript prepare all data by accessing the relevant beans, 
possibly trigger calculations by calling bean-methods, 
and fetching the relevant data by accessing the bean getters.
Or simply instantiate java objects directly:

function myHelloFunction() 
{
   var now = java.util.Date();
   cocoon.sendPageAndWait("helloWorld.jx", { date: now } );
}

2.) and then in the jx-template page.jx: display what i get from flowscript:

<?xml version="1.0"?>
<html xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";>
  <head>
    <title>Hello flowscript</title>
  </head>
  <body>
    <h1>Hello world</h1>
    <h2>We are running at ${date} </h2>
    welcome to cocoon-flowscripts  
  </body>
</html>

========================

In principle i also could have written the flowscript:

function myHelloFunction() 
{
   cocoon.sendPageAndWait("helloWorld.jx");
}

and the jx-template:

<?xml version="1.0"?>
<html xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";>
  <head>
    <title>Hello flowscript</title>
  </head>
  <body>
    <h1>Hello world</h1>
    <h2>We are running at <jx:out value="${java.util.Date()}"/> </h2>
    welcome to cocoon-flowscripts  
  </body>
</html>

But this secnd (XSP-like) approach is evil, because:

i have to decide on the view layer, what data i want to display.
But the view layer shall never decide WHAT to display, 
but only HOW to display what has to be shown.
And that is why flowscripts have been invented...

So fetching the data from the flowscript is clearly preferred over fetching
the data from the jx-templates.
+++++++++++++++++++++++++++++++++++++++++++++++

Is that more or less a correct description of the nuts and bolts ?

regards, hussayn
-- 
View this message in context: 
http://www.nabble.com/How-can-i-activate-XSP-in-cocoon-2.2---tp19452293p19468587.html
Sent from the Cocoon - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to