Torsten Curdt wrote:
So I think we should clearly separate the FOM (the JS wrapper of the OM) from the FAPI, the flowscript API which gathers flowscript-related utility functions by attaching them for a new "flowscript" object.
We would therefore have:
- cocoon.request, cocoon.context, cocoon.mymodule, etc.
- flowscript.sendPageAndWait(), flowscript.getComponent(), flowscript.redirect(), etc.
sounds good to me ...one tiny thing though: I'd prefer the name "flow" ...so
flow.sendPageAndWait(), flow.getComponent(), flow.redirect()
With javaflow the whole "script" naming scheme does not really fit ...even if you get a script-like behaviour with the compiling classloader ...IMO
WDYT?
You're falling in the same trap again ;-)
Why should the flowscript API and javaflow API be the same? In javaflow, you have access to Avalon-related data such as the service manager and therefore don't need flow{script}.getComponent().
So the FSAPI (flowscript API) should be defined separately from the JFAPI (javaflow API), even if they share some concepts and/or function names related to the fact that they both manage flow, such as sendPageAndWait().
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
