cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Wed, 26 Jan 2005 07:29:12 GMT
Daniel Fagerstrom wrote:
> 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.

I tend to agree with you Daniel. I don't understand why we need datatype 
declarations in the sitemap, but maybe a stronger contract between sitemap and 
template makes sense.

Let's make a step back and let's define the usecase that makes us discuss the 
border between flow and sitemap. IIUC it's about making objects available in 
templates without having to go the detour of using flow _and_ defining a 
stronger contract for this.

Two days ago, I wrote about my usecase for chained input modules. Daniel 
answered, that in his opinion this looks like voodoo and suggested to have a 
global action that is executed for every request. Wouldn't this be the solution 
for passing objects to the view layer either?
Currently JXTG gives access to the session, the request and the application 
context. So using them as container is possible today. The drawback: The 
contract isn't defined very well because in your template you have to to 
something like this:

<p>${cocoon.request.getAttribute('xyz')}</p>

A weak contract IMO.

Having a strong contract like

<generate type="jx" src="..">
   <parameter name="userprofile"
    object="{$cocoon.request.getAttribute('userprofile')}"/>
</generate>

could help us to make templates more side-effect free because then we could 
forbid the direct access of the request and the session from within templates:

<page xmlns:jx="...">
   <p>{$userprofile.getName()}</p>
</page>

We could even go a step further and enforce explicit variable declaration:

<page xmlns:jx="...">
   <jx:variable name="userprofile"/>
   <p>{$userprofile.getName()}</p>
</page>

Unfortunatly those templates wouldn't still be side-effect free, because nobody 
prevents me from doing

<p>{$userprofile.getRole().setName('newRoleName')}</p>


> And as said I feel 
> more for polishing the flowscript way, than being part of developing 
> alternative solutions. 

Maybe you can comment on my response all the same :-)

> But you don't need my blessing for discussing and 
> developing such things if you feel a need for it.
> 
> /Daniel

-- 
Reinhard

Mime
View raw message