cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <peter.hunsber...@gmail.com>
Subject Re: [RT] function sources
Date Tue, 23 Nov 2004 19:30:16 GMT
On Mon, 22 Nov 2004 16:44:24 -0800, Miles Elam <miles@pcextremist.com> wrote:
> A while back, Ugo brought up his idea for "A Groovy Kind of Sitemap"
> which met with some friction.  On the one hand was the camp that felt
> that the sitemap/flowscript dichotomy was a case of overseparation of
> concerns.  On the other was the camp that absolutely wanted to keep a
> general purpose programming language away from the main URI/HTTP
> decision tree.  At the time, I was firmly in the second camp.
> 
> This is not to say that I now want scripting code embedded in the
> sitemap.  Far from it.  I still believe that the logic and management
> issues are absolutely two distinct concerns that warrant a Great Wall
> of SoC(tm) between them.  However, the feelings of overseparation were
> not without cause.  Let's face it, it's a major PITA to make two
> matchers for every scripted source: one for the <map:call /> and one
> internal pipeline for the flowscript sendPage() output -- and then make
> sure they all stay in sync.
> 
> So what do you say to function sources? 

Interesting.  Did you read my post yesterday on generic generators? 

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110114534905358&w=2

In order to exploit such a beast you want to be able to wrap a source
with a liittle extra ornamentation than you normally do today. It
seems to me In a way that in a way we're attacking the same problem?
However, with a generic generator the existing sitemap and sendpage
remain, you just don't have to add any new target sitemap pipelines
for the flowscript functions since everything can go to the same
pipeline (which contains the generic generator).  Obviously this
doesn't apply if you want different transforms, we use a single
styling transform for 80% of our target pages anyway.

I'm a little confused as to why you show the sitemap source connected
to the transformer instead of the generator?

<snip>src generation description</snip>

> Logic is kept at arm's length from the sitemap AND there are no blind
> "where's in coming out" logic paths.

What if you could declare a pipeline "default" so that a "sendPage"
would always go to the default if no other match was found? Doesn't
solve the other issues, but helps with this one?

> So the following questions remain:
> 1. Does this ease overseparation concerns somewhat?

Not sure, other simpler things might also help here.

> 2. Does this avoid gratuitous FS-syndrome?

Not sure, seems a little strange.  I like the idea of being able to
build up  the source definition in flowscript.  I'm not sure if I'm
understanding exactly how you see it interacting with the sitemap.

> 3. How easy would it be to wire this into the existing codebase (eg.
> JXTemplateTransformer)?

I think so.

> 4. Could the same flow engine be used but with a different set of
> default objects/interfaces?

I think so.

> 5. Am I completely off my rocker?

Probably, but who isn't?

> 
> I think the answers to 1-3 are "yes".  I'm not familiar enough with 4
> to make any comment.  5 I'll leave as an exercise for the reader.

-- 
Peter Hunsberger

Mime
View raw message