Re: [Chain] ContextToRequestCommand

[Jeff Caddel]

If your application uses WebContext (or one of it's subclasses) as the Context
object being passed down the chain, you already have access to the request
attributes via the getRequestScope() method.  There's also other Map-returning
methods on WebContext for lots of other useful stuff (headers, cookies, session
attributes, context attributes, context init parameters, ...).
A.  Brain cells starting to click now.  One huge benefit of exposing 
them as map's being that you can make use of generic bean manipulating 
code to mess with them, right?  Instead of making API specific calls 
like getAttribute/setAttribute.

On the attribute collections in particular, the Map implementation is two-way
... for example, usage like this:
 public boolean execute(Context context) throws Exception {
   ...
   WebContext wcontext = (WebContext) context;
   // Following is equivalent to request.getAttribute(foo)
   String fooValue = wcontext.getRequestScope().get(foo);
   // Following is equivalent to request.setAttribute(foo, bar)
   wcontext.getRequestScope().put(foo, bar);
   ...
 }
Which is better since nothing in this implementation makes a servlet 
specific API call.  If I needed the value bar to be present under the 
attribute foo in a portlet environment (for example), this command 
could be re-used.

makes a request attribute named foo with value bar visible to a JSP page (or
whatever) that will ultimately create the response.
If I'm getting this right, I could also place bar into the request 
under the attribute foo (in an API independent manner, nonetheless) by 
simply configuring a CopyCommand:

command className=org.apache.commons.chain.generic.CopyCommand 
toKey=requestScope.foo from=foo/

(Assuming that some other previous bit of logic had placed bar into 
the context under the key foo.)

Holy smokes...how easy is that!!

Does this satisfy the sorts of requirements you were after?

Fit's the bill quite nicely, Craig.  Thanks.

Craig

-
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]

[Chain] ContextToRequestCommand

[Jeff Caddel]

Any feedback on this Command implementation?

The idea is that as a chain of commands is executing objects get 
aggregated into a map.  The context holds a reference to the map.  At 
the tail end of the execution chain, this command places the objects 
from the map into the request as request attributes so that front end 
components (Tiles, JSP's etc) can display them.

Is this:
A) A terrible idea violating abstractions of the Chain of Responsibility 
pattern? 
B) A good idea demonstrating good use of the pattern?
C) Something else?

public class ContextToRequestCommand implements Command {
   String key = contextToRequest;
   public boolean execute(Context context) throws Exception {
   HttpServletRequest request = 
(HttpServletRequest)context.get(request);
   Map map = (Map)context.get(key);
   if (map == null) {
   return false;
   }

   Iterator pairs = map.entrySet().iterator();
   while (pairs.hasNext()) {
   Map.Entry pair = (Map.Entry)pairs.next();
   request.setAttribute((String)pair.getKey(), pair.getValue());
   }
   return false;
   }
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]