Just to clarify my previous post. By "user's experience" I mean how the user interacts with the application. A user can have a positive experience if the application is intuitive and responsive. But the user's experience is likely to be negative if the application is slow or hard to use. This idea can be applied to all applications [although web applications typically do not applied well to web applications].
I hope that clarifies what I was trying to say. Nathan Anderson SUM-Ware, Inc. -----Original Message----- From: Trieu, Danny [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 10:18 AM To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Hello all, I only read up to Ted email, but I think I have enough understanding to give in some though. First of all, I am not quite understand what Nathan mean by 'user's experience'. Second, I do not agree with Bob on having to treate the browser base application the same as window base application. From my experiences of doing web application for the pass 2+yrs, the applications that we built with high concerntration of JavaScript on the presentation tiers has always created more problems then its benefit. Whether it is incompairtabily issue to security issues, it is alway a pain to maintain it. As for the spreadsheet example that Bob brought up. What do you mean by going blank? is this mean every time you try to sort a column, you will have to hit the database for a different sorting orders? hmmm.... then it is realy bad design of a web app. To solve this problem, there is more then one way to improve its performance without loosing any user experience. Just to name a few: you can user Paging, implement Collection interface as your Session Facade to your scrollable result set, or multiple view for you Collection that represent all the different sorting orders. In the end I totally agree w/ Ted on his last paragraph: > The thing to watch for is predetermining that doing something on the > client will be beneficial before developing a base line for comparison. > The effort spent on maintaining this one Javascript might be better > spent on some other optimization which will have a greater overall > effect. Thanks, danny -----Original Message----- From: Nathan Anderson [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 9:42 AM To: Struts Users Mailing List Subject: RE: Action an overkill ?? I have to agree with Robert on this issue. In the application I am currently writing, we have decided to do some of the tasks that need to be more interactive with JavaScript simply because it is faster and smoother to do it in the client then make another server call. It boils down to improving the user's experience. If you can do something in JavaScript that will greatly improve the user's experience without degrading the quality of your application [i.e. don't rely on JavaScript to validate your data], why not do it? An added benefit is you will have fewer requests to your server, less required bandwidth, etc. Nathan Anderson SUM-Ware, Inc. -----Original Message----- From: Robert J. Sanford, Jr. [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 6:29 AM To: Struts Users Mailing List Subject: RE: Action an overkill ?? think about using an application, a spreadsheet for example, within your favorite windowing system (beos, macos, x, win32, etc.). if you want to sort the data in your favorite spreadsheet and you see the entire screen go blank, wait just a second and then have the data pop up or do you want to have the spreadsheet just sort the data in place? doing something on the client isn't always about performance but about usability and given the number of advances that we have made in the abilities of browsers we shouldn't treat the users of browser based applications any differently than we do standard applications if we can possibly avoid doing so. rjsjr > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 07, 2001 4:31 AM > To: Struts Users Mailing List > Subject: Re: Action an overkill ?? > > > Which makes the answer, implement it in the Action first, where it is > easy to do, but more because it *is* business logic, and then consider > moving it to the client *if* that helps performance. > > The thing to watch for is predetermining that doing something on the > client will be beneficial before developing a base line for comparison. > The effort spent on maintaining this one Javascript might be better > spent on some other optimization which will have a greater overall > effect. > > "Early optimization is the root of all evil." > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel +1 716 737-3463 > -- http://www.husted.com/struts/ > > Keith Bacon wrote: > > > > Edward, > > Bravo! The fewer facilities you use on the client the > > fewer problems you'll have. > > But for systems with huge numbers of users the more > > work you can off-load to the client the lower your > > server workload, so it's always going to be trade-off. > > Keith. > > > > --- "Edward Q. Bridges" <[EMAIL PROTECTED]> wrote: > > > > > > what if the client doesn't support javascript? > > > > > > what if the ordering is significant, and the client > > > has javascript turned > > > off? > > > > > > basically, it's a design question that gets answered > > > during that phase of > > > development. having it done in the business layer > > > ensures that it's always > > > done and done in the same way, without having to > > > know anything about the > > > client; also, the sorting is done once (probably) > > > by a database (which are > > > designed for, among other things, sorting data). > > > > > > of course, there are occasions that call for sorting > > > on the client, and when > > > that makes a lot of sense. but, typically having X > > > clients do their own > > > (potentially cpu intensive) sorting is overkill > > > compared to one server that > > > has been optimized for sorting doing the sorting for > > > everyone. > > > > > > > > > > > > On Thu, 6 Dec 2001 14:10:41 -0600, Robert J. > > > Sanford, Jr. wrote: > > > > > > >pardon my naivete... > > > > > > > >but couldn't the presentation of the table be a > > > JavaScript based > > > >table with buttons (or whatever) on the column > > > headers that handles > > > >the data sorting on the client side? > > > > > > > >that would allow you to dump the data down to the > > > client in whatever > > > >initial order is deemed appropriate by the business > > > logic and allow > > > >the client to perform their sorting as they desire > > > without having to > > > >go back to the server at all. > > > > > > > >rjsjr > > > > > > > >> -----Original Message----- > > > >> From: Ted Husted [mailto:[EMAIL PROTECTED]] > > > >> Sent: Wednesday, December 05, 2001 8:05 AM > > > >> To: Struts Users Mailing List > > > >> Subject: Re: Action an overkill ?? > > > >> > > > >> > > > >> It's my personal opinion that presentation pages > > > should be as dumb as > > > >> possible. It should not have to "think" about the > > > data, just render it > > > >> as it has been given. > > > >> > > > >> Conversely, the business layer should be as smart > > > as possible, and > > > >> provide whatever alternatives the rest of the > > > application needs to do it > > > >> job. If the dataset needs to be ordered in a > > > certain way, then it is up > > > >> to the business layer to provide that ordering. > > > >> > > > >> It wouldn't know how to write a HTML table, but > > > it should now how to get > > > >> the dataset ordered in the way the HTML table > > > wants it. Ordering data is > > > >> business logic, shoving in the <td>'s is the > > > presentation's job. > > > >> > > > >> The critical question, I think, is to ask -- "OK, > > > what if we wanted to > > > >> do this with something other that a JSP. Say a > > > printed report or another > > > >> templating system, like Velocity? Do we have > > > everything we need on the > > > >> business tier to make this work?" > > > >> > > > >> If business logic, like the alternative ways data > > > is ordered, is > > > >> expressed in the tag extensions, then it is not > > > available to another > > > >> presentation system. Like say, a report rendered > > > as a PDF. > > > >> > > > >> So, IMHO, ordering is not something the Action > > > does, or something a tag > > > >> extension does, is something the business layer > > > does. The Action may > > > >> select which ordering has been requested by the > > > client, but when the > > > >> data comes back, it just passes it along. > > > Ordering data is business > > > >> logic, and custom code that does that should not > > > be in any framework > > > >> component, including the tag extensions. > > > >> > > > >> It may be that you need another set of beans > > > between the EJBs and the > > > >> rest of your application. Many times EJBs end up > > > representing the > > > >> resource layer, and only partially represent the > > > business layer. So the > > > >> solution here may be a JavaBean wrapper that did > > > the sorting, so all the > > > >> presentation page need do is call an iterator. > > > Which ordering to use > > > >> would be a property on this (business layer) > > > JavaBean, that the Action > > > >> might set to the way to the page. And submitting > > > a request for a > > > >> different order would probably go back to the > > > same Action (since it > > > >> already knows how to select an order). > > > >> > > > >> If the data is being cached in the session, then > > > it would be the > > > >> Action's job to get it back, and maybe call a > > > method to change to the > > > >> default sort order. But the ordering would take > > > place on the business > > > >> layer, the Action would just known enough to call > > > the right method. > > > >> > > > >> If the data need be presented to another device, > > > like a PDF renderer, > > > >> the same JavaBean could be passed to that > > > component. This provides > > > >> resuse not only between JavaServer Pages, but > > > between all presentation > > > >> components. > > > >> > > > >> In the end, pretty much the same code is going to > > > get written either > > > >> way. The question is whether it can get more > > > reuse in a tag extension or > > > >> in the JavaBean that the tag exposes. > > > >> > > > >> HTH, Ted. > > > >> > > > >> -- Ted Husted, Husted dot Com, Fairport NY USA. > > > >> -- Custom Software ~ Technical Services. > > > >> -- Tel +1 716 737-3463 > > > >> -- http://www.husted.com/struts/ > > > >> > > > >> > > > >> Abhishek Srivastava wrote: > > > >> > > > > >> > Hello All, > > > >> > > > > >> > I render a table through my jsp page. The user > > > can sort the table by > > > >> > clicking on each of the column headers. When > > > the user clicks on > > > >> the column > > > >> > header, an Action is invoked and the data that > > > is used to > > > >> render the table > > > >> > is sorted accordingly and placed back into the > > > session. Now the > > > >> control is > > > >> > forwarded to the jsp that renders the table > > > with sorted data/ > > > >> > > > > >> > I have got some feedback that using Action for > > > things like > > > >> sorting a table > > > >> > is an overkill. what is suggested that each > > > table column should > > > >> point to a > > > >> > jsp which should use a custom tag library to > > > sort the table. > > > >> > > > > >> > I am unable to decide which approach to take > > > and why. > > > >> > > > > >> > Can someone help me on this. > > > >> > > > > >> > regards, > > > >> > Abhishek. > > > >> > > > > >> > A ship in harbor is safe, but that is not what > > > ships are built for. > > > >> > John A. Shedd > > > >> > > > > >> > ***** ***** Abhishek Srivastava > > > >> > *** /_ __ *** Hewlett-Packard - > > > Solutions Organization > > > >> > ** / / /_/ ** 19 Cunningham Road. > > > Bangalore -560052. > > > >> > *** / *** phone +91 80 2251554 > > > Extn:1532 > > > >> > ***** ***** > > > mailto:[EMAIL PROTECTED] > > > > > === message truncated === > > > > __________________________________________________ > > Do You Yahoo!? > > Send your FREE holiday greetings online! > > http://greetings.yahoo.com > > > > -- > > 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]> -- 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]>
