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: [RANT] The Flow...
Date Wed, 05 Mar 2003 14:16:04 GMT
Christopher Oliver wrote:

> Pier Fumagalli wrote:
>
>>
>> Back to the drawing board, my fellow IDL editor at hands, and I start 
>> doing
>> one weird thing: converting the flow object model into IDL, as the 
>> current
>> JavaDOC output of JSCocoon and friends doesn't look "easy and nice",
>> preventing me to visually see if it's an implementation problem (all 
>> those
>> jsGet_whatever, jsSet_Something and jsFunction_Yadayada are making me go
>> nuts) or a more important and radical _design_ problem.
>>
>> Let me tell you one thing, after I wrote a couple of IDL interfaces, it
>> started to come out... It looks like there is no whatsoever OO-design 
>> behind
>> the flow object model, and that's the same feeling you get when you take
>> MSIE and try to make sense of its Jscript stuff.
>
>
> I don't think its quite as bad as you make out. The intended public 
> interface of Ovidiu's design is really quite simple and elegant. The 
> problem is that a lot of the apparent "interfaces" in JSCocoon.java 
> are really implementation details. Here is a pseudo-idl depiction of 
> the "real" public interface (Ovidiu, correct me if I'm wrong):
>
> interface Cocoon {
>
>   readonly attribute request;
>
>   void createSession();
>
>   void removeSession();
>
>   void sendPageAndWait(in string uri, in Object bean,
>                        in int timeToLive);
>
>   void sendPage(in string uri, in Object bean, in int timeToLive);
>
>   boolean process(in string uri, in Object object,
>                   in OutputStream stream);
>
> }


Ok,  just to put things in pespective:
Numerous threads have disussed  "integration" with the flow layer. There 
have been different approaches to the problem and theese solutions have 
evolved with the word "integration" in the back of peoples minds. This 
may have resulted in a not so very constistent OM.  
As I agree with Stefano and now Pier, about massaging an interface/OM 
that lasts, I think we should sum up all various scenarios that can 
occur using flow.
examples might be:
1. Interaction with authentication framework
    How to get the hands on attributes specified and should they be
2. Interaction with  business logic:

As I promoted in the flow O/R thread earlier, we are using the flow + 
OJB. To do this we have an Avalon Component wrapping the OJB 
PersistenceBroker (the low-level endpoint OJB used to retreive the java 
objects from db). From inside the flowscript the business data to be 
sent to the view (in our case an xsp) is loaded by asking COCOON´s 
component manager for our PersistenceManager (our wrapper uses a similar 
name to the OJB counterpart: PersistenceBroker).
This is obviously *not* the optimum way of doing this, one should not 
need to manipulate cocoon´s internal roles file to be able to locate and 
use the business-logic.

Mats Norén (my brother, btw :)) raised the question about the need for 
an alternative, possible block specific componentManager , a 
BusinessComponentManager (BCM)  that one use to call  the business-logic 
implemented in java and forward the resulting bean/beans to sendPage.

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104254063324113&w=2

So I´d think this intended interface is a little edgeless in terms of 
actually retrieving beans/data to send.
I propose the inclusion of a separate ComponentManager that flow can 
use. This ComponentManager should be set up/managed by the application 
builder.
The interface /OM should allow access to this manager for retreival of 
 business components and/or persistence mechanisms.


Regards,
Per-Olof Norén
Curalia AB




Mime
View raw message