On 10.Jan.2003 -- 05:56 PM, Sylvain Wallez wrote:
>
> But I'm also wondering how we could also use the fact that InputModule
> returns Objects and not only Strings and would like to have a means to
> return an object for e.g. {request-attr:foo}.
Since all object have a toString() method, it should not be a problem
to return objects. Obviously, the using component has to be aware of
how to deal better with eg XMLizable. OTOH there are occasions where
the automatic conversion does not work.
For the sitemap I fear it would be a rather fundamental change to
allow objects as parameters. For a transformer, it could work.
> I also would like to introduce InputOutputModules. For example, I have a
> component which needs some data to work, but doesn't actually care where
> this data comes from, as it may depend from the application. For
> example, it could be {request-attr:foo} or {session-attr:bar} or
> {context-attr:baz}. So I would like to have an InputOutputModule that
> can be used by the application to set the value, and the by the
> component to read it.
Tough one. A component could implement both interfaces but would end
up as two instances in the component manager. Therefore storing data
in one instance could not be read from the other instance.
A third category is difficult as well, making the module handling
extra complex.
Would leave a helper component that stores the data and is looked up
by both instances. But that would need to be a singleton since thread
safe does not guarantee this AFAIK. IOW this leads to unwanted
complexity.
Or is there a way to have one instance registered with multiple
selectors?
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]
