I agree these routines should not be lumped into one or two huge util classes. Ideally, these functions would be grouped into logical service classes fronted by interfaces, allowing multiple implementations. To pull of something like that cleanly, however, I believe we'd have to fully adopt an IoC/DI container like Spring.
Don
Niall Pemberton wrote:
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" <[email protected]>
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
