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 Wed, 24 Nov 2004 15:31:41 GMT
On Tue, 23 Nov 2004 12:16:16 -0800, Miles Elam <miles@pcextremist.com> wrote:
> On Nov 23, 2004, at 11:30 AM, Peter Hunsberger wrote:
> 
> > On Mon, 22 Nov 2004 16:44:24 -0800, Miles Elam <miles@pcextremist.com>
> > wrote:
> >> So what do you say to function sources?
> >
> > Interesting.  Did you read my post yesterday on generic generators?
> 
> I hadn't then.  I just did.  It looks like we're on the same page and
> trying to solve similar problems from different points of view.
> 
> > 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?
> 
> Yes.  The "src" attribute is a String.  What you do with that String
> has always been implementation dependent.  It's just that the
> implementation has always (?) been to use the SourceResolver
> exclusively.

I think that others are saying you can do your proposal by having the
source resolver understand a "script" source, which makes sense to me.
 IOW, really you just need to wrap the return from script engine to
that it can look like  a source and you've got what you want.  So, it
continues to exclusively go to the SourceResolver.  But this isn't the
complete answer, read on...

> > 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 don't want sendPage to go anywhere.  I love sendPage.  But this
> problem is not the same problem that sendPage solves.  In fact, it only
> loosely parallels the current usage of flow.  The only thing in common
> is a scripting language and passing objects to the caller.
> Continuations are not just an inconvenience.  They are the wrong
> approach in my opinion.

Well if you look at the perspective of "script:myfunc()" being a
source that calls the script engine you've still got continuations and
everything else available as you do today.  A script based source
looks to me like the input side of the continuations which can then
focus more exclusively on the action side.  This lets your script be
divided up into two seperate areas of concern also (so you're code is
even more broken up than before!).  Now potentially you've got:

sitemap -> script source -> flowscript -> [browser] -> 
sitemap -> continuation -> flowscript

(Or you can just skip continuations and write an action handler as
before, but that's definitely not what we want!)

Note that, so far, having a scriptable source hasn't removed any need
for continuations because it doesn't address the issue of mapping the
source to the action.  To do this you'd need a new concept even beyond
sources, which I think is what you're trying to get at?

Let's consider this second thing; what you'd need is some new source,
lets call it "continuable-script".  Then in your sitemap you'd do:

continuable-script:myfunc(...)

The continuable-script would then do a sendSource (equivalent to a
sendPage) at the point it thinks it is done producing the source data
(so to speak).  This would cause the flow script to return to the
sitemap which would then finish up more-or-less as normal, but all the
while retaining the context of the dangling sendSource.  Basically
SendSource would create some sort of flag/stack (?) that tells the
sitemap handler to treat the termination of the serializer as the
point to jump back into the rest of the flowscript sendPage handling
and at that point the normal sendPage handling would resume but
without the requirement for a second sitemap fragment.  This, I think
achieves what you're asking for?

I think this makes some sense, but what you're asking for is more than
a source.  You're asking for a transparent hook into continuations
handling that eliminates the need for a second sitemap fragment, but
does not eliminate continuations.

The biggest issue with this proposal is what happens if multiple
sitemap components invoke a continuable-script source?  I think the
answer is that you just stack up the continuations in a LIFO stack
handling them in reverse order upon return, but maybe others can see
issues with this?  From a conceptual point of view that could
potentially be very powerful but I get dizzy trying to figure out any
real use-cases; I'm sure I could invent some kind of UI/business logic
separation use-case, but at the moment I'm fighting a cold so I drop
this for future conversations if the idea seems worth pursuing at
all...

<snip>example discussion</snip>
> 
> > <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?
> 
> It would work, but have never been in favor of deceiving the developer
> in the name of a hack.  sendPage has a well-defined purpose.
> Short-circuiting that purpose will only lead to confusion.  If sendPage
> is causing the problem, it needs to be removed from that solution set,
> not gutted of its functionality.  Hence my terminology that function
> sources define a completely new contract that cannot be directly
> overlayed on top of the old.

I'm not sure I'd want any kind of magic default handling either, I was
just throwing the idea out to see if it had any resonance with the
rest of the issue.  Now that I think I've got the entire concept of
what you're asking for I think your idea is a little cleaner.

> >> So the following questions remain:
> >> 1. Does this ease overseparation concerns somewhat?
> >
> > Not sure, other simpler things might also help here.
> 
> Simpler from a conceptual standpoint or simpler from an implementation
> standpoint?

I meant implementation point of view.  With the new concept I'm not
sure you've separated concerns since now a single script has the
responsibility of producing both the source and then handling the
action upon return.  I don't really have a problem with this, maybe
others will?

> >> 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.
> 
> From the user point of view?  The "src" attribute.  I see your point
> about making the contract clearer though.  Have any suggestions? 

I think I've sketched it out above? Basically it's your concept just
slightly rephrased...

> Bear
> in mind that only sitemap components that know how to handle the
> functionality will use it (eg. ones that don't use SourceResolver).  It
> would seem incredibly foolish to create a component that used "src" in
> this way and not even documenting that fact in the Javadocs.  I guess
> stranger things have happened though.
> 
> >> 3. How easy would it be to wire this into the existing codebase (eg.
> >> JXTemplateTransformer)?
> >
> > I think so.
> 
> Thanks for answering my poorly worded question.  I meant to say, "Would
> it be easy to wire this..."

I think the complete implementation as I've sketched out is a tad
harder than just a source wrapper around a script produced object!  I
still think it sounds doable, but I've been through some of this code
and it it takes a lot of little turns and twists and this wouldn't
make it any simpler!

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

Yes, in fact you'd want almost exactly today's code for the
implementation I describe, you basically just break sendPage into two
parts, one handled at "sendSource" time and the other when the
serializer terminates.  I have no idea how to glue the two pieces
together over the duration of the sitemap traversal of the rest of the
pipeline (or if it' really possible); I think it's some kind of
context stack but you need a pipeline expert to answer that question.

-- 
Peter Hunsberger

Mime
View raw message