Re: struts2 design question
[EMAIL PROTECTED] wrote: I wouldn't have seen that. Thanks, Jeromy. It's disturbing to see this kind of code in 2008 and makes me wonder what other antipatterns might exist in the struts2 codebase. Actually I only linked to that discussion to show that Dave had been courteous enough to follow it up for you. From a design perspective I think it's a negligible issue that people are opinionated about because it's rather easy to understand. "Put First things First" Incidentally, the most significant antipattern present in Struts 2 that affects me is that of the "Fragile Base Class". http://en.wikipedia.org/wiki/Fragile_base_class It's caused by xwork actually and is evident because Struts 2 is used in scenarios that were probably not even conceived when the base classes were developed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
--- Musachy Barroso <[EMAIL PROTECTED]> wrote: > I am confused here. You do know that you don't need to > extend/implement any class/interface right? Or I am missing the whole > point. The original issue was regarding error messages and how they're stored in the action rather than in a thread/instance variable referenced through a static class. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: struts2 design question
--- [EMAIL PROTECTED] wrote: > 3. Classes can't stand on their own. Neither can a class that's using a static method. > 4. It's easier for Java beginners to mix business logic with > MVC framework code. Easier? Like... typing is actually easier with S2? Never mind, I don't get that one, and this isn't the forum to discuss it. > If your action and bean methods only refer to a framework context (which, > by the way, *is* injectable with Seam Another dependency. > or with your own VariableResolver, Isn't that a JEE dependency? > I hope you can see how JSF has a lighter footprint > than struts2. I hope you can understand that reasonable people can disagree. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
I am confused here. You do know that you don't need to
extend/implement any class/interface right? Or I am missing the whole
point.
musachy
On Thu, Feb 21, 2008 at 11:39 AM, <[EMAIL PROTECTED]> wrote:
> >Funny; I was thinking the same thing about the static context stuff in
> JSF
> >that makes it really difficult to test in isolation.
>
> What makes you think that's difficult? I'm sure you're aware of mock
> objects. There are a number of mock JSF test frameworks---JMock and Shale
> come to mind. Writing actions and beans that extend or inherit MVC
> classes/interfaces are worse than "static context stuff" because:
>
> 1. Java doesn't have multiple inheritance so if you want to make your own
> base classes, you're forced to create an inheritance chain tied to the MVC
> framework
>
> 2. Swapping out frameworks is next to impossible.
>
> 3. Classes can't stand on their own.
>
> 4. It's easier for Java beginners to mix business logic with MVC framework
> code.
>
> We've been down this road before with struts1. Spring-MVC brought us the
> next generation of thinking by making all framework dependencies
> interfaces (implementations are provided but not required, like struts2).
> JSF takes this idea to its logical conclusion.
>
> If your action and bean methods only refer to a framework context (which,
> by the way, *is* injectable with Seam or with your own VariableResolver,
> contrary to your statement in a previous post. For example,
> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977385), you can
> write them to support multiple frameworks simultaneously. In practice, no
> one does this, but it demonstrates the flexibility of the JSF approach. I
> can, for example, write an action class that works with both Struts2 and
> JSF:
>
> public class CreateCustomerAction extends ActionSupport /* ActionSupport
> req'd by struts2 */ {
> ...
> ...
>
> /** Stuts2 action */
> public String execute() throws Exception {
> if (!customerDAO.create(...))
> addActionError("Unable to create customer");
> return INPUT;
> }
>
> /** JSF action */
> public String createCustomer() {
> if (!customerDAO.create(...))
> FacesContext.getCurrentInstance().addMessage("someId", "Unable to
> create customer");
> return "input";
> }
> }
>
> If JSF required the extension of a framework class or implementation of a
> framework interface like struts2 does, the code above couldn't be written
> without a mixin/delegation (esp. if the interfaces shared the same method
> names like execute()). I hope you can see how JSF has a lighter footprint
> than struts2.
>
>
>
>
> *** IMPORTANT
> NOTE* The opinions expressed in this
> message and/or any attachments are those of the author and not
> necessarily those of Brown Brothers Harriman & Co., its
> subsidiaries and affiliates ("BBH"). There is no guarantee that
> this message is either private or confidential, and it may have
> been altered by unauthorized sources without your or our knowledge.
> Nothing in the message is capable or intended to create any legally
> binding obligations on either party and it is not intended to
> provide legal advice. BBH accepts no responsibility for loss or
> damage from its use, including damage from virus.
>
>
> -
>
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
>Funny; I was thinking the same thing about the static context stuff in
JSF
>that makes it really difficult to test in isolation.
What makes you think that's difficult? I'm sure you're aware of mock
objects. There are a number of mock JSF test frameworks---JMock and Shale
come to mind. Writing actions and beans that extend or inherit MVC
classes/interfaces are worse than "static context stuff" because:
1. Java doesn't have multiple inheritance so if you want to make your own
base classes, you're forced to create an inheritance chain tied to the MVC
framework
2. Swapping out frameworks is next to impossible.
3. Classes can't stand on their own.
4. It's easier for Java beginners to mix business logic with MVC framework
code.
We've been down this road before with struts1. Spring-MVC brought us the
next generation of thinking by making all framework dependencies
interfaces (implementations are provided but not required, like struts2).
JSF takes this idea to its logical conclusion.
If your action and bean methods only refer to a framework context (which,
by the way, *is* injectable with Seam or with your own VariableResolver,
contrary to your statement in a previous post. For example,
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977385), you can
write them to support multiple frameworks simultaneously. In practice, no
one does this, but it demonstrates the flexibility of the JSF approach. I
can, for example, write an action class that works with both Struts2 and
JSF:
public class CreateCustomerAction extends ActionSupport /* ActionSupport
req'd by struts2 */ {
...
...
/** Stuts2 action */
public String execute() throws Exception {
if (!customerDAO.create(...))
addActionError("Unable to create customer");
return INPUT;
}
/** JSF action */
public String createCustomer() {
if (!customerDAO.create(...))
FacesContext.getCurrentInstance().addMessage("someId", "Unable to
create customer");
return "input";
}
}
If JSF required the extension of a framework class or implementation of a
framework interface like struts2 does, the code above couldn't be written
without a mixin/delegation (esp. if the interfaces shared the same method
names like execute()). I hope you can see how JSF has a lighter footprint
than struts2.
*** IMPORTANT
NOTE* The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
--- [EMAIL PROTECTED] wrote: > I wouldn't have seen that. Thanks, Jeromy. It's disturbing to see this > kind of code in 2008 and makes me wonder what other antipatterns might > exist in the struts2 codebase. Funny; I was thinking the same thing about the static context stuff in JSF that makes it really difficult to test in isolation. Makes me wonder what other antipatterns exist in the JSF codebase. If only there was a perfectly refactored, up-to-date, everything-done-as-it-"should"-be framework. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
I wouldn't have seen that. Thanks, Jeromy. It's disturbing to see this
kind of code in 2008 and makes me wonder what other antipatterns might
exist in the struts2 codebase.
Dave Newton wrote:
> --- [EMAIL PROTECTED] wrote:
>
>> I'm curious why the developers of struts2 chose to define constants in
an
>> interface (StrutsStatics) and then implement that interface in at least
18
>> classes
>>
Just thought I'd mention that Dave followed this up for you in struts-dev:
http://www.nabble.com/StrutsStatics...-td15595866.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
*** IMPORTANT
NOTE* The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
Strangely it first freezes my browser. Re-testing it now and it's working. I also thought the three dots could come from a shortened url, while it's effectively not. Apologies. Maxx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
--- Jeromy Evans <[EMAIL PROTECTED]> wrote: > Maxx wrote: > > On Thu, Feb 21, 2008 at 2:03 AM, Jeromy Evans > > <[EMAIL PROTECTED]> wrote: > >> http://www.nabble.com/StrutsStatics...-td15595866.html > > Just to let you know this link does not work (seems incomplete). > Works for me in FF and IE6 and from Thunderbird! And Safari... As odd as it looks, that is the actual URL (mailing list message subject plus a message ID). Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
Maxx wrote: On Thu, Feb 21, 2008 at 2:03 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote: Just thought I'd mention that Dave followed this up for you in struts-dev: http://www.nabble.com/StrutsStatics...-td15595866.html Just to let you know this link does not work (seems incomplete). Works for me in FF and IE6 and from Thunderbird! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
On Thu, Feb 21, 2008 at 2:03 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > Just thought I'd mention that Dave followed this up for you in struts-dev: > http://www.nabble.com/StrutsStatics...-td15595866.html Just to let you know this link does not work (seems incomplete). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
Dave Newton wrote: --- [EMAIL PROTECTED] wrote: I'm curious why the developers of struts2 chose to define constants in an interface (StrutsStatics) and then implement that interface in at least 18 classes Just thought I'd mention that Dave followed this up for you in struts-dev: http://www.nabble.com/StrutsStatics...-td15595866.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts2 design question
--- [EMAIL PROTECTED] wrote: > I'm curious why the developers of struts2 chose to define constants in an > interface (StrutsStatics) and then implement that interface in at least 18 > classes It's likely you'd need to ask the original WebWork developers. Item #17, "Use interfaces only to define types", is on page 89 in my copy, btw. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
