On 03.Oct.2002 -- 07:42 PM, Piroumian Konstantin wrote:
> > From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> > On Wed, Oct 02, 2002 at 12:04:23PM +0200, Christian Haul wrote: ...
> > <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.
Fine.
> > In this model (the current one), certain modules are
> > designated 'meta' modules, and act on others.
> > 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.
I'm referring _only_ to the "if (!present) then use otherModule"
case. This should IMO be done by a separate module.
> I don't think that the order of component declarations should be relevant.
> Do I get something wrong?
It should not matter. It does in cocoon.xconf ATM (startup problems
regarding hsql lead to this, IIRC).
> > > 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.
Absolutely. See DigestMetaModule for example :-)
> > 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?
None, really. This distinction is purely language. It's _only_ the "I
don't know, ask somebody else" case I'd like to be separate.
The other way around: Why should every (more than one) module be able
to escalate the method to another module if an attribute is not found?
> > 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 looks better than it is, since the composition part (and keeping
references if threadsafe) can not be separated that easily IMO because
of the try-catch-finally split.
> So let's ask somebody (Jeff? ;) ) to summarize the proposal and let's start
> voting procedure as was suggested by Stefano.
I've tried to, although not being Jeff :-)
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
