Daniel Fagerstrom <[EMAIL PROTECTED]> writes: > > Hunsberger, Peter wrote: <snip>examples</snip>
> > > So, lets see, I started with a 7 line sitemap snippet, where > most Cocoon > users should be able to understand at a course level what is going on > after short look at it. Then I proposed that the flowscript version > where you have to look at two files at once for seeing what > is going on > is more complicated to grasp. And now you propose that it would have > been better to write something that abstracts away about > everything that > was concrete and easy to grasp about the first example. I moved any explicit handling of the page to the flowscript, instead of looking in the sitemap you now look in the flowscript. I also added some generic handling for any page that does not need specific handling. That's something you can already do with the site map independent of flow. So, I added more capability, but I don't think I abstracted anything or made it harder to understand. Surely, you're not suggesting that the average person manipulating a Cocoon sitemap can't understand that * is a wild card? <snip>abstraction discussion</snip> > > In our case, we just have a > >whole patch of common parameters we always pass in the > sitemap, subbing > >them in via an action, but that's more-or-less the same > thing as using > >a module to get at them...) > > > Sure, you can do that, but you either have to turn of caching or make > the cache key depend on a lot of stuff that it shouldn't > depend on. Also > after having started to feed my xslt with params explicitly through > input-modules in the sitemap to get better cache control I also, as a > side effect, find it easier to understand what my apps do > from looking > at the sitemap. Umm, there should be no difference if the parameter in the sitemap is generated from an action or a module? But, I'm not arguing against modules (I quite like some of them), but rather in favor of moving flow control out of the sitemap (and using flow script). > Request attributes are often parts of the urls and because of that a > part of the sitemaps concern area. Also flow attributes are > part of the > contract between the sitemap and flow scripts, so in many cases it, > IMHO, increase readability if you are explicit about what flowscript > attributes a sitemap rule depends on. Hmm, I like the sitemap purely to specify how things are generated. There can be a lot of communication between components to precisely specify what needs to be generated, but as much as possible I try to keep communication between flow and sitemap minimized. > >If you're site map shrinks down to almost nothing, and all > the logic on > >what page is being called is in the flow script, doesn't that add > >clarity? In your example, you're still using the sitemap to > determine > >page flow... > > > > > IMO, the sitemap contains excelent abstractions for > describing one page > "page flows", as long as you don't require to much input > handling, (and > as some readers might remember, I have some ideas about how > to improve > the sitemap abilities in that area as well ;) ). > > And flowscrips are a good abstraction of multipage flow. IMO > it does not > increase readability to put absttractions of one page access > patterns, > this is of course a matter of taste. If you're just generating a couple of pages I think I can agree with you. But if you're just generating a couple of pages I'm not sure why you are using Cocoon in the first place? In our case, we have over 350 different pages being generated on the production system, with 1000's more to come...
