My jsps currently assume use of the form specified in
the mapping from <html:form action="mapping">. I
suppose it's not a problem to always include the name
property in my tags, and assign that the generic form
bean name. It's a little bothersome though that the
action writer needs to know what kind of object to
create where for each local forward, and that pulling
the data from the model is now duplicated in this
action and in the generic form. My current design
forwards with the UID of the data as a request
parameter, the form is created for me, I populate it
from the model in the reset method, then the other
request paramters are populated for me, just like when
the generic form is submitted. Seems a lot more
straightforward, and I can still use a local forward
to keep the navigation contained in the struts-config,
and avoid form population anomalies, if I do this:
forward = new
ActionForward((mapping.findForward("forward")).getName()+"?UID="+UID,true);
Is there really a problem with this approach?My jsps
currently assume use of the form specified in the
mapping from <html:form action="mapping">. I suppose
it's not a problem to always include the name property
in my tags, and assign that the generic form bean
name. It's a little bothersome though that the action
writer needs to know what kind of object to create
where for each local forward, and that pulling the
data from the model is now duplicated in this action
and in the generic form. My current design forwards
with the UID of the data as a request parameter, the
form is created for me, I populate it from the model
in the reset method, then the other request parameters
are populated for me, just like when the generic form
is submitted. Seems a lot more straightforward, and I
can still use a local forward to keep the navigation
contained in the struts-config, and avoid form
population anomalies, if I do this:
forward = new
ActionForward((mapping.findForward("forward")).getName()+"?UID="+UID,true);
Are there problems I need to be aware of, with this
approach?
--- David Graham <[EMAIL PROTECTED]> wrote:
> >You have to take that relationship on faith.
> Perhaps
> >it's not the best example, but suffice it to say
> that
> >I have many-to-many types of relationships in my
> data,
> >and that the Forms are best segregated for re-use.
> It
> >is highly inefficient for me to make a separate
> form
> >for each combination of data relationship.
> >Futhermore, there are many levels involved here.
> >Distributions have Shipments, Shipments have
> Orders,
> >Orders Have Items, Items have Tasks, Tasks have
> >TaskDetails. Are you really suggesting I put all
> this
> >in one Form? If I make a screen to query for
> >TaskDetails which then uses the same jsp to display
> >the results as the one that is linked to by the
> Task
> >screen, then I must use this giant Form with mostly
> >inconsequential fields, and add my TaskDetail query
> >screen specifics to it, too.
>
> If you have a generic query result page then you
> need to supply it with a
> generic result bean to display the data. Your
> TaskDetailQueryForm object is
> handled by your TaskDetailQueyAction which then puts
> your generic result
> bean in the request and forwards to the result page.
> I don't see why you
> would need action chaining here.
>
> David
>
> >Where does it end? My
> >other options are to make a new jsp, or make a jsp
> >with some really nasty scriptlet in it to handle
> >different forms. Right?
> >
> >
> >--- David Graham <[EMAIL PROTECTED]> wrote:
> > >
> > > >There are, however, situations where the second
> > > screen
> > > >really has nothing to do with the first. For
> > > example,
> > > >an Order screen and an OrderItem screen. When
> > > >navigating from Order to OrderItem, I should
> not go
> > > >directly to OrderItem.jsp for two reasons. The
> > > >OrderItemForm is unrelated to the OrderForm and
> > > should
> > > >not be part of the OrderForm object. Given
> this,
> > > it
> > > >*could* still be ok to go to OrderItem.jsp when
> it
> > > >uses it's own Form object, but not if you need
> to
> > > pass
> > > >through OrderItemAction to verify the user is
> > > logged
> > > >in. The other options are action chaining from
> the
> > > >OrderAction to the OrderItem mapping, or
> linking
> > > from
> > > >the Order.jsp to the OrderItem mapping, both of
> > > which
> > > >are considered bad. What else is there?
> > >
> > > Why is an order unrelated to its items? I would
> > > have one class called
> > > OrderForm that contained a List or array of all
> the
> > > items being ordered.
> > > One ActionForm object does not necessarily map
> to
> > > one HTML form. You can
> > > split up the view however you like but store all
> the
> > > data in one form
> > > object.
> > >
> > > David
> > >
> > > >
> > > >m
> > > >
> > > >
> > > >--- David Graham <[EMAIL PROTECTED]>
> wrote:
> > > > > >So if I understand what you're suggesting,
> I
> > > put
> > > > > >multiple html forms into editPage.jsp, one
> of
> > > which
> > > > > >maps to ConfirmEditAction. Not bad,
> although,
> > > what
> > > > > I
> > > > > >have in this form now is a drop down for
> the
> > > user
> > > > > to
> > > > > >specify what they intend to do.
> > > > >
> > > > > Sorry, I think the steps would actually be
> like
> > > > > this:
> > > > > GetEditPageAction --> editPage.jsp -->
> > > > > GetConfirmPageAction --> confirm.jsp
> > > > > --> SaveFormAction --> index.jsp
> > > > >
> > > > > Just use different submit buttons for
> different
> > > > > actions like Update and
> > > > > Delete. Your SaveFormAction will perform
> > > different
> > > > > operations based on
> > > > > which button they pressed.
> > > > >
> > > > > >Also, if I want to use
> > > > > >this single, generic, confirmation page in
> > > multiple
> > > > > >places, which I do, I'll have to use
> scriptlet
> > > > > rather
> > > > > >than the html:form tag to render the
> correct
> > > action
> > > > > >attribute to take them back to the edit
> they
> > > came
> > > > > >from, right?
> > > > >
> > > > > Then you will also need a generic
> SaveFormAction
> > > to
> > > > > save the data from your
> > > > > generic confirm page. You might look at
> using
> > > > > DispatchAction to use one
> > > > > action to route to different pages based on
> a
> > > > > request parameter.
> > > > >
> > > > > David
> > > > >
> > > > > >
> > > > > >m
> > > > > >
> > > > > >--- David Graham <[EMAIL PROTECTED]>
> > > wrote:
> > > > > > > >If my need, for example, is to go from
> > > > > > > >an "Edit X" screen, to a "Confirm X
> > > deletion"
> > > > > > > screen,
> > > > > > > >how is this related to business logic,
> and
> > > how
> > > > > > > would I
> > > > > > > >refactor?
> > > > > > >
> > > > > > > GetEditPageAction --> editPage.jsp -->
> > > > > > > ConfirmEditAction --> index.jsp
> > > > > > >
> > > > > > >
> > > > > > > David
> > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
>
>_________________________________________________________________
> > > > > > > Help STOP SPAM with the new MSN 8 and
> get 2
> > > > > months
> > > > > > > FREE*
> > > > > > >
> http://join.msn.com/?page=features/junkmail
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
>
>---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > > > > > >
> [EMAIL PROTECTED]
> > > > > > > For additional commands, e-mail:
> > > > > > > [EMAIL PROTECTED]
> > > > > > >
> > > > > >
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
