************************************************************** * FOM (Flow Object model) * **************************************************************
Context object --------------
--parameters-- getInitParameter(name)
If I interpret this correctly you would provide the web.xml parameters as properties. Another possibility would be the attributes. Stefano, what do you think?
IMHO it would be nice to access values like init parameters in a uniform way. That is what the input modules are all about. Therefore I would prefer to drop this and make it available through a module instead. Even though this entails an additional component lookup.
IMHO the same is true for
Session object --------------
Cookie object -------------
Environment object ------------------ Question on the environment: Currently the sendPage functions are implemented using Cocoon.environment:
this.cocoon.forwardTo("cocoon://" + this.cocoon.environment.getURIPrefix() + uri, bizData, wk);
How can we implement this without the environment object?
Additinally the method cocoon.forwardTo( uri, bizData, wk) is not available too!
Why would it be difficult to not expose environment but still have it available for the methods? Sorry if I am super dumb but I haven't looked at the actual implementation for a while.
************************************************************** * Component loading * **************************************************************
I see two different types of components in Cocoon today:
1) general components (example: SaxParser) 2) sitemap components (example: FOPSerializer)
I think the flow should have access only to the first family.
Fine. Although I don't see the possible abuse here.
************************************************************** * statefull components - how to release them? * **************************************************************
Sylvain:
1/ raise an error if there are some unreleased stateful components
Until we fully understand this I would go with the above.
************************************************************** * Flow and sessions * **************************************************************
Note to the vote:
+++++++++++++++++
So I think we could vote on the current implementation or can anybody come up with a use case that is not covered with the current implementation?
Fine.
************************************************************** * Map callAction(name,map) * **************************************************************
Note to the vote: +++++++++++++++++ Okay, this will be a simple yes/no question.
I believe everything is said about this one. It's OK to remove this and augment those actions that may still be of use with an additional entry point. Won't be many actions that qualify, I believe.
************************************************************** * Continuations Object * **************************************************************
Note to the vote: +++++++++++++++++ This is a simple yes/no question too.
I don't see the harm but the potential creative uses, so I'm in favour of keeping it.
************************************************************** * Modules (input/output) * **************************************************************
Stefano:what modules?
I meant the input and output modules. I think there is information available in input modules (e.g. static global parameters) that could be useful within flows.
Output modules could be useful too. But maybe Christian could come up with more detailed explanations.
Well, I feared this :-| First off: There is absolutely no *need* to have those.... however, they provide _uniform_ access to a lot of stuff that is often needed and what more.
So the trade off here is to have uniform access and encapsulation versus additional indirection. IMO we should remove direct access to those sources and require to go through modules.
The access is not only uniform across the source but also throughout cocoon since the modules are available in many places.
The current API is not complete and it would be nice to make it a little more ECMAscript like e.g.
var foo = Cocoon.input["request-attr"]["foo"]
or
var foo = Cocoon.input["request-attr"].get("foo")
.getArray("foo")
.output["request-attr"].set("foo")
.output["request-attr"].commit()
.output["request-attr"].rollback()
Obviously the last two may fuel endless arguments and show that the first use case was database access. I would perceive this as a additional discussion than the general module issue.
************************************************************** * Script load support * **************************************************************
Note to the vote: +++++++++++++++++ Simple question: Do we support the load() function within scripts?
Indifferent on this.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08