The best practice is to first validate the incoming data entry using the
Strut's ActionForm beans. There is a Validation servlet available that
automates much of this using regular expressions, and generates checks
using both client-side Javascript and server-side Java code.
Then, the Strings from the ActionForms can then be passed to your
Enterprise Beans. Depending on how your EB's are setup you can do this
with
1. Data conversion methods built into the Action Forms.
2. A generalized helper class.
3. Some other methods already available to you.
I'm work with CachedRowSets, which handle most of the data conversions
for me.
Struts is a very good choice for a data-entry applications, given the
limitations of HTML forms generally.
I'm rebuilding the data-entry portion of an application now, and should
be able to share most of the code next week as open source. It does not
use J2EE directly, but does follow the same design patterns. The view
portion of this is an online auction for a public broadcasting auction.
Most of the items are gone (we started with over 5000), but a few dozen
are still available at < http://data.wxxi.org/wxxi-gavel/ >. This also
is a Struts application, though we originally transfered the data from
another application.
My biggest tip is to use templates to design many common classes at
once. With a data-centric application, many operations are repeated for
each table, so I'm using a boilerplate form that lets me define several
related classes with one sweep with search and replace. (At least until
I get around to writing a real code generator!)
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Kris Vandenberk wrote:
>
> Hi,
>
> I work in a company where 90% of all applications being developed are mostly
> data-entry kinda applications (so a lot of data input, validations on that
> data ... and readonly views of that data)
>
> A lot of our clients 'heard' of J2EE and they insist on using J2EE for their
> new applications, which isn't a bad thing, although it is quite costly for
> applications only used by a 100 users.
>
> This aside, I have a couple of questions:
> * what is at this moment the best practice (presentation) to develop data
> entry
> applications using J2EE, is struts appropriate, or would you suggest
> applets, ... ? or a mix, lets say applets for data entry and struts
> based JSP for read only views ?
> * does anyone have hands-on experience with data entry kinda applications
> built on struts ?
> * metrics available ? time to develop ? compared to applets ?
> * pitfalls ? tips ?
>
> thanks,
>
> Kris
