You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" <ms...@hp.com> on 2001/06/18 23:36:14 UTC
RE: [EJB] java report article says "bye-bye struts"
To Anyone It Concerns,
Although I'm relatively new to EJB's, I'm listed on the 1.1 TODO list
to add better EJB support/design patterns. Ideas that anyone has about
things that they'd like Struts to do with EJB's will definately help me
along with this and help Struts quiet this EJB fud. I'm looking to get
started on this soon, and anyone who wants to is more than welcome to
help me out.
- Mike
-----Original Message-----
From: Bill G [mailto:toroweap@pacbell.net]
Sent: Monday, June 18, 2001 5:04 PM
To: struts-user@jakarta.apache.org
Subject: RE: java report article says "bye-bye struts"
Hi Craig,
"Although excellent in dealing with Web-based applications, Struts is not
ready to take on EJB."
This is a concern of mine as well but as a newbie to this technology, I am
wondering how to adopt the Struts framework knowing that I will move to
EJB's. Is it worth starting with Struts with the idea of moving to EJB's or
what? Any info on this matter is seriously appreciated!
Thanks
BG...
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Monday, June 18, 2001 11:14 AM
To: 'struts-user@jakarta.apache.org'
Subject: RE: java report article says "bye-bye struts"
On Mon, 18 Jun 2001, Ritter, Steve wrote:
> Hi Hal, yeah I read the same article and couldn't help but laugh.
> Prashant really made some outlandish comments and hopefully those
> comments will diminish any negative impact his article might have on
> Struts (or, the adoption of Struts I should say).
>
> Craig, if you read this thread it might not be a bad idea to send a
> quick email to the editor's of Java Report and let them know about
> some of the mis-leading statements. Sounds like their review board
> needs a little re-org.
>
Looks like I'll have to go buy a copy -- I don't pay a lot of attention to
trade magazines in print, because production cycles make them so far out
of date.
Judging from the many thank-you's I've received for the 1.0 final
release, I wouldn't worry to much about negative impact on Struts
adoption. :-)
> --Steve
>
Craig
> > -----Original Message-----
> > From: Deadman, Hal [mailto:hal.deadman@tallan.com]
> > Sent: Monday, June 18, 2001 7:52 AM
> > To: 'Struts List'
> > Subject: java report article says "bye-bye struts"
> >
> >
> > Clearly there are too many java magazines and they will
> > publish anything. In
> > the July issue of Java Report there is an article titled
> > "Writing a Reusable
> > Implementation of the MVC Design Pattern" by Prashant Sarode
> > from Brience.
> > It's interesting because it has a section title of "Bye-Bye
> > Struts". The
> > section starts out as follows:
> >
> > "While the Struts framework is a powerful idea, it is not yet
> > a product.
> > Although excellent in dealing with Web-based applications,
> > Struts is not
> > ready to take on EJB."
> >
> > There are other gems in the article but I won't reproduce
> > them all here.
> >
> > The premise of the article is that the author went looking for an MVC
> > framework. He found the Blueprint document and liked that but
> > it was too
> > complicated. He then found Struts but apparently it didn't
> > meet his need for
> > "a reusable implementation of the MVC pattern." Prashant must
> > be a hard man
> > to please. I think he wants one framework that can be used
> > for both web
> > applications and desktop applications. Personally I would
> > rather share the
> > model components and let my MVC framworks be a little less
> > abstract and more
> > useful to the task at hand.
> >
> > I couldn't find the article on-line. I just skimmed the rest
> > of the article
> > because it it was hard to concentrate or take it seriously
> > after the Bye-Bye
> > Struts section.
> >
> > Hal
> >
>
Re: [EJB] Design Patterns (was JavaReport ...)
Posted by Jonathan Asbell <ja...@i-2000.com>.
What you have here is:
1) an immutable from the web tier
2) an immutable from the enterprise tier
3) a need to update each other
Maybe they are immutable as far as standard get/set methods.
However, they can also implement an interface which uses separate secondary
fileds which start with the original values, and CAN be updated. In this
way the 2 original models (the web tier ActionForm and the EJB model) can
have the original values untouched, and the new secondary fields will hold
and provide the updated state.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 8:03 AM
Subject: Re: [EJB] Design Patterns (was JavaReport ...)
> What I'm working on now are patterns for Struts development that can be
> used with or without Enterprise Beans. As mentioned, the J2EE blueprints
> are mostly about development patterns, and Enterprise Beans are one part
> of implementating those patterns. This work is the second part of the
> Strut by Strut series ("Stepping out").
>
> I had a long discussion with a BEA Weblogic employee the other day about
> this very thing. I think we need to more strongly seperate the J2EE
> patterns from the Enterprise Bean implementation. The idea being we
> should introduce people to the pattern first (presentation beans / data
> access beans / value object beans / helper beans), and then show where
> Enterprise Beans plug into that. Or, where you would roll your own.
>
> On the Struts front, while it is often the case that the ActionForm
> beans end up looking like many of your internal beans, there are
> important differences. For example, ActionForm beans should be immutable
> except by the actor, meanwhile many of your internal beans should be
> immutable except by the model. ActionForm beans need to use Strings as
> the primary type, but your internal beans may need native types to
> commune with the business logic beans. You really only need ActionForm
> beans to get input from the actor. When sending read-only views back,
> you can use any kind of bean you want (with the bean tags), so long as
> it has a reasonable toString(). It seems wasteful at first, but in the
> big picture, it seems like treating ActionForm beans as HTTPD
> throw-aways is the only way to keep the application loosely coupled, and
> able to attach to other environments later.
>
> Of course, data transfer becomes a big issue when you have to ferry
> things from ActinForm beans to data-access beans (and then back again in
> the case of an update). What I'm looking at now is using hashmaps as a
> standard data transfer agent. If the ActionForm can return a hashmap
> that matches the data access bean you can use BeanUtil.populate() to
> make the switch. Coming back later, if the value object bean returns a
> hashmap, you can use BeanUitl.populate() to fill your ActionForm bean
> (for an update). This would mean that your ActionForm bean design
> "knows" about your value object bean design, but I think that's OK
> (though the inverse would not be OK).
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
>
> "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" wrote:
> >
> > To Anyone It Concerns,
> >
> > Although I'm relatively new to EJB's, I'm listed on the 1.1 TODO list
> > to add better EJB support/design patterns. Ideas that anyone has about
> > things that they'd like Struts to do with EJB's will definately help me
> > along with this and help Struts quiet this EJB fud. I'm looking to get
> > started on this soon, and anyone who wants to is more than welcome to
> > help me out.
> >
> > - Mike
>
Multiple Submit Buttons
Posted by DHarty <ha...@db.erau.edu>.
Is it possible to use multiple <html:submit/> buttons in the same form, and
provide a different action depending on which was hit?
ex:
<html:submit>Do something</html:submit>
<html:submit>Do Something Else</html:submit>
<html:submit>Do Yet Another Thing</html:submit>
I know you can check if the button is a cancel, but that only works if you
have two alternatives.
I'm looking for a way in the Action class to see which button was hit.
Thnxs
David
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Thursday, June 21, 2001 11:13 AM
To: struts-user@jakarta.apache.org
Subject: Re: [EJB] Design Patterns (was JavaReport ...)
They could. This is especially convenient when your value object bean
contains a RowSet, since the *String versions are already built in. So,
you end up with something like
thisForm.set(
thisValue.getItemString(),
thisValue.getDonorString(),
thisValue.getDonorAnonString(),
thisValue.getCategoryString(),
thisValue.getPricelessString(),
thisValue.getScriptString(),
thisValue.getHasImageString(),
thisValue.getShippingString(),
thisValue.getItemTypeString(),
thisValue.getNameString(),
thisValue.getMarketString(),
thisValue.getMinimumString(),
thisValue.getIncrementString(),
thisValue.getSaleTypeString(),
thisValue.getQtyReceivedString(),
thisValue.getShippableString(),
thisValue.getWeightString(),
thisValue.getLocationString()
);
where thisValue.getItemString() does something like
/**
* Return the item as String
*
* @return the item as String
*/
public String getItemString() throws SQLException {
return values.getString("item");
}
// ... and
thisValue.setString(
thisForm.getItem(),
thisForm.getDonor(),
thisForm.getDonorAnon(),
thisForm.getCategory(),
thisForm.getPriceless(),
thisForm.getScript(),
thisForm.getHasImage(),
thisForm.getShipping(),
thisForm.getItemType(),
thisForm.getName(),
thisForm.getMarket(),
thisForm.getMinimum(),
thisForm.getIncrement(),
thisForm.getSaleType(),
thisForm.getQtyReceived(),
thisForm.getShippable(),
thisForm.getWeight(),
thisForm.getLocation()
);
where setString does something like
values.updateString("item",item);
I'm just looking for the least intrusive, most flexible pattern.
The nice part about a map is that it works well as part of an interface,
encapsulates the accessors within a toMap() method, and that mutators
can be called through reflection (e.g. BeanUtil.populate()).
Jonathan wrote:
>
> Why is it that each bean (includeing the containing bean) could not have
> BOTH String get/set and also native type get/set?
>
Re: [EJB] Design Patterns (was JavaReport ...)
Posted by Ted Husted <hu...@apache.org>.
They could. This is especially convenient when your value object bean
contains a RowSet, since the *String versions are already built in. So,
you end up with something like
thisForm.set(
thisValue.getItemString(),
thisValue.getDonorString(),
thisValue.getDonorAnonString(),
thisValue.getCategoryString(),
thisValue.getPricelessString(),
thisValue.getScriptString(),
thisValue.getHasImageString(),
thisValue.getShippingString(),
thisValue.getItemTypeString(),
thisValue.getNameString(),
thisValue.getMarketString(),
thisValue.getMinimumString(),
thisValue.getIncrementString(),
thisValue.getSaleTypeString(),
thisValue.getQtyReceivedString(),
thisValue.getShippableString(),
thisValue.getWeightString(),
thisValue.getLocationString()
);
where thisValue.getItemString() does something like
/**
* Return the item as String
*
* @return the item as String
*/
public String getItemString() throws SQLException {
return values.getString("item");
}
// ... and
thisValue.setString(
thisForm.getItem(),
thisForm.getDonor(),
thisForm.getDonorAnon(),
thisForm.getCategory(),
thisForm.getPriceless(),
thisForm.getScript(),
thisForm.getHasImage(),
thisForm.getShipping(),
thisForm.getItemType(),
thisForm.getName(),
thisForm.getMarket(),
thisForm.getMinimum(),
thisForm.getIncrement(),
thisForm.getSaleType(),
thisForm.getQtyReceived(),
thisForm.getShippable(),
thisForm.getWeight(),
thisForm.getLocation()
);
where setString does something like
values.updateString("item",item);
I'm just looking for the least intrusive, most flexible pattern.
The nice part about a map is that it works well as part of an interface,
encapsulates the accessors within a toMap() method, and that mutators
can be called through reflection (e.g. BeanUtil.populate()).
Jonathan wrote:
>
> Why is it that each bean (includeing the containing bean) could not have
> BOTH String get/set and also native type get/set?
>
Re: [EJB] Design Patterns (was JavaReport ...)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 21 Jun 2001, Jonathan wrote:
> Why is it that each bean (includeing the containing bean) could not have
> BOTH String get/set and also native type get/set?
>
You can only do this if you use different property names for the same
property. Otherwise, you'll get compile errors on something like this:
public Date getStartDate() { ... }
public String getStartDate() { ... }
or you will violate the naming conventions in the JavaBeans Specification:
public void setStartDate(Date startDate) { ... }
public void setStartDate(String startDate) { ... }
and your startDate property will not be recognized by the introspection
logic.
Craig
Re: [EJB] Design Patterns (was JavaReport ...)
Posted by Jonathan <ja...@i-2000.com>.
Why is it that each bean (includeing the containing bean) could not have
BOTH String get/set and also native type get/set?
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 9:03 AM
Subject: Re: [EJB] Design Patterns (was JavaReport ...)
> The ActionForm beans can contain nested references, so you could just
> set some other bean to it, then refer to myBean.propertyThis and
> myBean.propertyThat. Of course, the other bean would have to have
> standard String accessor and mutators, which is where it starts to fall
> down. The other beans may need to use native types, and would want to
> reject or transform an incoming String value being set to type. So if
> you need two storage locations, joining the two classes loses its edge.
>
> In general, I would say that ActionForms can be coupled to other beans,
> but other beans should not be coupled to ActionForm bean (import the
> Struts class). Because, in another environment, the ActionForm beans
> might be replaced with another class that hooked up to non-HTTP user
> interface (say, Swing), and we would want to be able to drop those in.
> Of course, the other beans could be designed to accept values from any
> given JavaBean via reflection, which would include an ActionForm bean.
>
> It's my feeling that proper MVC/J2EE design implies that we are going to
> be stuck with a set of ActionForm beans and a set of other beans, and
> need to find the best way to transfer data between the two.
>
> Jonathan Asbell wrote:
> >
> > I was on this track in another thread where I was saying.......
> >
> > "What if ActionForm was an inner class to a Value object. Or, what if a
> > Value object had a reference to an ActionForm which when filling with
> > parameters we did ActionFormValue.getActionForm(), filled it, complete
"does
> > it exist" checking and non-business object validation checking, and then
do
> > a ActionFormValue.setActionForm(ActionForm myform) to set it back, which
> > would fill the ActionFormValue object with the values in the ActionForm.
An
> > "ActionValue" could hold 1 or more ActionsForm(s) , or could take
ActionForm
> > as a parameter, with which it would copy and "nativeize" the data in the
> > ActionForm. In this case an ActionValue would hold specific fileds for
the
> > beans it uses."
> >
> > My point here,....though I hope it is apparent, is that we need to send
> > value ojects through the system in a way in which it can complement/work
> > with Struts.
>
Re: [EJB] Design Patterns (was JavaReport ...)
Posted by Ted Husted <hu...@apache.org>.
The ActionForm beans can contain nested references, so you could just
set some other bean to it, then refer to myBean.propertyThis and
myBean.propertyThat. Of course, the other bean would have to have
standard String accessor and mutators, which is where it starts to fall
down. The other beans may need to use native types, and would want to
reject or transform an incoming String value being set to type. So if
you need two storage locations, joining the two classes loses its edge.
In general, I would say that ActionForms can be coupled to other beans,
but other beans should not be coupled to ActionForm bean (import the
Struts class). Because, in another environment, the ActionForm beans
might be replaced with another class that hooked up to non-HTTP user
interface (say, Swing), and we would want to be able to drop those in.
Of course, the other beans could be designed to accept values from any
given JavaBean via reflection, which would include an ActionForm bean.
It's my feeling that proper MVC/J2EE design implies that we are going to
be stuck with a set of ActionForm beans and a set of other beans, and
need to find the best way to transfer data between the two.
Jonathan Asbell wrote:
>
> I was on this track in another thread where I was saying.......
>
> "What if ActionForm was an inner class to a Value object. Or, what if a
> Value object had a reference to an ActionForm which when filling with
> parameters we did ActionFormValue.getActionForm(), filled it, complete "does
> it exist" checking and non-business object validation checking, and then do
> a ActionFormValue.setActionForm(ActionForm myform) to set it back, which
> would fill the ActionFormValue object with the values in the ActionForm. An
> "ActionValue" could hold 1 or more ActionsForm(s) , or could take ActionForm
> as a parameter, with which it would copy and "nativeize" the data in the
> ActionForm. In this case an ActionValue would hold specific fileds for the
> beans it uses."
>
> My point here,....though I hope it is apparent, is that we need to send
> value ojects through the system in a way in which it can complement/work
> with Struts.
Re: [EJB] Design Patterns (was JavaReport ...)
Posted by Jonathan Asbell <ja...@i-2000.com>.
I was on this track in another thread where I was saying.......
"What if ActionForm was an inner class to a Value object. Or, what if a
Value object had a reference to an ActionForm which when filling with
parameters we did ActionFormValue.getActionForm(), filled it, complete "does
it exist" checking and non-business object validation checking, and then do
a ActionFormValue.setActionForm(ActionForm myform) to set it back, which
would fill the ActionFormValue object with the values in the ActionForm. An
"ActionValue" could hold 1 or more ActionsForm(s) , or could take ActionForm
as a parameter, with which it would copy and "nativeize" the data in the
ActionForm. In this case an ActionValue would hold specific fileds for the
beans it uses."
My point here,....though I hope it is apparent, is that we need to send
value ojects through the system in a way in which it can complement/work
with Struts.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 8:03 AM
Subject: Re: [EJB] Design Patterns (was JavaReport ...)
> What I'm working on now are patterns for Struts development that can be
> used with or without Enterprise Beans. As mentioned, the J2EE blueprints
> are mostly about development patterns, and Enterprise Beans are one part
> of implementating those patterns. This work is the second part of the
> Strut by Strut series ("Stepping out").
>
> I had a long discussion with a BEA Weblogic employee the other day about
> this very thing. I think we need to more strongly seperate the J2EE
> patterns from the Enterprise Bean implementation. The idea being we
> should introduce people to the pattern first (presentation beans / data
> access beans / value object beans / helper beans), and then show where
> Enterprise Beans plug into that. Or, where you would roll your own.
>
> On the Struts front, while it is often the case that the ActionForm
> beans end up looking like many of your internal beans, there are
> important differences. For example, ActionForm beans should be immutable
> except by the actor, meanwhile many of your internal beans should be
> immutable except by the model. ActionForm beans need to use Strings as
> the primary type, but your internal beans may need native types to
> commune with the business logic beans. You really only need ActionForm
> beans to get input from the actor. When sending read-only views back,
> you can use any kind of bean you want (with the bean tags), so long as
> it has a reasonable toString(). It seems wasteful at first, but in the
> big picture, it seems like treating ActionForm beans as HTTPD
> throw-aways is the only way to keep the application loosely coupled, and
> able to attach to other environments later.
>
> Of course, data transfer becomes a big issue when you have to ferry
> things from ActinForm beans to data-access beans (and then back again in
> the case of an update). What I'm looking at now is using hashmaps as a
> standard data transfer agent. If the ActionForm can return a hashmap
> that matches the data access bean you can use BeanUtil.populate() to
> make the switch. Coming back later, if the value object bean returns a
> hashmap, you can use BeanUitl.populate() to fill your ActionForm bean
> (for an update). This would mean that your ActionForm bean design
> "knows" about your value object bean design, but I think that's OK
> (though the inverse would not be OK).
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
>
> "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" wrote:
> >
> > To Anyone It Concerns,
> >
> > Although I'm relatively new to EJB's, I'm listed on the 1.1 TODO list
> > to add better EJB support/design patterns. Ideas that anyone has about
> > things that they'd like Struts to do with EJB's will definately help me
> > along with this and help Struts quiet this EJB fud. I'm looking to get
> > started on this soon, and anyone who wants to is more than welcome to
> > help me out.
> >
> > - Mike
>
Re: [EJB] Design Patterns (was JavaReport ...)
Posted by Ted Husted <hu...@apache.org>.
What I'm working on now are patterns for Struts development that can be
used with or without Enterprise Beans. As mentioned, the J2EE blueprints
are mostly about development patterns, and Enterprise Beans are one part
of implementating those patterns. This work is the second part of the
Strut by Strut series ("Stepping out").
I had a long discussion with a BEA Weblogic employee the other day about
this very thing. I think we need to more strongly seperate the J2EE
patterns from the Enterprise Bean implementation. The idea being we
should introduce people to the pattern first (presentation beans / data
access beans / value object beans / helper beans), and then show where
Enterprise Beans plug into that. Or, where you would roll your own.
On the Struts front, while it is often the case that the ActionForm
beans end up looking like many of your internal beans, there are
important differences. For example, ActionForm beans should be immutable
except by the actor, meanwhile many of your internal beans should be
immutable except by the model. ActionForm beans need to use Strings as
the primary type, but your internal beans may need native types to
commune with the business logic beans. You really only need ActionForm
beans to get input from the actor. When sending read-only views back,
you can use any kind of bean you want (with the bean tags), so long as
it has a reasonable toString(). It seems wasteful at first, but in the
big picture, it seems like treating ActionForm beans as HTTPD
throw-aways is the only way to keep the application loosely coupled, and
able to attach to other environments later.
Of course, data transfer becomes a big issue when you have to ferry
things from ActinForm beans to data-access beans (and then back again in
the case of an update). What I'm looking at now is using hashmaps as a
standard data transfer agent. If the ActionForm can return a hashmap
that matches the data access bean you can use BeanUtil.populate() to
make the switch. Coming back later, if the value object bean returns a
hashmap, you can use BeanUitl.populate() to fill your ActionForm bean
(for an update). This would mean that your ActionForm bean design
"knows" about your value object bean design, but I think that's OK
(though the inverse would not be OK).
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
"SCHACHTER,MICHAEL (HP-NewJersey,ex2)" wrote:
>
> To Anyone It Concerns,
>
> Although I'm relatively new to EJB's, I'm listed on the 1.1 TODO list
> to add better EJB support/design patterns. Ideas that anyone has about
> things that they'd like Struts to do with EJB's will definately help me
> along with this and help Struts quiet this EJB fud. I'm looking to get
> started on this soon, and anyone who wants to is more than welcome to
> help me out.
>
> - Mike