> -----Original Message----- > From: Lesiecki Nicholas [mailto:[EMAIL PROTECTED] > Sent: 22 June 2003 11:36 > To: Cactus Developers List > Subject: RE: cvs commit: jakarta- > cactus/framework/src/java/share/org/apache/cactus > AbstractWebServerTestCase.java > > > --- Vincent Massol <[EMAIL PROTECTED]> wrote: > > 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?). > > Yep. The inconsistency bugged me too. But not enough to solve it tonight. > I > like your proposal. > > > > > 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() > > } > > Hmmm, I like it. Looks like a good interface. Then we can make the > RequestCommandData class final or package private or something to keep > users away from it. > > > > > 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? > > I think RequestCommandData is the right place for the id. > > > > > 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... :-) > > Yeah, "command" doesn't seem right. We just need something to > differentiate > it from user data. "Internal" is ok, "Cactus" is always an option... > > How about naming the class "CactusDirectives"? Or "RequestDirectives"? > > or...hmmm...
yeah Directives is quite good. Chris? Thanks -Vincent > > undecided, > Nick > > > > What do you all think? > > > > Thanks > > -Vincent > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Sent: 22 June 2003 04:51 > > > To: [EMAIL PROTECTED] > > > Subject: cvs commit: jakarta- > > > cactus/framework/src/java/share/org/apache/cactus > > > AbstractWebServerTestCase.java > > > > > > > [snip] > > > > > - > > theRequest.addParameter(HttpServiceDefinition.CLASS_NAME_PARAM, > > > - this.getClass().getName(), WebRequest.GET_METHOD); > > > - > > > theRequest.addParameter(HttpServiceDefinition.METHOD_NAME_PARAM, > > > - this.getCurrentTestMethod(), WebRequest.GET_METHOD); > > > - > > > theRequest.addParameter(HttpServiceDefinition.AUTOSESSION_NAME_PARAM, > > > - theRequest.getAutomaticSession() ? "true" : "false", > > > - WebRequest.GET_METHOD); > > > + addCactusCommand(HttpServiceDefinition.CLASS_NAME_PARAM, > > > + > > this.getClass().getName(), > > > + theRequest); > > > + > > addCactusCommand(HttpServiceDefinition.METHOD_NAME_PARAM, > > > + > > this.getCurrentTestMethod(), > > > + theRequest); > > > + > > addCactusCommand(HttpServiceDefinition.AUTOSESSION_NAME_PARAM, > > > + > > theRequest.getAutomaticSession() ? > > > "true" : "false", > > > + theRequest); > > > + > > > + theRequest.setUniqueId(generateUniqueId()); > > > > [snip] > > > > > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
