cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [Discuss] Sitemap NG
Date Mon, 06 Aug 2012 15:33:15 GMT
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
<peter.hunsberger@gmail.com> wrote:
> Hi Simone,
>
> long time ago we had discussions on alternate languages for the C2 Sitemap,
> I used to want to do them in XSLT (as opposed to XML) with Java extensions
> to implement the actual interface from the XSLT to the resulting Cocoon
> object tree for the sitemap. These days I sometimes wonder if I could build
> sitemaps in Neo4J and have Cocoon read them in via it's Neo4Js REST
> interface (or more directly)...
>
> In some ways it seems Cocoon 3 is already aimed at  most of what you outline
> or is this in addition to the way you can do Java pipelines there?
>
> Peter Hunsberger
>
>
>
> On Mon, Aug 6, 2012 at 2:50 AM, Simone Tripodi <simonetripodi@apache.org>
> wrote:
>>
>> Hi all guys,
>>
>> I've had this mail draft for a long while and I think it's time to
>> shout it out to get your feedbacks.
>>
>> Due to my involvement in Apache Commons and being strongly influenced
>> by the Google-Guice design, I think we could get benefit from a vision
>> that mixes the power of:
>>
>>  * modularity;
>>  * Embedded DSL.
>>
>> The current situation is that the sitemap takes tons of Kb of Spring
>> dependencies (please assume I'm not a big fan of Spring so my POV is
>> influenced :P) and the sitemap is described via XML. Since we can
>> still take the XML configuration, I'm sure - but I haven't had the
>> time to write even a kickoff spike, so I still don't have the proof on
>> hands - we could simplify the foundation of sitemap design, getting
>> benefits from the javac using directly the Java language to describe
>> the sitemap.
>>
>> What I'd suggest is introducing Sitemap(s) to describe how  the
>> sitemap is organized, i.e.
>>
>> +-------------------------+
>> interface Sitemap
>> {
>>
>>     void configure( SitemapBinder binder );
>>
>> }
>> +-------------------------+
>>
>> where the {{SitemapBinder}} contains a set of APIs to allow describing
>> the path-matching;  a possible case could be:
>>
>> +-------------------------+
>> 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( "linkmap2.xml" )
>>                  .newCachingPipeline()
>>                  .setStarter( new XMLGenerator(new URL( "feed2.xml" ) )
>>                  .addComponent( new
>> XSLTTransformer(this.getClass().getResource("/trax2.xslt") )
>>                  .setFinisher( XMLSerializer.createXMLSerializer );
>>
>>         ...
>>     }
>>
>> }
>> +-------------------------+
>>
>> that would reflect what in XML would be expressed as:
>>
>> +-------------------------+
>> <map:match pattern="linkmap.xml">
>>   <map:generate src="classpath:feed" />
>>   <map:transform src="{lm:transform.linkmap.document}"/>
>>   <map:serialize type="xml" />
>> </map:match>
>>
>> ...
>>
>> <map:match pattern="linkmap2.xml">
>>   <map:generate src="classpath:feed2" />
>>   <map:transform src="{lm:transform.linkmap.document}"/>
>>   <map:serialize type="xml" />
>> </map:match>
>>
>> ...
>> +-------------------------+
>>
>> of course, XML looks compact, but please take in consideration that
>> XML is not type checking, we can get errors at runtime only; that
>> means that a transformer can be erroneously set as generator, while
>> using Java APIs it would be notified at compile time.
>>
>> An AbstractSitemap would help to reduce the `binder` variable verbose
>> and redundant call:
>>
>>
>> +-------------------------+
>> public class MySitemap
>>     extends AbstractSitemap
>> {
>>
>>     @Override
>>     public void configure()
>>     {
>>        when( "linkmap.xml" )
>>                  .newCachingPipeline()
>>                  .setStarter( new XMLGenerator(new URL( "feed.xml" ) )
>>                  .addComponent( new
>> XSLTTransformer(this.getClass().getResource("/trax.xslt") )
>>                  .setFinisher( XMLSerializer.createXMLSerializer );
>>
>>         ...
>>
>>        when( "linkmap2.xml" )
>>                  .newCachingPipeline()
>>                  .setStarter( new XMLGenerator(new URL( "feed2.xml" ) )
>>                  .addComponent( new
>> XSLTTransformer(this.getClass().getResource("/trax2.xslt") )
>>                  .setFinisher( XMLSerializer.createXMLSerializer );
>>
>>         ...
>>     }
>>
>> }
>> +-------------------------+
>>
>> we could also work by Sitemap composition:
>>
>>
>> +-------------------------+
>> 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.include( new MySitemap2() );
>>
>>         ...
>>     }
>>
>> }
>> +-------------------------+
>>
>> then a special loader is used to create the application:
>>
>> +-------------------------+
>> SitemapLoader.load( Sitemap...sitemaps );
>> +-------------------------+
>>
>> WDYT?
>> TIA, all the best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>
>

Mime
View raw message