Stefano Mazzocchi wrote: <snip/>
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}"/>
</transform>
<serialize>
</match>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: {flow-attribute:foo}.
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"/> </flow>
<match pattern="table.html"> <call function="getSortOrder"/> </match>
<match pattern="table-view">
<generate src="table.xml"/>
<transform src="table2html.xsl">
<parameter name="sortOrder" value="{flow-attribute:sortOrder}"/>
</transform>
<serialize>
</match>sortOrder.js:
function getSortOrder() {
sendPage("table-view",
{"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 don't.
--- 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.
<snip/>
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 syntax.
WDYT?
/Daniel
