I would be interested to hear an example of such an app where the use of
HTML forms is a good decision over some sort of cutom control or
spreadsheet control, grid control, or desktop tool that is web-enabled (in
this case). I have had no experience where such a thing was necessary. And
I would never think to build a spreadsheet out of web-page. Why not just
build a web page out of a spreadsheet?
Perhaps Pete can provide more details to the original issue and we can see
if HTML is really even the best way.
I hear what you are saying, Martin......just never seen such a
thing.........(at least not that anyone would actually use.)
- Cody
Martin Farrell <[EMAIL PROTECTED]> on 02/06/2002 09:33:29 AM
Please respond to Struts Users Mailing List
<[EMAIL PROTECTED]>
To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
cc:
Subject: RE: speed of struts
hi
i think it depends on the type of application - if it is similar
information
then you could have a 10*5 array (some form of corporate time sheet maybe)
-
to help the user submit the information faster. rather than having 5 * 10
forms with the inevitable network delays that would give the user dialing
up
from home
your essentially moving from a form filing metaphor to a spreadsheet
metaphor idea.
martin
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: 06 February 2002 15:32
To: Struts Users Mailing List
Subject: RE: speed of struts
Good point. Under no circumstances whatsoever should the user be expected
to do data entry for 50 items on a single web page unless they items all
happen to be simple checkboxes. This is a known principal in
user-experience architecture and Web site usability. If you need some lab
data or something that backs this up, I can probably find something if I
dig around.
Data entry is a cumbersome process. Users must be incented through the
process by parsing the process itself into manageable chunks and giving
users motivation throughout.
Consider a "wizard"-based data entry metaphor to correct this issue.
Also, make sure that you give appropriate feedback to the user after each
wizard step.
Consider also adding a motivator and possibly even a "step-map" that shows
location in the overall data entry process.
If you really want to be aggresive, consider also allowing automatic save
of the current state so that the user can always pick up where they left
off on new sessions.
- Cody
"Galbreath, Mark" <[EMAIL PROTECTED]> on 02/06/2002 07:14:57 AM
Please respond to Struts Users Mailing List
<[EMAIL PROTECTED]>
To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
cc:
Subject: RE: speed of struts
50 fields in a form??? Me thinks the bug is in the design.
Cheers!
Mark
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 6:02 AM
To: [EMAIL PROTECTED]
Subject: RE: speed of struts
I had a form with lots of custom tags. When run under the Sun 1.3 JDK it
was
slow as molasses. Sun 1.2 JDK or IBM 1.3 was instantaneous. A few mailing
list posts pointed me to a bug in Sun's 1.3 having to do with nested
try/catch blocks in the compiled JSP.
Try your page under Sun 1.2 or the IBM JDK and see if it makes a
difference.
Lee
-----Original Message-----
From: Christopher Cheng [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 3:50 AM
To: Struts Users Mailing List
Subject: RE: speed of struts
My form does not have a lot of tag processing (acutally none) The time it
takes to load the page is proportional to the number of instances of form
objects appeared on the JSP.
For instance, outputting a radio set is A LOT slower than outputting a drop
down list since you just have to pass a collection to the "iterate", but
you
have to actually put all the <html:radio/> options on the JSP.
<html:select property="factors[4].rating">
<html:options collection="ratings" property="value" labelProperty="label"/>
</html:select>
<html:radio ...../>Option A
<html:radio ...../>Option A
<html:radio ...../>Option A
<html:radio ...../>Option A
-----Original Message-----
From: Pete Carapetyan [mailto:[EMAIL PROTECTED]]
Posted At: Wednesday, February 06, 2002 12:10 PM
Posted To: Struts
Conversation: speed of struts
Subject: Re: speed of struts
I have had the same problem on one very large form with lots of back end
tag
processing. Would be interested to know if anyone had performed any
profiling on similar situations to identify where the bottlenecks were.
Struts wrote:
> I found out that if I include a lot of html form fields in a form (over
50). The jsp pages seems to be awfully slow to load (almost 10 seconds). I
made it a little bit faster when I converted all radio button sets to drop
down list, still it is very slow. The speed to load up seems to
exponentially related to the number of form fields.
>
> Has anybody got the same problem?
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
Pete Carapetyan
http://datafundamentals.com
Java Development Services
Open standards technology for commercial profitability
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
** For great Emap magazine subscription & gift offers visit
http://www.emapmagazines.co.uk **
--------------------------------------------------------------------------------
The information in this email is intended only for the addressee(s) named
above.
Access to this email by anyone else is unauthorised.
If you are not the intended recipient of this message any disclosure,
copying,
distribution or any action taken in reliance on it is prohibited and may be
unlawful.
Emap plc and or its subsidiaries do not warrant that any attachments are
free from
viruses or other defects and accept no liability for any losses resulting
from
infected email transmissions.
Please note that any views expressed in this email may be those of the
originator
and do not necessarily reflect those of this organisation.
--------------------------------------------------------------------------------
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
