You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Michael Jouravlev <jm...@gmail.com> on 2005/08/01 05:55:25 UTC
Re: 1.3.0 Release - Next Steps
On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> But, first things first, we should resolve the problem reports and roll 1.3.0.
Does this mean, that even if I present MailReader rewritten with
Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
future version?
Or will the answer be more definite after I show how to make
MailReader with dialogs?
Do you have any timeframe in mind for 1.3?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Dakota Jack <da...@gmail.com>.
Ooops! Forgot the "stuff". Here you go.
An endless source of aggravation is the HTML input image element. The
specification says that browsers should treat this control like an
image map. Unlike other buttons, it does not submit a string
representing the button's label, it submits the X and Y coordinates.
If you look at the HTTP post for an image button, you'll see it looks
something like this
myImageButton.x=200
myImageButton.y=300
For most other controls, a Struts developer can create a simple String
property to represent the element. This clearly won't work with an
image button, because it submits two "dotted" properties instead of a
simple "name=value" entry like other elements.
Happily, Struts allows an ActionForm to contain, or nest, other
JavaBeans, and will automatically populate the beans using the same
syntax as the image element. (What a co-inky-dink!)
To represent an image input element in your ActionForm, say what you
mean, and use an ImageButtonBean to capture the X and Y parameters.
public final class ImageButtonBean extends Object {
private String x = null;
private String y = null;
public String getX() {
return (this.x);
}
public void setX(String x) {
this.x = x;
}
public String getY() {
return (this.y);
}
public void setY(String y) {
this.y = y;
}
public boolean isSelected() {
return ((x!=null) || (y!=null));
}
} // End ImageButtonBean
Note that we've included a helper method on this bean, isSelected().
This just returns true if either the x or y property is not null. If
both are still null, then isSelected() returns false.
Here's how you could declare two ImageButtonBeans on an ActionForm.
// ..
private ImageButtonBean logonButton = new ImageButtonBean();
public void setLogonButton(ImageButtonBean button) {
this.logonButton = button;
}
public ImageButtonBean getLogonButton() {
return this.logonButton;
}
private ImageButtonBean cancelButton = new ImageButtonBean();
public void setCancelButton(ImageButtonBean button) {
this.cancelButton = button;
}
public ImageButtonBean getCancelButton() {
return this.cancelButton;
}
// ...
The next question will be "OK, which button did they push?", so let's
define another helper method on the ActionForm to tell us.
public String getSelected() {
if (getLogonButton().isSelected()) {
return Constants.LOGON;
}
if (getCancelButton().isSelected()) {
return Constants.CANCEL;
}
return null; // nobody home
}
In an Action, determining which button is pressed is then a simple
matter of asking the form what was selected.
String selected = ((myForm) form).getSelected();
if (Constants.CANCEL.equals(selected)) ...
Of course selected doesn't need to be a String; it could be an int, a
custom type to represent your API functions, or even the name of
another method for use with a DispatchAction.
Using "API helper methods" on ActionForms, as we did with
getSelected(), is a very useful technique. We'll use it again in Tip
#2, when we discuss the standard Dispatch Actions.
HTH, Ted.
On 8/17/05, Dakota Jack <da...@gmail.com> wrote:
> Here is Ted's 2002 offering: you will see that this has nothing to do
> with "stripping .x". I think, further, that what Ted is talking about
> originated with Hubert Rabago, although I am not suggesting that Ted
> is suggesting otherwise. Anyway, this is all irrelevnat.
>
> On 7/31/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> > > But, first things first, we should resolve the problem reports and roll 1.3.0.
> >
> > Does this mean, that even if I present MailReader rewritten with
> > Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
> > future version?
> >
> > Or will the answer be more definite after I show how to make
> > MailReader with dialogs?
> >
> > Do you have any timeframe in mind for 1.3?
> >
> > Michael.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Dakota Jack <da...@gmail.com>.
Here is Ted's 2002 offering: you will see that this has nothing to do
with "stripping .x". I think, further, that what Ted is talking about
originated with Hubert Rabago, although I am not suggesting that Ted
is suggesting otherwise. Anyway, this is all irrelevnat.
On 7/31/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> > But, first things first, we should resolve the problem reports and roll 1.3.0.
>
> Does this mean, that even if I present MailReader rewritten with
> Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
> future version?
>
> Or will the answer be more definite after I show how to make
> MailReader with dialogs?
>
> Do you have any timeframe in mind for 1.3?
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
For the 1.3.x release series, we decided to divy Strus 1.2.x into
several subprojects. Right now, I'm focussing on the Core, but we will
also have to release other subprojects like Apps, El, Taglib, and
Tiles to make it a complete distribution.
I expect Struts 1.3.0 to be released very quickly, but I don't expect
it to reach General Availability status. On average, it takes 4 to 6
releases before an Apache project goes from "alpha" to "beta" to
"General Availability". Each of these releases will have its own
serial number, 1.3.1, 1.3.2, 1.3.3, and so forth. If we start making
releases in the Struts 1.3.x series in early August, it possible that
we might see one of these release make GA grade by December. But
since no one is working on Struts full-time, it's not possible to
hazard more than a wild guess.
I have no idea whether the team wants to host several different
MailReaders in the Struts Apps package. Craig mentioned doing one for
Shale, and if one were written, I expect we would bundle it with the
Struts Shale subproject distribution. LIkewise, I would expect that
the Struts Dialog MailReader would be distributed with the Struts
Dialog extension.
-Ted.
On 7/31/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> > But, first things first, we should resolve the problem reports and roll 1.3.0.
>
> Does this mean, that even if I present MailReader rewritten with
> Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
> future version?
>
> Or will the answer be more definite after I show how to make
> MailReader with dialogs?
>
> Do you have any timeframe in mind for 1.3?
>
> Michael.
>
--
HTH, Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org