Eric,
Sorry for the delay in replying to this.
I did want a simple Map. However, I had in mind finding some way of
trying to impose some way of keeping concerns separated. In this case,
of keeping the data belonging to a single concern separate and trying to
avoid users writing code that ended up mixing data from one area with
data from another. Your comment has provoked further thoughts.
I was wondering about making the 'pipelineData' a typesafe Map which
only allowed Map objects to be put into it. Each service would have the
option to put a Map of its objects into the pipelineData using a key
which may be the service name.
This would mean that users would have to get the Map which they required
explicitly and would have the full Collections API available on that
Map. However, they would not be able to put sundry objects into the
pipelineData Map and start writing methods which relied on them without
first explicitly accessing the required Maps. PipelineData could also
throw a clearly defined exception if trying to retrieve a Map which was
not contained in it.
The 'typesafe Map' approach would also prevent services overwriting data
from another service if the same name was used for the object key. In
this case the data would be held in the Map belonging to the service
itself. We may have to prefix all keys with the Service Name for example
to stop this happening if we used a simple map as pipelineData.
It is slightly more work for the user, but when users start adding or
swapping valves in the pipeline, it may make for code that is easier to
debug and maintain.
Any thoughts anyone?
Regards,
Peter
On Wed, 2004-05-12 at 17:26, Eric Dobbs wrote:
> Hi All.
> Not sure why this thread snapped me out of my lurking... maybe it
> was the introduction of yet another Context. ;-)
>
> On May 12, 2004, at 5:06 AM, Eric Pugh wrote:
>
> > Instead, what I would like to see is a
>
> > PipelineData or PipelineContext
>
> Instead of creating a new interface, why not just use a Map?
> I like the idea of decoupling the pipeline from RunData, but I
> don't think PipelineData, nor Peter's suggestion for
> RequestData add very much descriptive power.
>
>
> >> The other option is to create a new interface, say RequestData, with a
> >> single purpose, that of passing objects along the pipeline.
>
> >> public interface RequestData {
> >>
> >> public void putObject(String key, Object obj);
> >>
> >> public Object getObject(String key);
> >>
> >> }
>
> This example is just a subset of what is offered by Map. If you
> use Map you don't have to introduce any new concepts to the
> programmer, you can get() and put(), and also benefit from the
> rest of the Collections API. You also don't have to write any
> code for the interface nor for the implementation. Less code is
> A Good Thing.
>
> -Eric (the other one :-)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
