cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From oceatoon <t.katelb...@systheo.com>
Subject Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Tue, 25 Jan 2005 14:16:56 GMT
Hi
this thread is getting quite complicated to follow and the snake seems to be
bighting it's own tail;) , but the idea is quite simple and seems an easy
patch.
> I don't get why you are so obsessed with being able to do everything
> from the sitemap. Once, when the community started to develop Cocoon in
> a direction to better support webapps there was the question if we
> should put more abilities to have control stuff in the pipeline or if
> this should be done in a separate system, the flowscript. Had we chosen
> the sitemap way we would have need to put more mechanisms in the sitemap
> to preserve nice SOC. That was the way I prefered back then.

Eric's proposal of passing objects (like DOM) as sitemap parameters in
pipeline, IMO would be compared to  jx:import(with a pipeline as uri)  and
loadDocument(cocoon://blabla) in flow, So why not be able to pass directly
any kind of DOM in sitemap as a parameter?
(for example coming from a session context or other IM)

> 
> Now we have gone the flowscript way and I'm completely happy with that.
> There are nummerous good reasons for that decision and some good reason
> against it. But in some way that doesn't matter anymore. What is much
> more important is that we focus our energy on making Cocoon realy smooth
> and efficient to use along the choosen direction. Trying to support
> several similar ways of achieving the same things only disolve our energy.
> 
> Whats important to notice for software development is that if enough
> talented people choose an at least somewhat reasonable direction and
> focus on, it _makes_ the direction a good direction after a while. To be
> worthwhile to backtrack and chose another direction must lead to very
> large advantages to be anything else but destructive.

I think we all agree on the above, but also know that we all have different
ways of solutionning the same problem. The quantity of solutions proposed
by the cocoon structure is part of its charm ;)

> 
> Conclusion: the current direction is that objects and control are
> handled in flowscript rather than pipelines. Let us focus on making that
> smooth rather than confusing our users and ourselves about where things
> should be done.

IMO, it isn't more complicated than the other two cases, just the
possibility to pass an object as a parameter. 

> 
>>2) servicemanager, $request, $session useless in jx (pass parameters
>>explicitly in the sitemap like you use to do with SendPage in flow). SoC
>>preserved.
>>
>>3) inversion of control not broken. (Exception triggered from the
>>sitemap). You can remove java object access from jx since they are used
>>for breaking this IoC and SoC.

I understand that the SiteMap plays the central role in the simplified
pyramidal design of Cocoon(Sitemap,Flow,JX) but is restrained in the type
of parameters it passes(strings) to either JX or Flow. 
OTOH Flow is able to pass any type of objects in a SendPage which is
enormously usefull. And poor old JX spits out whatever the other two
Controllers giv'him. I find it normal that the sitemap could give him DOM,
or any other object.

SoC and IoC truly are truly respected here.

Tibor


Mime
View raw message