Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: error (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <cc159a4a04112311304c57d563@mail.gmail.com>
References: <D2AA5324-3CE8-11D9-B496-000393539234@pcextremist.com>
 <cc159a4a04112311304c57d563@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <879F514A-3D8C-11D9-B496-000393539234@pcextremist.com>
Content-Transfer-Encoding: 7bit
From: Miles Elam <miles@pcextremist.com>
Subject: Re: [RT] function sources
Date: Tue, 23 Nov 2004 12:16:16 -0800
To: dev@cocoon.apache.org

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.

> 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.

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

The JXTemplateGenerator is pulling data from two sources: the template 
file and the data from flow.  I chose a transformer so that each piece 
performed exactly one data gathering action.  Virtual pipeline 
components could mask the separation of the two if you made a virtual 
generator that was a combination of a file generator and a jx 
transformer.  The parsing has to happen anyway, and if the parsing is 
actually a bottleneck in your overall app compared to data acquisition, 
the parsing algorithm is horribly faulty or your data acquisition is by 
far the fastest on the planet.  FileGenerator caches, so reparsing 
isn't an issue.

> <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.

>> 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?

>> 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?  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..."

>> 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?

LOL!

- Miles Elam