On Sat, 2003-07-19 at 06:00, Christopher Oliver wrote: <snip> > >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. <snip> > > >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? Regards, Bruno -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
