Good post. My comments interspersed (I just got back from vacation, so maybe the points were already made):
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > > In light of the discussion on blocks, Sylvain pointed out > that cocoon services should be mapped to pipelines and not to > resources directly. > > This consideration triggered a few RT that I would like to > share with you and trigger further discussion. > > NOTE: this is nothing related to blocks or flow, but only at > the sitemap semantics. Difining the pipeline. > What is a pipeline > ------------------ > > We call 'Cocoon pipeline' the collection of all filters > (transformers) and adapters (generator and serializer) > because there cannot be a pipeline without adapters. > > I think it's time to challenge this concept. I agree, but not necessarily in the way that you might be thinking. > What are sitemap resources? > --------------------------- > > Let me tell you: they are a mistake, a mistake I did trying > to reduce the sitemap verbosity and fixing a problem that > didn't yet emerged at that time. Early optimization is the > root of all evil and I see that > now: resources overlap with pipelines. I agree on the statement of early optimization. I have not used resources or views (with the exception of link crawling). However, consider which is clearer to the user: * Dynamically generating a pipeline based on runtime parameters or URI. * Statically selecting the resource based on runtime paramters or URI. Resources do not necessarily reduce verbosity, but they clarify the end result. The problem is not pipeline vs. resources, but the mixing of the concepts. I have had the pleasure of working on a rats nest. It mixed OO design, procedural design, and a quasi finite state machine that spanned four objects (states where controlled by static integers). The thing functioned, it did its job (sort of). Trying to understand it requires the equivalent of three doctorates and 5,000,000 years of experience. My solution: scrap it and start again. The new version still has some bugs to work out, but it is *much* easier to understand. Under the hood, Cocoon is firmly entrenched in the pipeline semantics. This is good. It helps make the components very flexible and powerful, without having to learn several different ways of doing the same thing. The problem is that the sitemap exposes everything underneath to the end user. It would be much better if the sitemap markup EITHER supported the resource/view paradigm OR purely the pipeline paradigm. The resource would specify the pipeline fragment that starts the pipeline. The view would specify the fragment that ends the pipeline. It helps with the formalization of a *component* model for web applications. There is still the matching/selecting section of the sitemap, but instead of dynamically assembling a pipeline as it goes, it uses resources, and then selects the view. What would really help is if the component definition were in one file, the resource definitions and view definitions were in a second file, and lastly the matching/selection logic were in a third file. Each of the files would have a purpose (SOC). We would know what we are editing with each of the resources. The logic, or sitemap file is what calls the resource and selects the view. In essence, we could set up a really simple sitemap like this: <map:sitemap> <map:match pattern="*.*"> <map:resource name="{1}"/> <map:view name="{2}"/> </map:match> </map:sitemap> It's really easy to understand. There is no notion of separate pipelines, although they can be implemented under the hood. The problem with sitemap verbosity is not so much what it represents, but that it mixes the representation paradigms to the user. That makes it more complex to understand than necessary. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
