On Tue, 23 Nov 2004 12:16:16 -0800, Miles Elam <[EMAIL PROTECTED]> wrote: > On Nov 23, 2004, at 11:30 AM, Peter Hunsberger wrote: > > > On Mon, 22 Nov 2004 16:44:24 -0800, Miles Elam <[EMAIL PROTECTED]> > > 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
