I'm interested in hearing other opinion on this. I personally find the logic present/equals tags to be ugly and cumbersome (not to mention inefficient in terms of the generated servlet) and often find myself resorting to simple if/else scriptlets instead. I'm not sure the logic tags win even from a maintainabilit point of view.
How does everyone else deal with complex display logic? Do you use the logic tags? -----Original Message----- From: Jim Downing [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 27, 2002 8:17 AM To: Struts Users Mailing List Subject: Re: speed of struts On Mon, Feb 11, 2002 at 03:01:12PM +0000, [EMAIL PROTECTED] wrote: > I'm curious as to the limit here. I'm currently building an app which > has huge form requirements - I may have upwards of 500 fields as html > text inputs -- very spreadsheet like. Where is the limitation? > Rendering into html, or parsing the request into beans? I've had not > problems so far with rendering speed, though I'm using Mozilla, so > browser speed hasn't been noticable to far.. I've just finished a struts project where I had to move to scriptlets away from struts tags for presentation logic. The problem was that every now and then the GC would take a second or so to run. This struck me as a VM issue (and may still have been, although it happened under linux jdk1.2.2 and 1.3.1), but when I profiled the page I found that the handful of tags I was using (10 - 20 logic equals, a few logic:iterates) were generating 6M of garbage. Is this typical for all taglibs? I dislike developing with scriptlets, but that's a pretty big performance hit to have to take for a bit of maintainability. Is this the same factor that limits pages to 50 form tags? What's the best solution for pages with complex presentation logic? jim Jim Downing [EMAIL PROTECTED] > -----Original Message----- > From: husted > Sent: 06 February 2002 13:50 > To: struts-user > Cc: husted > Subject: Re: speed of struts > > > This comes up fairly often, and around 50 does seem to be a cut-off > point for some reason. A number of things can affect the speed the form > renders, including the browser and, as mentioned, the JVM. > > One interesting thing would be to try the same page under VelServlet. > > http://husted.com/struts/resources/velservlet.htm > > This is a drop-in extension, and you can mix and match Velocity > templates with JSPs in the same application. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Java Web Development with Struts. > -- Tel +1 585 737-3463. > -- Web http://www.husted.com/struts/ > > > 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]> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > > -- > 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]>
