cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per-Olof Norén <pe...@alma.nu>
Subject Re: Flow status and report. [PATCH]
Date Fri, 06 Sep 2002 11:26:07 GMT
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





Mime
View raw message