You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Hubert Rabago <hr...@gmail.com> on 2005/10/12 20:39:41 UTC
Reset for DynaActionForm
Does anyone have any opinion on this?
http://issues.apache.org/bugzilla/show_bug.cgi?id=37057
I would like to tackle this problem, but both solutions I can think of
have gotchas. Is it too late for a DTD change in 1.3?
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Hubert Rabago <hr...@gmail.com>.
> -----Original Message-----
> From: Ted Husted [mailto:ted.husted@gmail.com]
> Sent: Wednesday, October 12, 2005 5:44 PM
> To: Struts Developers List
> Subject: Re: Reset for DynaActionForm
>
> Right now, a lot of Java web applications flit from action to action.
> We migth use one action to display the page the first time,
> and then submit to another action after the form is filled
> out, and so forth.
In Struts, this is because if an action mapping requires a form, the
values have to be there when that mapping is called. Again, from my
example:
<action path="/edit" type="PrepareFormAction"/>
<action path="/save" type="SubmitFormAction" name="myForm" input="/edit.jsp"/>
When the form is first shown ("/edit"), Struts doesn't call reset().
> But, another popular paradigm, going back to the Perl days,
> is to keep submitting back to the same URI. The first time
> the page is retrieved, it is by GET. After that, it is
> submitted back by POST (aka PostBack).
In our case, we can do this with maybe a DispatchAction. Still, it'd
trigger a call to populate the form, which again makes a call to
reset() (to clear those checkboxes) necessary.
<snip/>
> Apparently, Michael wants to do something simliar with Struts
> Dialogs, which seems reasonable to me, if there's a
> reasonable way to do it.
Yeah, I've thought that the reason I'm not understanding Michael is
because the use case is specific for Struts Dialogs. It doesn't seem
to make sense with the usual "show the prepopulated form" + "submit
the user modified form" that I'm used to.
> -Ted.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Michael Jouravlev <jm...@gmail.com>.
On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 10/12/05, Ted Husted <te...@gmail.com> wrote:
> > On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> > In an environment like JSF or ASP.NET, the framework makes a clear
> > distinction between the initial GET and subsequent POSTs. During the
> > GET, we prepopulate the components, which then retain their state
> > across the subsequent POSTs.
> >
> > Apparently, Michael wants to do something simliar with Struts Dialogs,
> > which seems reasonable to me, if there's a reasonable way to do it.
>
> Um, I am already doing this ;-) MailReader uses exactly this concept.
> It is even better than ASP.NET, which binds only one markup page per
> code-behind class (am I right?). Struts allows to have unlimited
> number of pages. I check the current action state, and forward to an
> appropriate page.
This page contains the description of what am I doing with Struts:
http://struts.sourceforge.net/strutsdialogs/#codebehind
But I could not explain it as simple as Ted did ;-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Michael Jouravlev <jm...@gmail.com>.
On 10/12/05, Ted Husted <te...@gmail.com> wrote:
> On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> > I'm still trying to understand why the distinction is important. :)
> >
> > Someone help me!
>
> Right now, a lot of Java web applications flit from action to action.
> We migth use one action to display the page the first time, and then
> submit to another action after the form is filled out, and so forth.
>
> But, another popular paradigm, going back to the Perl days, is to keep
> submitting back to the same URI. The first time the page is retrieved,
> it is by GET. After that, it is submitted back by POST (aka PostBack).
>
> In an environment like JSF or ASP.NET, the framework makes a clear
> distinction between the initial GET and subsequent POSTs. During the
> GET, we prepopulate the components, which then retain their state
> across the subsequent POSTs.
Thank you, Ted! :-))
> Apparently, Michael wants to do something simliar with Struts Dialogs,
> which seems reasonable to me, if there's a reasonable way to do it.
Um, I am already doing this ;-) MailReader uses exactly this concept.
It is even better than ASP.NET, which binds only one markup page per
code-behind class (am I right?). Struts allows to have unlimited
number of pages. I check the current action state, and forward to an
appropriate page.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Ted Husted <te...@gmail.com>.
On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> I'm still trying to understand why the distinction is important. :)
>
> Someone help me!
Right now, a lot of Java web applications flit from action to action.
We migth use one action to display the page the first time, and then
submit to another action after the form is filled out, and so forth.
But, another popular paradigm, going back to the Perl days, is to keep
submitting back to the same URI. The first time the page is retrieved,
it is by GET. After that, it is submitted back by POST (aka PostBack).
In an environment like JSF or ASP.NET, the framework makes a clear
distinction between the initial GET and subsequent POSTs. During the
GET, we prepopulate the components, which then retain their state
across the subsequent POSTs.
Eventually, when the Use Case for the page is resolved, we would
transfer to another page. But most JSF or ASP.NET wizards just keep
POSTing back to the same page until the task is complete.
Apparently, Michael wants to do something simliar with Struts Dialogs,
which seems reasonable to me, if there's a reasonable way to do it.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Hubert Rabago <hr...@gmail.com>.
I'm still trying to understand why the distinction is important. :)
Someone help me!
Hubert
On 10/12/05, Ted Husted <te...@gmail.com> wrote:
> We'd pretty much have to go with (2), I think.
>
> The reset flag seems all right, especially if you can distingish
> between GET and POST, as Micheal was asking. This would jive well with
> the new form feature that makes it easy to submit back (or post back)
> to the same action.
>
> I would not consider the DTD locked at this point.
>
> -Ted.
>
> On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> > Does anyone have any opinion on this?
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=37057
> >
> > I would like to tackle this problem, but both solutions I can think of
> > have gotchas. Is it too late for a DTD change in 1.3?
> >
> > Hubert
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> HTH, Ted.
> http://www.husted.com/poe/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Ted Husted <te...@gmail.com>.
We'd pretty much have to go with (2), I think.
The reset flag seems all right, especially if you can distingish
between GET and POST, as Micheal was asking. This would jive well with
the new form feature that makes it easy to submit back (or post back)
to the same action.
I would not consider the DTD locked at this point.
-Ted.
On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> Does anyone have any opinion on this?
> http://issues.apache.org/bugzilla/show_bug.cgi?id=37057
>
> I would like to tackle this problem, but both solutions I can think of
> have gotchas. Is it too late for a DTD change in 1.3?
>
> Hubert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Joe Germuska <Jo...@Germuska.com>.
At 3:06 PM -0700 10/12/05, Don Brown wrote:
>No, by can of worms, I'm referring to the adding of configuration
>data to form properties ala action mappings. I suppose such
>additions are inevitable, so it isn't a big concern.
FormPropertyConfig extends BaseConfig, which is the nexus of
"arbitrary config properties," so one *could* achieve this with no
DTD changes, just by using <set-property key="X" value="Y" />
elements.
I'm not particularly opposed to extensions to the DTD either, and
there's something to be said for the clarity of explicit attributes.
But I just wanted to point out that that's available.
Joe
>As for making DTD changes now, I have no problem with it.
>
>Don
>
>Hubert Rabago wrote:
>>Yeah, I like the second, too.
>>Which can of worms are you talking about, though? The DTD change? I
>>was thinking, since we don't have a release yet, it ain't locked yet. Right?
>>
>>Hubert
>>
>>On 10/12/05, Don Brown <mr...@twdata.org> wrote:
>>
>>>I like the second, I suppose, but it does open up a can of worms :/
>>>
>>>Don
>>>
>>>Hubert Rabago wrote:
>>>
>>>>Does anyone have any opinion on this?
>>>>http://issues.apache.org/bugzilla/show_bug.cgi?id=37057
>>>>
>>>>I would like to tackle this problem, but both solutions I can think of
>>>>have gotchas. Is it too late for a DTD change in 1.3?
>>>>
>>>>Hubert
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Don Brown <mr...@twdata.org>.
No, by can of worms, I'm referring to the adding of configuration data to form
properties ala action mappings. I suppose such additions are inevitable, so it
isn't a big concern.
As for making DTD changes now, I have no problem with it.
Don
Hubert Rabago wrote:
> Yeah, I like the second, too.
> Which can of worms are you talking about, though? The DTD change? I
> was thinking, since we don't have a release yet, it ain't locked yet.
> Right?
>
> Hubert
>
> On 10/12/05, Don Brown <mr...@twdata.org> wrote:
>
>>I like the second, I suppose, but it does open up a can of worms :/
>>
>>Don
>>
>>Hubert Rabago wrote:
>>
>>>Does anyone have any opinion on this?
>>>http://issues.apache.org/bugzilla/show_bug.cgi?id=37057
>>>
>>>I would like to tackle this problem, but both solutions I can think of
>>>have gotchas. Is it too late for a DTD change in 1.3?
>>>
>>>Hubert
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Hubert Rabago <hr...@gmail.com>.
Yeah, I like the second, too.
Which can of worms are you talking about, though? The DTD change? I
was thinking, since we don't have a release yet, it ain't locked yet.
Right?
Hubert
On 10/12/05, Don Brown <mr...@twdata.org> wrote:
> I like the second, I suppose, but it does open up a can of worms :/
>
> Don
>
> Hubert Rabago wrote:
> > Does anyone have any opinion on this?
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=37057
> >
> > I would like to tackle this problem, but both solutions I can think of
> > have gotchas. Is it too late for a DTD change in 1.3?
> >
> > Hubert
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Don Brown <mr...@twdata.org>.
I like the second, I suppose, but it does open up a can of worms :/
Don
Hubert Rabago wrote:
> Does anyone have any opinion on this?
> http://issues.apache.org/bugzilla/show_bug.cgi?id=37057
>
> I would like to tackle this problem, but both solutions I can think of
> have gotchas. Is it too late for a DTD change in 1.3?
>
> Hubert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Hubert Rabago <hr...@gmail.com>.
Apologies, I'm on my way out. I only wanted to respond to a couple of
items, below:
On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > No, what I'm saying is Struts doesn't distinguish between the two
> > (AFAIK). However, you seem to.
>
> I do, but Struts don't. You have said before, that reset() is called
> only when form is submitted. So I asked you, how Struts knows that a
> form was submitted?
Via the action mapping.
<action path="/edit" type="PrepareFormAction"/>
<action path="/save" type="SubmitFormAction" name="myForm" input="/edit.jsp"/>
"/edit" doesn't call reset(), "/save" does.
> reset() is always called when request is serviced by an action.
Actually, reset() is called only when the mapping specifies a form.
Which should mean that the form should be populated with values coming
from request parameters.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reset for DynaActionForm
Posted by Craig McClanahan <cr...@apache.org>.
On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:[snip]
> No. reset() is supposed to be overriden by an application developer,
> it is empty by default. But I cannot override reset() on a dynabean,
> can I? I suppose that I cannot, please correct me if I am wrong.
Sure you can.
* Write a class that extends DynaActionForm and implements
your custom reset() method.
* Use this as the "className" attribute value instead of
DynaActionForm.
Yes, you have to write a class for each bean where you need a custom reset()
method, but it only needs to contain reset() -- you don't have to write all
the getters and setters that you would in a standard form bean. Indeed, your
reset() method has direct access to the underlying Map named dynaValues,
which contains the actual name/value pairs ... and that's what you would
actually be changing.
Craig
Re: Reset for DynaActionForm
Posted by Michael Jouravlev <jm...@gmail.com>.
Moved from: User List, [FORMDEF] Resetting booleans for session-scoped dynaforms
On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > I am telling you that checkbox values should be cleared, you are
> > telling me that reset() is get called. Don't you think these are
> > different things? ;-)
>
> I don't think there are any disagreements there. :) We're discussing
> clearing these values in reset(), right?
No. reset() is supposed to be overriden by an application developer,
it is empty by default. But I cannot override reset() on a dynabean,
can I? I suppose that I cannot, please correct me if I am wrong.
Therefore, we are talking about something that framework does before
it calls reset()
> > The sole purpose of reset() is to be called by Struts before form is
> > populated.
>
> Yes. Major point here.
>
> > Checkbox is an input element. Input element is part of HTML form. HTML
> > form is submitted with POST method by default, and I don't know anyone
> > who overrides HTTP method to use GET for that.
> >
> > Therefore, I want to clear checkboxes only when POST request comes.
>
> Struts doesn't forbid form submission using GET.
Did I say that it did? I said that in 99% cases form is submitted
using default method, which is POST. Yes, it is possible to submit a
form with GET, but this is not common, maybe for search engines, when
they produce idempotent results. Differentiation between POST and GET
is not exactly equal to differentiation between input phase and render
phase, but is close enough.
> > Do you want to say, that Struts somehow gets to know that a form was
> > submitted? How exactly does it do that? Can you show it in the code?
> > There is nothing in request which says "this stuff comes from an HTML
> > form". Struts just gets a request with bunch of name/value pairs, and
> > this is it. How should it know that this is a submission?
>
> No, what I'm saying is Struts doesn't distinguish between the two
> (AFAIK). However, you seem to.
I do, but Struts don't. You have said before, that reset() is called
only when form is submitted. So I asked you, how Struts knows that a
form was submitted?
> Regardless of your conventions for GET and POST, I still don't
> understand how a call to reset() when a form is submitted messes up
> your prepopulation routine when no forms are being submitted and
> reset() doesn't get called.
reset() is always called when request is serviced by an action.
Anyway, this is not about reset(), which I can override when I
subclass a regular ActionForm. This is about clearing of checkbox
values, which currently cannot be done declaratively.
Irrelevant to FormDef, I want to use dynaforms. And I *do* care about
differences between GET and POST. It is possible to implement the
change in a way, that it would work for those who cares about this
difference, and for those who do not. So, why not to do it so it would
work for everyone? I am not suggesting something that would work for
me only.
I would say that the change is not about when to call reset(). It is
about direct setting of bean properties before reset() is called.
I am suggesting to use reset attribute as follows:
1) reset attribute is not set for a property ==> initial value is set
only once, when dynaform is created. Property is not reset on request
(initial value does not have to be "false". Setting initial value when
form is constructed, and clearing this value on request are two
different things).
2) reset="true" or reset="all" ==> value is reset to false or empty
string for every incoming request, when form is reused.
3) reset=<request methods> like reset="POST" or reset="POST, HEAD" ==>
value is reset to false or empty string if incoming request has
selected type.
<form-property
name="someFlag"
type="java.lang.String"
initial="false"
reset="POST"/>
I can prepare and submit a patch for that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org