You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Kris Vandenberk <Kr...@skynet.be> on 2001/06/13 21:37:44 UTC
General Struts & J2EE question
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
Re: General Struts & J2EE question
Posted by Ted Husted <hu...@apache.org>.
The actual validation is accomplished via an ActionForm subclass. For
client-side validation, there are custom tags to generate the
JavaScript. The only part the servlet plays is to digest (parse) the XML
file that defines the validations into a resource the subclass and
custom tags can use.
Because we don't have an alternate loading mechanism yet, the only way
to get really cool additional services into the application is through
servlets. But in this case, it's just a bootstrap servlet. Once the XML
is digested, the servlet component is not used again.
Jonathan Asbell wrote:
>
> Ah. So you are saying its just a plain class(not a servlet). Or rather,
> its not being triggered by urls, but rather by direct calls from other
> classes. Or is it a servlet that is not being triggered by urls. I am just
> getting confused because it is the umteenth time I have seen these pluggable
> "extensions" referred to as servlets.
Re: General Struts & J2EE question
Posted by Jonathan Asbell <ja...@i-2000.com>.
Ah. So you are saying its just a plain class(not a servlet). Or rather,
its not being triggered by urls, but rather by direct calls from other
classes. Or is it a servlet that is not being triggered by urls. I am just
getting confused because it is the umteenth time I have seen these pluggable
"extensions" referred to as servlets.
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 13, 2001 10:26 PM
Subject: Re: General Struts & J2EE question
> Sorry, the servlet part is really a misnomer, and is only used to load
> the validation mappings.
>
> The requests are all still handled by the ActionServlet. The server-side
> validation happens within a subclass of ActionForm. The client-side
> validation is generated by a custom tag. It snaps into the existing
> flow, and nothing bounces around.
>
> Jonathan Asbell wrote:
> >
> > Ted, One thing I am not understanding is why we are bouncing requests
all
> > over using various servlets, as in the case of validation. What are the
> > consequences and or benefits of one servlet triggereing another etc. It
> > seems as though this can create confusion because you dont know what is
> > happening. That is, you could end up being bounced all over the place
from
> > servlet to servlet beforwe coming to a rest, and you may or may not know
> > what exactlly transpired.
> >
> > Jonathan
> >
> > ----- Original Message -----
> > From: "Ted Husted" <hu...@apache.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Wednesday, June 13, 2001 5:39 PM
> > Subject: Re: General Struts & J2EE question
> >
> > > 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
> > >
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
Re: General Struts & J2EE question
Posted by Ted Husted <hu...@apache.org>.
Sorry, the servlet part is really a misnomer, and is only used to load
the validation mappings.
The requests are all still handled by the ActionServlet. The server-side
validation happens within a subclass of ActionForm. The client-side
validation is generated by a custom tag. It snaps into the existing
flow, and nothing bounces around.
Jonathan Asbell wrote:
>
> Ted, One thing I am not understanding is why we are bouncing requests all
> over using various servlets, as in the case of validation. What are the
> consequences and or benefits of one servlet triggereing another etc. It
> seems as though this can create confusion because you dont know what is
> happening. That is, you could end up being bounced all over the place from
> servlet to servlet beforwe coming to a rest, and you may or may not know
> what exactlly transpired.
>
> Jonathan
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, June 13, 2001 5:39 PM
> Subject: Re: General Struts & J2EE question
>
> > 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
> >
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: General Struts & J2EE question
Posted by Jonathan Asbell <ja...@i-2000.com>.
Ted, One thing I am not understanding is why we are bouncing requests all
over using various servlets, as in the case of validation. What are the
consequences and or benefits of one servlet triggereing another etc. It
seems as though this can create confusion because you dont know what is
happening. That is, you could end up being bounced all over the place from
servlet to servlet beforwe coming to a rest, and you may or may not know
what exactlly transpired.
Jonathan
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 13, 2001 5:39 PM
Subject: Re: General Struts & J2EE question
> 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
>
Re: General Struts & J2EE question
Posted by Ted Husted <hu...@apache.org>.
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