on 6/20/03 2:01 PM Christian Haul wrote:
> 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.
Input modules were created with the pressure of the intrinsic low
programmability of the sitemap and shine in that context. With a clearly
defined FOM, are you sure that having yet another abstraction layer is
going to help us?
[snip]
>>**************************************************************
>>* 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.
Having access to sitemap components would allow the flow writer to
assemble pipelines at runtime, which is the closest thing I to abuse of
cocoon internals I can think of.
>
>
>>**************************************************************
>>* 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.
I would say the exact opposite and my reason is simple: we have one FOM,
while input modules are pluggable.
just like we agreed to keep one sitemap semantics, I don't see why we
should change course on the contract between the flow writer and the way
to get input data.
> The access is not only uniform across the source but also throughout
> cocoon since the modules are available in many places.
This is a valid point, even if I see the need of sitemap input modules
being lowered a lot with the advent of flow, and your point with it.
> 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.
I really don't see the value of input modules if we have FOM and general
avalon compoments, because, just like actions, if they contain useful
logic, this can be factored out in a general avalon component and called
by the flow.
Both actions and input/output modules were created to overcome sitemap
programmability limitations. Flow doesn't have those limitations anymore
so i don't see the reason to keep those artifacts here.
What do others think about this?
--
Stefano.
