Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:

<generate type="jx" src="..">
<parameter name="userprofile" dom="{cocoon:/userprofile}"/>
...
</generate>


You could do it from a flowscript, whats the problem with that?


Wait. You can do a lot of things with flow, but I also think that we should not forget about what we already have.

The sitemap already contains input modules and as much as I was not thrilled by them, I came to agree that sometimes they are very useful, because while flow is great for stateful content, using it for stateless dispatching looks really like a waste and I think we are pushing flow so much that people will start to abuse it as a procedural dispatch mechanism.

What you are asking and what Éric is asking are two different things: he is asking to allow better integration between sitemap and data generation and you are telling him that "thou shall use flow".

Seem to me like we have switched opinion with each other ;)

You know, over the last few years I have written tons of RTs describing more or less cool pipeline constructions for simplifying webapp development. And you have after more or less convincing argumentation stated: "thou shall use flow" and concluded with your obligatory -1.

My current interest is polishing the basic building blocks for building webapps: JXTG, flow, CForms and maybe some more stuff so that it becomes as coherent and "smooth" as possible and in some cases less monolithic.

Having such a gool I am more interested in seeing the usual "I don't want to use flow because of X" for something that seem close to the concern area for flow, as a good reason for discussing how to polish flow so that it fullfills its task better.

Maybe handling data types other than strings; DOM, Java Beans, SQL rowsets etc in the sitemap is an excelent idea. But my gut feeling, after having spend considerable time thinking about building webapps with sitemap constructions, is that it doesn't stop there, we need some other sitemap constructions to make it really useful. And as said I feel more for polishing the flowscript way, than being part of developing alternative solutions. But you don't need my blessing for discussing and developing such things if you feel a need for it.

/Daniel

Reply via email to