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
