On Tue, 12 Feb 2002, DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) wrote: <snipped/> > For the HttpServletRequest/HttpRequest/Request problem - the fact that I am > not using any other methods that get/setAttribute does not mean anything. > The discussion is about fundamentals not specific usage in the simplistic > example. The Adapter or Dispatcher may need to access some information > associated with the transport on which the request was sent, including for > example InputStream for some reason. When you expose some public interface > you try to make this as usable as possible with the minimal number of > dependencies. My preferred choice will be HttpServletRequest and I said > already why. I am able to compromise this to use Cocoon abstraction but it > cannot be Request ( as it is today ) it does not expose all > HttpServletRequest definitions.
Well, again. This discussion has been held a year ago. Originally the Cocoon Request interfaces *were* based on the ServletRequest interfaces but over the time the decided has been to move onto it's own implementation to allow a more generic abstraction of an Environment (which is good IMHO). So, I don't really want to go the same path again and I don't see your objection does really matter in the Cocoon environment to use the original HttpServletRequest or the abstracted Cocoon Request. I also don't see why the Cocoon request has to "expose all HttpServletRequest" as the name is too specific for Servlets and that's what Cocoon wants to avoid to show that it has its own abstraction of an Environment. The objectModel contains the original environmental objects IRRC for parts which needs to know and run in a specific environment. The Cocoon core itself will and should not be be bound to any specific environment. Components which needs the specific environmental objects will not run in other environments (i.e. Commandline). This was very clear from the beginning of the design of this abstracted environment (and to tell you the truth, everybody knew there might be components with those needs but we avoided those being part of the distributions so far). And thus the more a Component can rely on the most abstracted environment the more they can be reused in other environments as more of those will be implemented anytime. The way to go was to implement a set of methods in the abstract environmental interfaces and add more if there will be a requirement. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
