Quoting Manfred Wolff <[EMAIL PROTECTED]>:
> Hi all.
>
> I have a question about the context implementation of the commons-chain
> project.
>
> I think it is a good way to have JavaBean Properties in a context like:
>
> private User user;
>
> with get()- and set()- Methods like
>
> public User getUser() ... and so one
>
> So you have type-safeness.
>
Agreed. You'll see that pattern used in specialized Context implementations
that are used in specific scenarios, such as the WebContext that is designed
for use in web applications, and has built in properties to return things like
a Map of request parameters.
> What is the benefit of "Attribute-Property Transparency" (I don't hear
> this concept before). You get the attributes via
>
> User user = (User) context.get(getUser());
>
> where getUser() in this case returns a string to have access to the
> propery. The benefit is to avoid having fixed strings like
>
> User user = (User) context.get("user");
>
> Now you have the handicap, that you must cast the value into the real
> type and all benefit of having JavaBean properties are away. The other
> way I would prefer.
>
> Regardless having JavaBean properties or some "untyped" values in the
> Map: Every values will store in the same Map. Than you have a nice
> possibility to clone contextes in an easy way.
>
> Example:
>
> class myContext extends Context {
>
> private String userString = "user";
>
> // --- Property User
> private User user;
>
> public User getUser() {
> return (User) get(userString);
> }
>
> public void setUser(User user) {
> put(userString, user);
> }
> }
>
> Perhaps somebody can me more explain about the benefits of the current
> implementation.
>
One of the popular recent themes in discussions about software architecture is
decomposing complex things into little things, and factoring them for reuse.
The transparency supports reusability, if you wish to take advantage of it.
Let's assume you are trying to combine a bunch of sets of Command
implementations from separate third party libraries into a single chain. If
each of those sets of Commands were programmed to the simple
org.apache.commons.chain.Context API, and rely on transparency to get and set
their values, your Command will operate correctly with *any* implementation of
Context. On the other hand, if you program your Commands to use your own
specialized Context implementation, then the only other Command implementations
you can interoperate with are those who use (or subclass) that same Context
implementation.
>From a design perspective, it's not a totally either-or decision ... it's quite
reasonable to use both styles, and/or to create inheritance hierarchies of
Context implementations that add some typesafe properties along the way. If
you know your Commands will only be used in the Context of a particular
application, that makes sense for the reasons that you've identified. But as I
design my Commands, I'm also keeping my mind open to easy interoperation with
other Commands, and being conservative about the Context implementation that I
depend on is one of the mechanisms to help this.
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
