On 30.Sep.2002 -- 03:38 PM, Piroumian Konstantin wrote:
> > From: Christian Haul [mailto:[EMAIL PROTECTED]]
> > I would prefer that module to be a "meta" module that can be
> > configured to take input from any source (i.e. another
> > InputModule) rather than do the reading itself.
> >
> > That way it would be possible to apply the XPath expression
> > e.g to a bean or document stored as session attribute.
>
> Yes, this would be much better. So, what about extending
> AbstractJXPathModule to say AbstractJXPathMetaModule which can implement the
> getContextObject() using configured input modules to obtain the object to be
> processed by the JXPath processor?
>
> Maybe even some AbstractMetaModule would be better (not only JXPath based)?
Depends if you want to extend the modules themselves or have one for
the routing.
pro module extension
- simpler
- no additional lookup and (de-)composition
cons module extension
- works only with the extended modules
- fixed lookup chain (?)
pro routing module (à la DefaultsMetaModule but more complex)
- plug any source list into it
- all modules gain new functionality
- modules themselves are simpler
cons routing modules
- additional (de-)composition / lookup
- more complex configuration
> > > > > if
> > > > > the xception has a meaningful message.
> >
> > What about "null"?
>
> Sorry, don't quite get what is "null"? The exception message?
No, the value "null" like in "String tmp = null" There's an ambiguity
here of course like in java.util.Map.get: does it contain the value
"null" or is it absent?
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]
