Return-Path: 
 <cocoon-dev-return-31559-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 99175 invoked by uid 500); 4 Oct 2002 15:24:33 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 83914 invoked from network); 3 Oct 2002 15:42:12 -0000
Message-ID: <B6352CB87AA70442A1C6F49E6B658C9875BFAA@postman.flagship.ru>
From: Piroumian Konstantin <KPiroumian@protek.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: Input module chaining (Re: XML input module)
Date: Thu, 3 Oct 2002 19:42:24 +0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Jeff Turner [mailto:jefft@apache.org] 
> On Wed, Oct 02, 2002 at 12:04:23PM +0200, Christian Haul wrote: ...
> > > > I think with this interface, we can still have input module
> > > > chaining. It would just be attributes that get 'chained', not 
> > > > whole objects. So we could have:
> > > > 
> > > > <component-instance class="...RequestModule" 
> name="request-attr"/>
> > > >   <input-module name="session-attr"/> </component-instance>
> > > > <component-instance class="...SessionModule" 
> name="session-attr">
> > > >   <input-module name="xmlconfig"/>
> > > > </component-instance>
> > > > <component-instance class="...XMLModule" name="xmlconfig">
> > > >   <config>context:///forrestconf.xml</config>
> > > >   <attribute-map from="*" to="/forrestconf/*"/>
> > > >   <input-module name="defaults"/>
> > > > </component-instance>
> > > > <component-instance class="...DefaultsMetaModule" 
> name="defaults">
> >       <!-- how about this: -->
> >       <input type="request-attr" priority="2"/>
> >       <input type="session-attr" priority="1"/>
> >       <input type="xmlconfig" priority="0"/>
> > > >   <values>
> > > >     <skin>default-skin</skin>
> > > >   </values>
> > > > </component-instance>
> 
> I think I see what the confusion is.
> 
> You're proposing simple Composition of modules:
> 
>  <component-instance class="...DefaultsMetaModule" name="defaults">
>       <input type="request-attr" priority="2"/>
>       <input type="session-attr" priority="1"/>
>       ...
>  </component-instance>

Let's keep it simple and simply use the declaration order instead of the
priority attribute. 

> 
> In this model (the current one), certain modules are 
> designated 'meta' modules, and act on others.
> 
> 
> An alternative is 'chaining' of modules, similar to Unix pipelines:
> 
> <component-instance name="A">
>    <input-module name="B"/>
> </component-instance>
> <component-instance name="B">
>    <input-module name="C"/>
> </component-instance>
> <component-instance name="C"/>
> 
> In this model, every module is potentially a 'meta' module, 
> as it can take as input any other module. Think of 
> 'input-module' as 'stdin'.

This is exactly what I would like to have. 
But I think that we should have simple modules declared in Cocoon
distribution by default and users should be able to combine them as they
like.

E.g. the LocaleInputModule which is the next on my todo list can look like
this:
  <component-instance class="...LocaleModule" name="i18n"
locale-param="locale">
       <input type="request-param" />
       <input type="request-attr" />
       <input type="session-attr" />
       <input type="cookie" />
       <input type="request" attribute="locale"/> <!-- This one corresponds
to request.getLocale() and should be declared explicitely -->
       <input type="string" attribute="en_US" />
  </component-instance>

> 
> The other big difference in this model is that the order is 
> reversed. DefaultsMetaModule is at the end of the chain. It's 
> very simple, basically a hashtable. It can contain defaults 
> for multiple other
> modules:
> 
> <component-instance name="A">
>   <input-module name="defaults"/>
> </component-instance>
> <component-instance name="B">
>   <input-module name="defaults"/>
> </component-instance>
> <component-instance class="...DefaultsModule" name="defaults">
>   <values>
>     ...
>   </values>
> </component-instance>

I don't think that the order of component declarations should be relevant.
Do I get something wrong?

> 
> 
> > The idea of meta modules was to provide functions that may apply to 
> > different sources. Like read a string and convert it to a 
> > java.util.Date or access a java.util.Map entry (easily 
> replacable with 
> > the jxpath support in attributes)
> 
> That's easy to do. Imagine a module that converts 
> milliseconds since 1970 to formatted date strings:
> 
> <component-instance class="...TimeModule" name="time"/> 
> <component-instance class="...DateFormatterModule" name="date">
>   <input-module name="time"/>
> </component-instance>
> 
> So {time:now} would give you 1033557024000, and {date:now} 
> gives you 'Wed, 02 Oct 2002 21:11:24". Alternatively, you 
> could feed random numbers into DateFormatter to get random dates.

Again +1 for this kind of modules.

> 
> I can give lots more examples if you like. I think this 
> chaining could be really powerful :) We keep the current 
> attribute-centric API, and gain all the advantages of "meta" modules.

I don't understand why having "meta" capabilities in every module can do any
harm? What are the objections?

> 
> As for inheritance, that's just a handy technique for 
> implementing chaining. We'd have:
> 
>     AbstractInputModule
>             |
>  AbstractChainedInputModule   (handles 'input-module' and 
> name mapping)
>             /\
>           /    \
>         /        \
> DateFormatter  AbstractJXPathModule
>                       |
>                       \_ RequestModule
>                       \_ SessionModule
>                       \_ XMLModule

+1
And even date formatter can be JXPath aware, e.g. you can use substring()
function to extract parts of the date string.

> 
> 
> > This is the same discussion as with the jxpath. Should it 
> be inherited 
> > or composed. Since I belive this should be configurable by the user 
> > (no reason not to have a number of different configurations for a
> > site!) I would vote for composition.

So let's ask somebody (Jeff? ;) ) to summarize the proposal and let's start
voting procedure as was suggested by Stefano.

> >
> > In addition I believe that it stays simpler to write custom 
> modules. 
> > Which should be a design goal.
> 
> Absolutely. I think that with chained modules, we can push 
> almost all the complexity into a superclass, and new modules 
> will be really simple to write. For example, the 
> number-to-date Module above should be a few lines.
> 
> > +1 for attribute mapping ("map-attribute" confuses because of 
> > +"map:attribute"?)
> 
> Oh yes.. mapping is a little extension to the chaining model. 
> Say A's names are all simple: 'foo', 'bar'. And B's names are 
> all XPath, so they're '/skinconf/foo', /skinconf/bar'. Then 
> the mapping rule translates from A's naming system into B's
> 
> <component-instance name="B">
>   <attribute-mapping from="*" to="/skinconf/*"/>
>   <input-module name="A"/>
> </component-instance>
> 
> Ehm.. more code, less talk :)

Let's summarize and vote.

Regards,
  Konstantin

P.S. I'll have access to CVS tomorrow and have a couple of modules to commit
(SystemPropertyModule and LocaleModule). It is also needed to synchronize
changes with 2.0.3-dev before the release is out (as was reminded by Vadim).

> 
> --Jeff
> 
> > 	Chris.
> > -- 
> > C h r i s t i a n       H a u l
> > haul@informatik.tu-darmstadt.de
> >     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org