On 9/10/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > > > > -----Ursprüngliche Nachricht----- > > Von: Craig McClanahan [mailto:[EMAIL PROTECTED] > > Gesendet: Samstag, 10. September 2005 18:06 > > An: Struts Users Mailing List; [EMAIL PROTECTED] > > Betreff: Re: Who decides? > > > > Here's a couple of things that (had we known then what we > > know now) would very likely be different -- and areas where I > > think improvements would be > > helpful: > > > > * Actions as stateless singletons, instead of per-request instances > > I think they 'de facto' are stateless singletons? I mean the controller > only > creates one instance, and you shouldn't create another :-)
Well, you can certainly make your custom RequestProcessor do this as well ... but nearly every successful developer using Struts has had it pounded into their heads that you shouldn't use instance variables in an Action to store per-request state. Creating an Action per request also still doesn't let you eliminate form beans and just use properties on the Action instance itself (the way WebWork, Tapestry, and JSF like you to do). > * Expression language syntax (based on BeanUtils) is way too limited > > For those who need it :-) The conciseness and power of using expression language based manipulations, especially when it can do dependency injection style bean creation the way JSF managed beans work "for free", and even when you're programming your actions in Java, is one of the hidden jewels that remains for many developers to discover :-). > > > * Totally dependent on Servlet API objects, making (a) unit > > tests hard, and (b) implementations on portlet difficult > > I think it's the nature of a http framework? Nope ... it's the nature of an http framework that was designed before portlets existed. JSF, for one, goes to great pains to hide the differences between the two environments. The same result should be possible with pretty much any architectural strategy that passes a context object around ... just make sure the context object has accessors to get to the abstract idea of a "request parameter" (and so on), without being coded directly to the servlet or portlet API. In the Commons Chain world, for example, that's why the WebContext abstraction exists. ... > > Regards > Leon Craig PS: No, it's not really 5 in the morning where I am ... just arrived in Bejing for the Java China conference going on this week , and it's 8pm here. But you're not very likely to see me participating in conversations in semi-real-time this week :-).
