cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: Woody-flow to FOM migration question
Date Sat, 19 Jul 2003 13:43:19 GMT
On Sat, 2003-07-19 at 06:00, Christopher Oliver wrote:
> >Another problem I stumbled onto: Woody needs to be passed the Request
> >object (as part of the FormContext object but that doesn't matter now).
> >As is well known, flowscript doesn't give access to this. Looking at
> >JXForm again, I see again a similar workaround. I could do the same for
> >Woody of course, but it all starts to feel a bit unnatural...
> >
> The Request and other such objects are made available to Java code, but 
> not to JS. I don't know if that's unnatural...

Actually, I've become used to the idea now (JS allows limited access --
if you need to do more you can go via Java). It was suprising at first
that a Java class created and called from the flowscript was able to
access stuff that the flow itself didn't have access to.

> >Then on a less related note: I noticed that the JXForm class uses the
> >Environment. Wasn't this interface supposed to be internal to Cocoon (I
> >don't consider a block to be Cocoon internals)? Maybe we should limit
> >the public interface of the FOM_Cocoon class?
> >
> >  
> >
> I wasn't aware of the status of Environment. It's there simply because 
> it was in the original flow implementation. It should be easy enough to 
> only expose the features of Environment that are needed ( getURIPrefix() 
> and getObjectModel()) rather than the entire object. I don't think 
> FOM_JavaScriptInterpreter should be exposed either. I'll try to make 
> these changes.

ok.  Is getURIPrefix() really needed? It seems like this is added always
when forwardTo() is called, so maybe it can be hidden in the
implementation of forwardTo?



Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message