cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@informatik.tu-darmstadt.de>
Subject Re: [Flow] Preparing the vote - long!
Date Fri, 20 Jun 2003 19:01:10 GMT
Reinhard Pötz wrote:

> **************************************************************
> * 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
haul@informatik.tu-darmstadt.de
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


Mime
View raw message