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
