cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Tue, 20 Apr 2004 18:11:53 GMT
Daniel Fagerstrom <danielf@nada.kth.se> 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...


Mime
View raw message