who the heck is Bob? from reading the comments that you attribute to him i assume you mean me but my name is Robert - it even says so in my email address and my initials at the bottom of my emails don't begin with the letter 'b' either.
rjsjr > -----Original Message----- > From: Trieu, Danny [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 07, 2001 12:18 PM > 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]>
