You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Per-Olof Norén <pe...@alma.nu> on 2002/09/06 13:26:07 UTC

Re: Flow status and report. [PATCH]

Hi,
See my comments below

Ovidiu Predescu wrote:
> Hi Per-Olof,
> 
> On Tuesday, September 3, 2002, at 02:08 AM, Per-Olof Norén wrote:
> 
>> Hi cocooners,
>> I´d like to give a real-life scenario using flowscripts.
>> We are currently in the end phase of developing the base of an 
>> enterprise system used for ordering/invoicing/crm tasks.
>> All of this is done in cocoon using the flowscript and Jakarta OJB, 
>> Axis   and torque.
>>
>> We decided to use the flowscript since its *the* way of creating web 
>> based, data-intensive business systems. In theese scenarios the focus 
>> are at error handling and usability. The gui is of course important 
>> but not in the "flashy" sence, but rather that its possible to work 
>> with the system for a whole work-day.
>>
>> Model: OJB
>> View: XSP´s
>> Controller: flowscript
>>
>> The Model:
>> Trying the axis wsdl2java tools to connect to SOAP services was as 
>> easy as stealing candy from a child, not a single problem.
>> This inspired us to look for a similar approach when using a local 
>> dbms for the other data. After some looking around we found OJB to be 
>> perfect. We modified the Ant tasks that reads db metadata and creates 
>> a file called repository.xml that is the database schema. The next ant 
>> task is to create beans for each table in the repository.xml file. 
>> This is done by velocity templates. Finally an "Operations" interface 
>> is created by hand. This interface class is then used by the flowscript.
>> Its incredible easy to modify the database, we just run our ant build 
>> that rebuilds all our beans. Using axis we can also wrap our 
>> "Operations" interface as a web service for future integration.
>>
>> The views:
>> We created a sort of language for page definition that abstracted html 
>> in xsp´s and this allows hard core coders to create pages that
>> are graphically pleasing. The concept of xsp as the source of the 
>> pages is perfectly fine, since it allows for some rendering logic to 
>> be applied. For example disabling buttons and parts of a page.
>> All data is provided in a java.util.Hashmap sent from the flowscript.
>>
>> The controller:
>> This is of course the flowscript.
>> In here we program the flow-logic and call the Model(Operations 
>> interface) for retrieving / updating / creating data.
>> We´ve devided some common functions such as showing error messages and 
>> delete confirms into "functions.js".
>>
>> To summarize:
>> Using flowscript, xsp and OJB is the *perfect* match for creating 
>> web-based enterprise systems
> 
> 
> This is great stuff!
> 
> I discovered OJB recently and I was investigating it to see how it 
> compares with Castor JDO. I was planning to start building a similarly 
> complex application using the flow and OJB or Castor.
> 
> It would be really great if you can make a simple example out of your 
> code, so it can be packaged with Cocoon as a demonstration of the 
> control flow layer.
> 
>> Since this is the dev list, i also have som dev questions:
>> I have problems putting things in a session variable from the 
>> flowscript using this syntax: cocoon.session["user_id"] = 
>> user.getUser_id();
> 
> 
> I've recently checked in some changes in the control flow which allows 
> you to create sessions from the flow layer. The idea is to maintain the 
> state of the global variables across different top-level function 
> invocations. E.g. suppose you have two functions, login() and 
> addToCart(), which look like this:
> 
> var user;
> 
> function login()
> {
>   // send the appropriate pages to the user to have the user log in
>   user = new Package.com.my.application.User(username, password, ...);
> 
>   // create a user session to preserve the value of the global variables
>   cocoon.createSession();
> }
> 
> function addToCart()
> {
>   if (user == null)
>     login();
> 
>   // make use of the 'user' global variable
> }
> 
> In this example, both login() and addToCart() are functions that can be 
> called from the sitemap using <map:call function="..."/>. The value of 
> all the global variables is essentially preserved, once the 
> createSession() function is called.
> 
> I'll commit an example of this feature. Using this, you no longer have 
> to maintain things in the servlet session object, just make your 
> 'userId' a global variable in your flowscript, and make sure you call 
> createSession() in one of the functions called earlier in the process.
> 
>> Does anyone have any idea´s?
>>
>> I will soon send a little patch for jpath.xsl that fixes for-each 
>> functionality that we use.
> 
> 
> Please do so. I also have some changes to the logicsheet to fix some 
> compilation errors when the same expression is used multiple times 
> throughout an XSP.

Attatched is our entire jpath.xsl, which fixes iterator problems and 
also compile some of the compile problems.

There is another problem however:
jpath namespace declaration have to be the last one on the xsp:page 
element, or otherwise there are compile problems. My guess is that there 
is some missing apply-templates or something (haven´t had time to really 
dig into xsp).

Will try to package an example of how we used xsp, javascript to create 
really cool applications the extrem easy.





> 
> I'll commit the changes described above and my little example soon.

Cool





Re: Flow status and report. [PATCH]

Posted by Ovidiu Predescu <ov...@apache.org>.
On Friday, September 6, 2002, at 04:26 AM, Per-Olof Norén wrote:

> Attatched is our entire jpath.xsl, which fixes iterator problems and 
> also compile some of the compile problems.

OK, I identified where your changes were and incorporated the 
applicable ones in the new version of the stylesheet. Please get the 
latest version from CVS and work with it in your application, and let 
me know if you see any problems.

> There is another problem however:
> jpath namespace declaration have to be the last one on the xsp:page 
> element, or otherwise there are compile problems. My guess is that 
> there is some missing apply-templates or something (haven´t had time 
> to really dig into xsp).

Do you have custom logicsheets which you use in your XSPs? I've tried 
changing the position of the jpath namespace in one of my pages, but 
everything works fine.

> Will try to package an example of how we used xsp, javascript to 
> create really cool applications the extrem easy.

This would be really great!

Best regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, 
Emacs ...)


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org