cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Input module chaining (Re: XML input module)
Date Wed, 02 Oct 2002 12:38:42 GMT
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>

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

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>


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

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.

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


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

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


Mime
View raw message