I've been thinking about this and I find it a little inconsistent. We're calling addCommand() for all data that need to be passed to the server side. However, we don't call this for the id. Instead we call setUniqueId() (BTW, am I wrong in thinking that an id is always unique - Otherwise, what's the point?).
I would have thought the id to be some data for the server side too. With your nice refactoring you have separated user data from cactus data in the request (which is good). Maybe we go one step further and add a class containing all cactus-related data of the request.
For example:
WebRequest.setRequestCommands(RequestCommandData)
RequestCommandData { setTestClassName() setTestMethodName() setAutoSession() setUniqueId() [...] getTestClassName() [...] saveToRequest() loadFromRequest() }
Now, thinking about it, we may want to consider the id as an intrinsic field for a WebRequest instead of a command data. However, I don't think we're using it for anything else than a command data, so we might not overdesign it and put it in the command data?
This leads the path for a future ResponseCommandData class.
BTW, is "Command" the right word?
It's rather some internal data. Something like "setInternalData(), RequestInternalData, ResponseInternalData". But there's must be a better name than "internal" for sure... :-)
What do you all think?
Okay, I hope I've read all the threads now, so I'll dare to add my 2 cents :-)
I think we are mixing concerns. The WebRequest class is just the user API for setting up the HTTP request that will be sent to the redirector. It should not try to be more, and -- more importantly -- it should not expose Cactus internals to the user.
The current design happens to use WebRequest to add the Cactus parameters to the request. Nick's addition of the CactusCommand stuff has promoted this implicit usage to an actual API, adding a facet to WebRequest which should not be there. I.e. WebRequest is being used as a general abstraction for HTTP requests.
This is a code smell IMHO. We should now not resort to tricks with inheritance or package-private-access to separate the user-API side of WebRequest from the internal-API side. Rather, the core should move away from using WebRequest as a general HTTP abstraction facility, possibly moving towards more direct usage of the HttpClient API. However, this is not the time for such refactorings!
I would like to see the CactusCommand stuff reverted to normal use of addParameter() etc. Adding an internal RequestDirectives class as a data structure to hold the various parameters/directives would be a nice idea.
Hmm, I've gotto run for the train now, maybe continue this later :-P
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
