If a user requires a "request" scoped behaviour then wouldn't it be better if this was implemened in a Command rather than Utils? In my mind Utils should be more of a Global thing thats overriden rarely. I think one of the problems with current Struts is that sometimes too much has been put into utils. Take the form population as an example - whats in the RequestUtils populate method is mainly a load of stuff to handle mutipart parameters - then it just calls BeanUtils. The multipart stuff IMO would have been better keeping it in the RequestProcessor and in 1.3 should be in a Command. In my mind thats the great thing about the 1.3 Chain stuff in that there is less need to factor out stuff into Utils since plugging in different behaviours, re-using and overriding becomes much simpler. I'd like to see whats in Utils become smaller and more tightly focused as small fragments of common code.
Niall ----- Original Message ----- From: "Don Brown" <[EMAIL PROTECTED]> To: "Joe Germuska" <[EMAIL PROTECTED]> Cc: "Struts Developers List" <dev@struts.apache.org> Sent: Wednesday, December 22, 2004 9:17 PM Subject: Re: ViewUtils and UtilityFactory (was Extracting taglibs) > "coming soon"? Is that an offer? :) I like the API bean aka > ViewContext aka ConfigHelper and agree it is a better solution. Reading > over the API bean thread, Ted has convinced me this bean would actually > be created for each request probably somewhere early in the chain. > While it could be passed around via the Context, I'd vote to also store > it in ThreadLocal so we could call ViewContext.getCurrentInstance() at > any point. > > Assuming we'd have a CreateViewContext chain command, would we pass in > the class names to instantiate for RequestUtils and ViewUtils as command > attributes in the config? This would allow the util implementation to > not only be module scoped but request scoped if desired since the user > can have complete control over the chains. > > Don > > > Joe Germuska wrote: > > At 12:33 PM -0800 12/22/04, Don Brown wrote: > > > >> What about having a UtilityFactory class that provides RequestUtils > >> and ViewUtils? It goes without saying we'd deprecate the static > >> methods and delegate to new, non-static methods on an instance pulled > >> from this factory. Does Struts have a consistent approach to > >> factories and allowing code to replace the factory implementation? I > >> know this would be a good opportunity to put Spring into the mix, but > >> perhaps an abstract factory would be a good first step in abstracting > >> implementation from usage. > > > > > > My first reaction is that an abstract factory is wasted effort if a > > Struts API bean is coming soon. I'd be more inclined to have something > > in the ActionServlet's initialization create and populate a "Struts" > > with the understanding that how the "Struts" is populated is a moving > > target. Eventually, I think you and I would agree on a vision which has > > Spring instantiate the "Struts" and set its "requestUtils" and > > "viewUtils" properties with implementation classes. > > > > Or are these utils module-scoped? > > > > Unless you're talking about a factory for the "Struts" object itself -- > > I just wouldn't want to see a proliferation of different factories when > > the end goal would probably make them obsolete... > > > > Joe > > > > > --------------------------------------------------------------------- > 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]
