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 Sun, 22 Jun 2003 11:37:18 GMT
Stefano Mazzocchi wrote:
> 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
haul@informatik.tu-darmstadt.de
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


Mime
View raw message