Robert Nicholson wrote:
> With struts the form beans capture all state relating to a form. Or at least
> that's how I think it's designed.
>
Yes ... that was the original design intent behind form beans.
>
> Now, I can see how this is appropriate when you want to redisplay the form
> to the user when there are errors and want to keep all the original values
> intact. ie. sticky values.
>
That is exactly their purpose. Note that the properties of a form bean should
reflect what the user actually entered -- even if the combination of values currently
entered does not pass all your validation rules (for example, a required field was
left blank).
This is the key reason you do *not* want to use Java objects that directly represent
your underlying database data as a form bean.
>
> What I want to know is ... how do things get from a database into a form
> bean?
>
Good question. See below for comments on your approach to this.
>
> When allowing the the user to view/modify contents of a record you'll use a
> form bean to capture the displayable/editable state of the record so does
> that mean that you also have to take the data from the database and put it
> into a form bean? This is easy for textfields. If you have checkboxes/select
> lists what does your .jsp code look like? For every option you have to pass
> it's value and compare against the beans value right?
>
Ideally, you would use boolean properties to correspond to checkboxes, and indexed
boolan properties (or properties that you get and set with an array of booleans) for
groups of related options. Unfortunately -- and this is an area Struts does not have
right yet, although there are some suggestions for dealing with it -- you run into
problems with the way that browsers submit their values. If a checkbox is checked
the field is submitted, and if the checkbox is not checked then it is not. If your
form bean properties have one-to-one correspondence to the input fields, you can
infer that the lack of a submitted value for a checkbox means the corresponding
boolean property should be set to false.
But what if you use a form bean to contain the properties for a multi-page
interaction with the user (like a wizard dialog)? Now, the lack of entry for the
field is ambiguous -- it could mean the field was unchecked, or it could mean the
field was not present on this particular page. For Struts we're going to need to
build in some mechanism to make this unambiguous. Outside of Struts, this is one of
the tricky aspects of form management to keep in mind.
For numeric properties, Struts deals with the simple conversion cases (to String for
display, to numeric for property storage) for you. Enhancements are planned to deal
with Locale-sensitive conversions and formatted displays (such as putting dollar
signs and commas in the right places for a US-locale presentation of currency
amounts). If you're not using Struts, you are on your own for these types of
conversions :-).
>
> I will not use struts as I'm working on an ongoing project but I have some
> input in how I handle my form processing. The team already puts all form
> processing in jsp pages and I'm using servlets.
>
> So, if I have everything understood correctly I'm gonna have write my code
> like this.
>
> I will want to browse a record and allow the user to make changes.
>
> So my form will be written to query it's layout based on the state of the
> form bean. So I'll populate said bean in my servlet that reads the database
> for the selected browsed record put that into the request as a request
> attribute and my form will conditonalize it's layout values based on the
> contents of the form bean . In addition my form will also have to use
> setProperty: on the form bean from the request attributes so that it can
> redisplay the new values after I dispatch from my form's handling servlets
> correct. At all times the form queries the form bean for it's values and I'm
> just trying to get my head around how the form bean gets those values
>
> 1. When read from the database.
>
> I have to explicitly configure the formbean from these values.
>
Yes.
One of the enhancements I'm considering in Struts is a utility method that takes a
bean and a java.sql.Row, and uses reflection to copy the column values to the
corresponding properties (the same way that Struts uses reflection to set the values
of a bean based on the request parameters). In the mean time, you're probably going
to have a bunch of set method calls.
>
> 2. When edited in the from.
>
> I use setProperty to that the beans properties are automatically set from
> the request attributes.
>
I assume you submitting back to the same JSP page the form was on (i.e. not using the
typical Model 2 approach)?
>
> Q. Since I'm using 1 and 2. The initial request to display the form won't
> have any request parameters as I'm setting a request attribute ie. the form
> bean and populating the form via that. My beans properties won't be
> overwritten by the setProperty in the form right? ie. if there's no
> parameters in the request my form bean will come through untouched by
> setProperty right?
>
Here's one possible approach to this issue -- put the <jsp:setProperty> call inside
the <jsp:useBean>, like this:
<jsp:useBean id="mybean" class="....." scope="request">
<jsp:setProperty name="mybean" property="*"/>
</jsp:useBean>
What happens now depends on whether the request attribute is present already or not.
If you have prepopulated the bean and stored it as a request attribute (under key
"mybean") before forwarding to this page, the <jsp:useBean> tag will see that the
attribute already exists, and skip the nested content (i.e. the <jsp:setProperty>
tag). On the other hand, if the bean doesn't exist yet (because the user submitted
the form straight to this bean), the bean will be created and then it's properties
populated from the request parameters.
>
> Am I making sense?
>
> This sounds feasible right?
>
It's feasible, but keep in mind that designing your application in this manner gives
up the "separation of business logic and presentation logic" advantages of an
MVC-style approach. For simple applications this can work quite well -- but it
doesn't scale well as complexity increases, because you've mixed the two separate
functions together so changes to one directly impact the other.
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
