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
They were created to prevent a starting combinatorial explosion of sitemap components, really. For example, we have wildcard matchers and regexp matchers, for request parameters, request headers, session attributes makes 6 matchers. Add request attributes makes 8... but we could do with 2 matchers and 4 modules.
defined FOM, are you sure that having yet another abstraction layer is going to help us?
The benefit is uniformness and indirection. Uniformness because o) all sources of are treated equal be it init parameters, configuration files, request attributes, request parameters, session attributes, attributes from the portal framework, whatever. We could introduce new objects into the FOM when the general need arises and hack our way in the meantime or have it plugable and clean. o) all those sources use the same interface: getAttribute(), getAttributeValues(), getAttributeNames(), no matter if they are originally called "attribute", "parameter", "header", "element" o) other places use already the same interface: transformers. sitemap, XSP logicsheet (input), actions
Indirection helps in two ways
o) ideally one would not use the predefined module names like
"request-attr" but create application specific ones. With a few key
strokes a different source is used. For example, use a XML file for
testing and use real headers for deployment.
o) when the application grows, perhaps you would like to keep your data
in a database instead of the session or in a remote object -- no
need to change anything in your script code, just replace the
module.In addition, to create a restricted version of the request object, it needs to be wrapped anyways. Why not use the existing wrappers?
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.
But reading a request parameter differs from reading a request attribute, or a request header, or an init parameter.
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.
I don't understand the analogy here, could you explain how this is related?
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.
Even with flow I see more and more very nice and elegant uses of modules in the sitemap. Very recent example: Virtual hosting uses different skins depending on the host. Solution:
<map:transform src="skins/{request:serverName}/skin.xsl"/>
Neat, isn't it.
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.
They are general avalon components. I would like to make it really easy to use them and not go through the lookup-cast-use-release-cycle including the exception handling. It's a little heavy in a script just to obtain a value or two :-)
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.
OTOH since cocoon is not restricted to be used as servlet, why is the FOM tied to it?
IMO the two approaches are quite similar. But I see additional benefits through the simpler interface and plugability for the modules. The modules approach does have short comings which I am certain could be solved easily given enough attention.
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