Hi Peter!
apologize for not having been more precise on explaining my idea:
while they look similar, I would consider the Sitemap a superset of
pure Pipeline fluent APIs.
Indeed, while a Sitemap woud _describe_ an "action" would be performed
if the current pattern matches against the input, the Pipeline APIs
would _invoke_ a Pipeline. i.e.
+-------------------------+
public class MySitemap
implements Sitemap
{
public void configure( SitemapBinder binder )
{
binder.when( "linkmap.xml" )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( "feed.xml" ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource("/trax.xslt") )
.setFinisher( XMLSerializer.createXMLSerializer );
binder.when( "atom.xml" )
.newCachingPipeline()
.setStarter( new SQLTransformer( ... )
.addComponent( new
XSLTTransformer(this.getClass().getResource("/atom.xslt") )
.setFinisher( XMLSerializer.createXMLSerializer );
}
}
+-------------------------+
would be different than direct pipeline executions
+-------------------------+
newCachingPipeline()
.setStarter( new XMLGenerator(new URL( "feed.xml" ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource("/trax.xslt") )
.setFinisher( XMLSerializer.createXMLSerializer )
.setup( System.out )
.execute();
newCachingPipeline()
.setStarter( new SQLTransformer( ... )
.addComponent( new
XSLTTransformer(this.getClass().getResource("/atom.xslt") )
.setFinisher( XMLSerializer.createXMLSerializer )
.setup( System.out )
.execute();
+-------------------------+
The setup-execute phases, in the pipeline, would be executed by the
Sitemap framework.
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Aug 6, 2012 at 5:40 PM, Peter Hunsberger
<peter.hunsber...@gmail.com> wrote:
> Hi Simone,
>
> I guess the part I'm missing is how would this differ from what is already
> in Cocoon 3 as an API? I do get that part (most, all?) of you objective is
> to get rid of the Spring layer, so maybe the end result is essentially the
> same as the C3 API in the end?
>
> Peter Hunsberger
>
>
>
> On Mon, Aug 6, 2012 at 10:33 AM, Simone Tripodi <simonetrip...@apache.org>
> wrote:
>>
>> Hi Peter!
>>
>> My proposal is writing an intermediate layer to create sitemaps, it
>> doesn't aim to replace the existing infrastructure but IMHO it could
>> be used as the foundation to create sitemaps; while all textual
>> configurations work fine, having a more expressive and type checking
>> APIs could help - and users could still wrap them in their bigger
>> picture, making the tree objects construction easier.
>>
>> You could have a look at the Apache Commons Digester binder[1] APIs,
>> which are wrapped by the XML configuration[2] and annotated
>> elements[3]. One expressive layer to create the sitemap, multiple way
>> to bind them.
>>
>> I agree that building tree objects would still work, but Fluent
>> Interfaces would help on respecting the configuration status, i.e. the
>> first element of a Pipeline can only be a Starter, when using the "old
>> way" users are still able to setup a pipeline with no starter and find
>> the error only when executing it.
>>
>> I am sure there are cases I am not taking in consideration that would
>> break my PoC as well :P
>>
>> what do you think? You would be still able to load a graph from Neo4j
>> and setup the pipeline using directly native Java APIs - no parsing,
>> no transforming, a little faster :P
>>
>> Many thanks in advance, all the best!
>> -Simo
>>
>> [1] http://commons.apache.org/digester/guide/binder.html
>> [2] http://commons.apache.org/digester/guide/xmlrules.html
>> [3] http://commons.apache.org/digester/guide/annotations.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Mon, Aug 6, 2012 at 4:21 PM, Peter Hunsberger
