Hi,
I am trying to create text fields dynamically in a form at the request time.
I need to have two text fields in a table row and an "ADD" button. When the
user clicks on "ADD" button, the form should refresh and shows another row with
two text fields and so on. In case if I have entered some data into any of
these text fields, the data should be prepopulated when the form refreshes. I
have "SUBMIT" button, when clicked, form action will be performed. I am using
DynaValidatorActionForm here. I am stuck up with this problem for the last two
days. Can anyone please send me a sample of code for JSP and struts-config.xml?
Thanks,
Sudha
Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 5/9/06, Niall Pemberton wrote:
> On 5/4/06, Michael Jouravlev wrote:
> > What we has been brought from the stone ages:
> >
> > * Base Action class does not dispatch events
> > * DispatchAction and its flavors do, but they do not allow a user to
> > derive an action class from some another user's base action
> >
> > What we got now in 1.2.9 and 1.3.1+ :
> >
> > * ActionDispatcher resolves the inheritance issue, allowing any action
> > to dispatch events
> > * EventActionDispatcher makes dispatching an easy and fun task; it
> > also allows to separate input phase from render phase, at the same
> > time it allows to trigger event with links (GET), not only with
> > buttons (POST).
> >
> > What appears to be a logical next step:
> >
> > * Stick dispatching features in base Action, thus making all actions
> > to be dispatch actions.
> >
> > Benefits:
> >
> > * ActionDispatcher will not be needed.
> > * Any action will be able to dispatch events.
> > * This makes a mind shift, making people think more in terms of events
> > and independent webresources, kind of like .NET's code-behind.
> >
> > Minor drawback:
> >
> > * only one dispatching behavior can be chosen. Considering all job
> > done before, we how have best-of-breed EventDispatchAction. Its
> > features (maybe in some modified manner) should be pushed to base
> > Action class. For those who rely on old-style DispatchAction or
> > MappingDispatchAction, they will still be available.
> >
> > So, the proposed feature changes nothing for regular Action users, it
> > changes nothing for old DispatchAction users, but it makes things a
> > lot simpler for those who want to switch to event-based paradigm with
> > as little efforts as possible.
> >
> > Thoughts? Objections? Suggestions?
>
> Personally I'm against this because IMO it just adds
> confusion/complexity to the Action class that is unnecessary for users
> who don't want to use the "dispatch" style.
The idea is to add dispatching features to an action class (and, I
think, to Command as well) while keeping current apps working. I think
this is possible. Unless the dispatching mapping is defined, nothing
would change for a user.
> I also think that the
> current provision for "dispatch" flavours isn't a real barrier for
> people to adopt the style that you're promoting here.
Most "flavors" of dispatch action have issues, so while they should
remain available, I believe that they should be deprecated. If not
deprecated, their location at "Extras" Gulag is quite appropriate. I
believe that at this moment SAF1 has one dispatching action
(EventDispatchAction) that solves most of the issues of DispatchAction
or LookupDispatchAction while providing more features.
> For people not limited/restricted by having to inherit from a "base"
> action class, they can simply inherit from one of the DispatchAction
> falvours.
Well, they won't have to do that. Every action will be a dispatching
action (if needed). This is logical, especially considering that
according to Front Controller spec, Action has Dispatcher role :) This
will also allow to debunk the claim that Struts has no notion of
events ;-)
> For people limited/restricted by having to inherit from a "base"
> action class, they can use the ActionDispatcher (or
> EventActionDispatcher) to easily plug in dispatch behaviour.
Instead of using/learning bunch of classes people can have only one class.
> Simply making the code changes you suggest will not shift people's
> mindset - you would need to document the choices available. IMO
> documentation is more important than merging the dispatch logic into
> the Action class and if Action and DispatchAction flavours were better
> documented you could achieve the same without changing the code at
> all.
Better documentation will surely help, as well as easier access to
these features, like having them right in the core instead of in
Extras module, as well as recommending this approach as a good
practice. Users prefer "official" recommendations.
> I don't use any of the DispatchAction/ActionDispatcher flavours and am
> happy with "simple" Actions. If we do document this better I would
> prefer we didn't promote one style over the other - but simply layout
> what the choices people have and let them decide.
Niall, do you use separate setup/render and submit actions? Dispatch
action is basically the same thing, only you have one submit action
instead of several. Less classes, less mappings, is not it a good
thing? Maybe your use cases are different...
Considering that it is possible to use Command instead of Action in
1.3.x, I agree that dispatching functionality should be either
external to actions/commands, so both Command and Action could be used
for dispatch, or should be implemented in the core for both actions
and commands. Good point.
I hope that the fact that you (as well as some other committers) do
not use dispatch actions, will not affect the technical decision on
this issue. I believe that dispatch actions change the paradigm, and
allow to develop more resource-oriented webapps in Struts, comparing
to request-oriented or page-oriented. I like to think of
Action+ActionForm combo as of a code-behind class.
I think that having one dispatch action *is* better than a bunch of
action classes, and actually I was hoping on promoting this approach.
Anyway, I'll try to put together some [not too passionate] docs and
examples first :)
So, to recap:
* I will create drafts of docs and samples to promote dispatch actions
as a best practice (ok, ok, as a good practice)
* I will research the better and simpler way of providing dispatch
functionality,whether by implementing it in the core or by using
ActionDispatcher class.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
