Hi Chris,
2007/1/25, Christopher Schultz <[EMAIL PROTECTED]>:
I agree with Dave: you're trying to do too much in your forms.
I disagree. There are two options that I consider acceptable for me.
One of them is to write getters and setters for each form's field
(just like a form bean). The other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Célio,
Célio Cidral Junior wrote:
> The problem happens when the user
> is *altering* an existing customer (creating a new customer works
> fine), more specifically when the user is submitting changes from the
> form to an existing customer object (al
I think your best bet would be to break up the parameter setting into 2
parts. (A variation on the paramsPrepareParamsStack) The first part would
set all parameters needed to load the data from the data. Then in the
prepare, you would have the id's needed to load the data from the database.
The
Célio Cidral Junior wrote:
Well, having Struts passing parameters in the order defined by the
html form would solve my problem. :-)
While setting parameters in a request struts has no idea what order they
were ordered in the originally generated form--remember that a single
action may be cal
2007/1/25, Tom Schneider <[EMAIL PROTECTED]>:
Unfortunately I don't think that's possible. The parameters get put into a
map structure, so the original parameter order is lost by the time it gets
to the servlet API. We've run into several instances where something will
work on one app server, b
Unfortunately I don't think that's possible. The parameters get put into a
map structure, so the original parameter order is lost by the time it gets
to the servlet API. We've run into several instances where something will
work on one app server, but break on another because we had duplicate
pa
2007/1/25, Tom Schneider <[EMAIL PROTECTED]>:
This is an issue with the typical edit/save scenario. The problem we are
discussing is that the domain model is needed in some form before the
parameter can be repopulated from the form save. The technique you are
using is to reread the data from th
This is an issue with the typical edit/save scenario. The problem we are
discussing is that the domain model is needed in some form before the
parameter can be repopulated from the form save. The technique you are
using is to reread the data from the database before the parameters are
set. An a
2007/1/25, Dale Newfield <[EMAIL PROTECTED]>:
Célio Cidral Junior wrote:
> Implementing Preparable does not seem to solve the problem because the
> parameters are set before the prepare() method is invoked.
Which is needed in order to know which object to retrieve from the DB.
I think you have
Célio Cidral Junior wrote:
Implementing Preparable does not seem to solve the problem because the
parameters are set before the prepare() method is invoked.
Which is needed in order to know which object to retrieve from the DB.
This model usually includes including the parameters interceptor tw
2007/1/25, Dave Newton <[EMAIL PROTECTED]>:
From my point of view it seems like your implementation is broken: if you need
to create a Customer from an ID passed via a form or URL then you either need
to implement Preparable or do the DAO operations in the (in your case) input or
save methods.
From: Célio Cidral Junior
> public Customer getCustomer() {
> if (customer == null)
> customer = id != 0 ? dao.get(id) : new Customer();
> return customer;
> }
> [...]
> The way I built both the action and the view prevents me from writi
12 matches
Mail list logo
