cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Mon, 19 Apr 2004 09:44:59 GMT
Stefano Mazzocchi wrote:
> I believe that inputmodules/outputmodules do already pose a significant 
> complexity to the clean separation.

Care to explain and examplify why you believe so?

I would certainly agree about that some of the modules; the meta 
modules, the database modules and the output modules are overkill, and 
that you don't need them when you have flowscripts, (I didn't need them 
before either, but that depends of course on what kind of apps you write 
and on your prefered style). So if you want to depreciate these stuff 
I'm +1.

I believe OTH that some of the "simpler" input modules, especially the 
request module, the request attribute module and the flow attribute 
module, makes it possible to have a *cleaner* SOC, than it is possible 
without them. Let me give a simple example:

<match pattern="table.html">
   <generate src="table.xml"/>
   <transform src="table2html.xsl">
     <parameter name="sortOrder" value="{request-param:sortOrder}"/>

First, the content of the table and the sort order in the view of it is 
clearly separate concern areas so I would definately not like to insert 
the sort order parameter in the "content" with jxtg or something like that.

Now I could transfer the request parameter implicitly to the xslt 
processor by turning on the "use-request-parameters" in the trax 
transformer. But by doing that I lose info in the sitemap about what 
external parameters the sitemap rule depends on. When I return to old 
apps or apps written by other developers I find it easier to understand 
them if the dependencies on e.g. request params are explicitely 
"declared" in the sitemap. It is also gives you controll over caching.

> I think input modules *are*not* 
> necessary once you have a clearly defined way for flow to pass 
> parameters to the sitemap.

There is a clearly defined way to pass flow params to the sitemap: 

I don't think that the "necesity" argument is that relevant. What counts 
is that we should have mechanisms that makes it easy to write web-apps 
in a way that gives a clear SOC.

I fail to see that:

<flow language="javascript">
   <script src="sortOrder.js"/>

<match pattern="table.html">
   <call function="getSortOrder"/>

<match pattern="table-view">
   <generate src="table.xml"/>
   <transform src="table2html.xsl">
     <parameter name="sortOrder" value="{flow-attribute:sortOrder}"/>


function getSortOrder() {
            {"sortOrder": cocoon.request.attibute.sortOrder}

would be an improvement in clearity compared to using input modules, 
(now I used the flow attribute module, as I don't know about the new 
mechanism for passing flow attributes that you refer to above). Of 
course, if you want to insert data in the sitemap that requires more 
programming than just accessing an attribute value, it is probably 
better to do that in flowscripts than by using complicated 
configuratioons for meta modules. But that is IMO an argument for 
deprecate some of the more "complicated" modules rather than taking them 
away completely.

                           --- o0o ---

So to sumarize my position: I believe that having read access to 
attributes in the request object and flow attributes in the sitemap 
impoves the SOC and clearity in sitemap, more complicated use of modules 

                           --- o0o ---

An alternative to input modules that would fullfill my requirements, 
would be to have a mechanism in the flow processor that gives access to 
(possibly a subset of) the readable attributes in the flow object model. 
If we factored out that from the flow object model, we could have a 
common model for what should be readable from cocoon by the user; for 
flowscripts, the sitemap and maybe in other places like in the bsf 
generator. The access language for this "Cocoon object model" in the 
sitemap could be the same as for input modules to keep back compability. 
By doing something like that we could remove the possible FS about 
modules and remove the need for configuring them.

Is it something like this that you have in mind when you want scrap the 
input modules?

> I do understand this is radical and i'm open for constructive criticism, 
> but please come up with examples to show me why you really need 
> inputmodules.

See above.

> And yes, I still believe in the pyramid of contracts, even more than in 
> the past, but the sitemap is not enough, we need something else, we 
> can't write script in XML.

I think we have two separate concerns here. The first is if something 
would be "natural" to put in the sitemap. The other is the question 
about XML and scriptabillity. IMO, if we think that the sitemap should 
be extended with something that requires scripting, but we can't do that 
because the sitemap is XML and "thou shall never do scripting in XML". 
Then we should maybe find a new non-XML syntax for the sitemap. The 
sitemap is one of the few document types that I never have felt any urge 
to apply XSLT on ;) So I wouldn't have anything against a more readable 



View raw message