On 05.Oct.2002 -- 05:07 PM, Jeff Turner wrote:
> On Fri, Oct 04, 2002 at 06:07:14PM +0200, Christian Haul wrote:
> > On 03.Oct.2002 -- 07:42 PM, Piroumian Konstantin wrote:
> ...
> > > > 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.
>
> Do you mean when, say {moduleA:foo} is requested, but moduleA doesn't
> have an attribute called 'foo'?
>
> I can see why you wouldn't _always_ want values to be defaulted to
> moduleB, but that does seem very useful behaviour to support.
>
> So how would it be done with a separate module?
Like it is done in today's DefaultMetaModule. Only that that only
defaults to a constant while we now want an arbitrary number of other
modules. So it would be like
<component-intstance .... "ChainingModule"...."chainA">
<input type="request-param"/>
<input type="request-attr"/>
<input type="session-attr"/>
<input type="xmlfile"/>
<input type="defaults"/>
</component-instance>
with "chainA" asking all modules in specification order for an
attribute until one returns a values != null. Of course, these
<input/> elements could contain configuration data for the modules as
well, e.g. to specify alternative names. Attribute name mapping or
augmentation (i.e. adding a prefix or postfix) could be done as
attributes to <input/>
Now, if you want a different lookup sequence for another application
or specific values, you could use the same to compose another chain
"chainB", that e.g. skips request-param.
> > > > 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.
>
> Looking at all the *MetaModule.java files, there is a huge amount of
> duplicated, non-trivial code. I don't fully understand it, and so cannot
> easily turn XMLModule into XMLMetaModule. Wouldn't it be possible to
> separate the common code out into an AbstractMetaModule class, which the
> *MetaModules could inherit from?
With some effort - yes. But the only code that really is sharable is
the "test a module for thread safty, keep a reference if it is or
release it otherwise" done during configuration.
The rest is more or less trivial component lookup if a different
module is specified as during configuration or the module is not
thread safe, plus component release.
Now, you could have an abstract module that calls an abstract method
that is to be implemented by child classes for the "do something with
the module" event and one for the "you've got your data, do something"
event.
Another issue is, that they all behave differently regarding the three
methods getAttribute(), getAttributeValues(), and
getAttributeNames(). So, one could not really follow the above route
and provide only a method for composing, which is only a few lines....
My assessment was and still is, that it would add considerable
overhead and complexity to share this code through inheritance and is
not worth it.
BTW there is a XMLMetaModule but that does a completely different job:
if packs all (some) e.g. request parameters to a string
representation. That is handy, if you don't know what to expect and
store it in a database, but that's a completely different story. (Yes,
I could use the request generator plus some xslt and the cocoon://
protocol to achieve the same.)
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]
