RE: Action an overkill ??
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
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
Re: Action an overkill ??
Ted, Early optimization is the root of all evil. I like that! A manager told me that maintenance bills for old systems were hugely inflated because of bloated optimisation logic that saved a little bit of hardware cost for a few years. Mind you plenty of systems have been written that won't perform on any network/hardware - you have to volume test optimise critical systems. Also I'd rather maintain a system that has logic in java than in javascript that's tangled up with html! Keith. --- Ted Husted [EMAIL PROTECTED] wrote: 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
Re: Action an overkill ??
Martin Fowler tells a good story about the Chrysler payroll system. After spending some time noodling what was probably needed fixing, Kent Beck broke out a profiler. Turned out the real problem was creating empty date ranges. (It takes awhile to create nothing.) They created a constant for the empty date range, and adjusted a single factory method to return that instead of creating a new empty date each time. Performance instantly doubled. Similar interations with the profiler resulted in gains of several magnitudes. The changes that needed to be made were rarely anything that the developers expected. Most of us realize that applications, like most anything else, spend at least 80% of their time doing 20% of the task. Which means that in any optimization, it's important to first determine that what you are doing is in the zone where the application spends most of its time. Otherwise whatever you do gets lost in the rounding. Fowler's advice is to start with the premise that the best optimization is a good design, which is often also the easiest code for the compiler to optimize. And then see if you a problem that needs fixing. The real benefit is that if you have a solid design, worthwhile optimizations are easier to make. Given the empty date example, since it used a factory method, they only had to make the change once, and the entire applicaton benefitted. Keith Bacon wrote: Ted, Early optimization is the root of all evil. I like that! A manager told me that maintenance bills for old systems were hugely inflated because of bloated optimisation logic that saved a little bit of hardware cost for a few years. Mind you plenty of systems have been written that won't perform on any network/hardware - you have to volume test optimise critical systems. Also I'd rather maintain a system that has logic in java than in javascript that's tangled up with html! Keith. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Action an overkill ??
i was a little confused about your original post on this subject, but then your followup seemed to confuse me more. your original post on this subject seems to imply there is an additional layer, distinct from the Action, where business logic should reside. then, your follow up seems to confirm that the business logic should reside in the Action. my original impression about the struts paradigm (being new to it), was that all business logic was coded into the Action. the logic would then make calls to Session, Entity, and Java Beans which would encapsulate the complexities of specific aspects of the business logic. as an approach, this seems to make the most sense, compared to trying to put _all_ of the business logic in some place other than an Action and have the Action call it. what would you say? thanks --e-- On Fri, 07 Dec 2001 05:30:52 -0500, Ted Husted wrote: Which makes the answer, implement it in the Action first, where it is easy to do, but more because it *is* business logic, . . . 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. argo_tec gmbh ed.q.bridges tel. 089-368179.552 fax 089-368179.79 osterwaldstraße 10 (haus F eingang 21) 80805 münchen /argo_tec gmbh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Action an overkill ??
The Action would call the business logic, as opposed to the view. The actual code resides in the business layer, but there would be a method call in the Action. People have been known to code the actual business logic into an Action, but have usually lived to regret it. If data were stored in a HTTP Session, the Action would retrieve the data and pass the salient facts to the business layer. It is strongly recommended that all business logic reside in classes outside the Action, so that they can be used in other environment, and properly tested with tools like JUnit. So, in a Struts application, the Action would call the business methods, but not implement them. Generally, this is not any more work, since by the time you put the business logic into an Action, the method is overly long. To break it up, you really need to insert helper methods. Since Actions are multithreaded, you need to pass everything on the stack. And if you are passing it on the stack, it's just as easy to pass it to another class. Edward Q. Bridges wrote: i was a little confused about your original post on this subject, but then your followup seemed to confuse me more. your original post on this subject seems to imply there is an additional layer, distinct from the Action, where business logic should reside. then, your follow up seems to confirm that the business logic should reside in the Action. my original impression about the struts paradigm (being new to it), was that all business logic was coded into the Action. the logic would then make calls to Session, Entity, and Java Beans which would encapsulate the complexities of specific aspects of the business logic. as an approach, this seems to make the most sense, compared to trying to put _all_ of the business logic in some place other than an Action and have the Action call it. what would you say? thanks --e-- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Action an overkill ??
We've followed the Session Facade design pattern, where the action classes handle the interaction between the GUI and our core business logic; somewhat of a sub-controller for the given GUIs to control how we get/put/update/calc data between our Session Beans and our Forms. In addition, the Action classes manage application errors and system exceptions and how these errors should be forwarded to the user. We try to keep most, if not all our business logic in our Session Beans, so business logic can be client independent (not tied to Struts, http, servlets or the like) and sharable across multiple action classes. Needless to say, we attempt to keep our Action classes as thin as possible, delegating business logic/processing to our Session Beans. In addition, we try to keep our client code (GUIs) as thin as possible as well. If a sorting algorithm is needed to present data in a certain way, we provide helper methods that can be called by our Action classes to get data in different ways... this way, these operations are sharable... So far, this pattern has worked extremely well for us and allows us to partition our application so our business logic is client independent and is manageable. In terms of overkill, well some may see this as an extra layer, however the benefits derived from partitioning these set of processes (sub-controlling interactions between GUI and core business logic) outweigh any concerns regarding extra layers in terms of overall application maintenance and reusability. If you are not using EJBs, you still may want to put core business logic in separate business operation classes, that are not tied to the client (Struts, http, servlets) I guess it would depend on how large your application is... Just my .02 -Original Message- From: Edward Q. Bridges [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 6:24 AM To: Struts Users Mailing List; Ted Husted Subject: Re: Action an overkill ?? i was a little confused about your original post on this subject, but then your followup seemed to confuse me more. your original post on this subject seems to imply there is an additional layer, distinct from the Action, where business logic should reside. then, your follow up seems to confirm that the business logic should reside in the Action. my original impression about the struts paradigm (being new to it), was that all business logic was coded into the Action. the logic would then make calls to Session, Entity, and Java Beans which would encapsulate the complexities of specific aspects of the business logic. as an approach, this seems to make the most sense, compared to trying to put _all_ of the business logic in some place other than an Action and have the Action call it. what would you say? thanks --e-- On Fri, 07 Dec 2001 05:30:52 -0500, Ted Husted wrote: Which makes the answer, implement it in the Action first, where it is easy to do, but more because it *is* business logic, . . . 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. argo_tec gmbh ed.q.bridges tel. 089-368179.552 fax 089-368179.79 osterwaldstraße 10 (haus F eingang 21) 80805 münchen /argo_tec gmbh -- 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]
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
RE: Action an overkill ??
there's a big difference between an application that is based for use over a network by multiple users and an application that runs entirely locally. in the regard you describe, there is every reason to do that on the client, particularly since all the data exists on the client to begin with. but, what would the application performance be like to use if it was a 15mb spreadsheet that was being accessed over a network? one designs one's applications according to their needs, and the needs of the environment the app is being used in. there is no blanket approach that covers these two extremes of app development. however, given the context within which we're discussing app development (network based applications) it's quite conventional to begin with the assumption that keeping business logic on the server is better than moving it to the client. --e-- On Fri, 7 Dec 2001 08:29:26 -0600, Robert J. Sanford, Jr. wrote: 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
RE: Action an overkill ??
there's a big difference between an application that is based for use over a network by multiple users and an application that runs entirely locally. in the regard you describe, there is every reason to do that on the client, particularly since all the data exists on the client to begin with. but, what would the application performance be like to use if it was a 15mb spreadsheet that was being accessed over a network? that depends on the design of the spreadsheet and the underlying operating system. if both were designed with intelligent caching then the only time the network effect would be noticeable would be when new data was needed from disk. in discussing sorting data on the client side the same is true - if i already have the data, why should i go get it again? one designs one's applications according to their needs, and the needs of the environment the app is being used in. there is no blanket approach that covers these two extremes of app development. i agree with you 100%. however, given the context within which we're discussing app development (network based applications) it's quite conventional to begin with the assumption that keeping business logic on the server is better than moving it to the client. i agree with that but i think we might have some friendly disagreement as to what constitutes business logic and what doesn't. the original topic of this thread was sorting and the concern that hitting an action bean and/or jsp was too heavy. my personal opinion is that if a client is allowed to sort data then there is a high liklihood that sorting is a function of presentation rather than business logic. rjsjr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Action an overkill ??
Robert J. Sanford, Jr. wrote: i agree with that but i think we might have some friendly disagreement as to what constitutes business logic and what doesn't. the original topic of this thread was sorting and the concern that hitting an action bean and/or jsp was too heavy. my personal opinion is that if a client is allowed to sort data then there is a high liklihood that sorting is a function of presentation rather than business logic. I'd say that displaying the rows in alternating colors is a function of the presentation. But what order the rows are given is business logic, and should be part of the business API. Ordering rows one way or another is something that your application does -- it reports by the last name, or invoice date, et cetera. And these are things that should be expressed in the queries and maybe optimized by the DBA. The real test case is this: OK, we're not using browsers any more. Users an can now request a report as a PDF as an email attachment in any supported order. Now how does the data get ordered? -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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
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
RE: Action an overkill ??
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
RE: Action an overkill ??
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
RE: Action an overkill ??
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] -- 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
Action an overkill ??
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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Action an overkill ??
Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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] -- 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]
RE: Action an overkill ??
Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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] -- 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]
Re: Action an overkill ??
IMHO the DB should never be accessed by anything in the JSP itself, Tag or otherwise. I believe that one of the purposes of having actions is to enable delegation of things like DB access to specialised layers which can then be pluggable. Also, using actions allows processing to be wrapped around the request for the pages as well as decoupling requests for pages and the actual location of these pages on the server. HTH ;-) - Original Message - From: Abhishek Srivastava [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, December 05, 2001 10:53 AM Subject: RE: Action an overkill ?? Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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] -- 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]
RE: Action an overkill ??
You're welcome... Documents... - The archtectural papers for Struts (and other web-frameworks) - Ted's Catalog - the javaworld-article (have no url ready...) on Model 2 - Jason Hunters ranting against JSP - common sense (at least for a huge number of web-application programmers) all dictate never to mix JSP with business-logic. I think it boils down to: Do I want to have a separation of concerns as mandated by OO-style and the MVC-pattern, or do I want to have the least possible number of components? Following the MVC-style (one of the Struts-goodies) mandates the use of action and a restricted use of business-logic-custom tags. hope this helps Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 11:53 AM To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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] -- 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]
RE: Action an overkill ??
Ted's Catalog was useful in this regard as it clearly say no linking to jsps so no more sorting a table by jsp as it leads to a jsp making a hyperlink to itself rather than an action. Wish I could find something on the access of Ejbs via jsp-tags vs. Actions also. The feeling here is that use of Tag libraries is not mixing jsp code with business logic. instead it is regarded as a way or creating reusable code across jsp pages without mixing java with jsp code. which also appears to be true for Actions. The only issue seems to be which one should be used as a standard. Thanks a lot for your reply and help. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:47 PM To: struts-user Subject: RE: Action an overkill ?? You're welcome... Documents... - The archtectural papers for Struts (and other web-frameworks) - Ted's Catalog - the javaworld-article (have no url ready...) on Model 2 - Jason Hunters ranting against JSP - common sense (at least for a huge number of web-application programmers) all dictate never to mix JSP with business-logic. I think it boils down to: Do I want to have a separation of concerns as mandated by OO-style and the MVC-pattern, or do I want to have the least possible number of components? Following the MVC-style (one of the Struts-goodies) mandates the use of action and a restricted use of business-logic-custom tags. hope this helps Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 11:53 AM To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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
RE: Action an overkill ??
In respect to ejb-access there have been thread's around in this mailing-list (search for ejb in the archive). And there is no difference between database-tables, corba-services and ejb's: they all belong to the applications backend. Therefor isolating them from the presentations layer is good style. You can also use the catalog again (no jsp-links): If a jsp just uses a few ejb's then it is very probable to link to itself... I usually try to convince programmers to isolate the ejb's in their own server (use a pure application server) and have the presentation layer also in its own server (a pure servlet-engine). Normally that's when they accept, that ejb's are a backend-thing. hope this helps Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 1:00 PM To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Ted's Catalog was useful in this regard as it clearly say no linking to jsps so no more sorting a table by jsp as it leads to a jsp making a hyperlink to itself rather than an action. Wish I could find something on the access of Ejbs via jsp-tags vs. Actions also. The feeling here is that use of Tag libraries is not mixing jsp code with business logic. instead it is regarded as a way or creating reusable code across jsp pages without mixing java with jsp code. which also appears to be true for Actions. The only issue seems to be which one should be used as a standard. Thanks a lot for your reply and help. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:47 PM To: struts-user Subject: RE: Action an overkill ?? You're welcome... Documents... - The archtectural papers for Struts (and other web-frameworks) - Ted's Catalog - the javaworld-article (have no url ready...) on Model 2 - Jason Hunters ranting against JSP - common sense (at least for a huge number of web-application programmers) all dictate never to mix JSP with business-logic. I think it boils down to: Do I want to have a separation of concerns as mandated by OO-style and the MVC-pattern, or do I want to have the least possible number of components? Following the MVC-style (one of the Struts-goodies) mandates the use of action and a restricted use of business-logic-custom tags. hope this helps Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 11:53 AM To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) 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] -- 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]
RE: Action an overkill ??
Hi Abhishek, As you have suggested, you can access your EJB via a Taglib or an Action. Both are valid options. You should however access the EJB via a Business Delegate, ie a standard JavaBean that hides the EJB lookup. The Business Delegate can then be use by an Action or a TagLib. A rule of thumb might be to use a TagLib if you need to check/validate/fetch data on multiple pages and an action to fetch/process data for another page. Jon Ridgway -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: 05 December 2001 12:00 To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Ted's Catalog was useful in this regard as it clearly say no linking to jsps so no more sorting a table by jsp as it leads to a jsp making a hyperlink to itself rather than an action. Wish I could find something on the access of Ejbs via jsp-tags vs. Actions also. The feeling here is that use of Tag libraries is not mixing jsp code with business logic. instead it is regarded as a way or creating reusable code across jsp pages without mixing java with jsp code. which also appears to be true for Actions. The only issue seems to be which one should be used as a standard. Thanks a lot for your reply and help. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:47 PM To: struts-user Subject: RE: Action an overkill ?? You're welcome... Documents... - The archtectural papers for Struts (and other web-frameworks) - Ted's Catalog - the javaworld-article (have no url ready...) on Model 2 - Jason Hunters ranting against JSP - common sense (at least for a huge number of web-application programmers) all dictate never to mix JSP with business-logic. I think it boils down to: Do I want to have a separation of concerns as mandated by OO-style and the MVC-pattern, or do I want to have the least possible number of components? Following the MVC-style (one of the Struts-goodies) mandates the use of action and a restricted use of business-logic-custom tags. hope this helps Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 11:53 AM To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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
RE: Action an overkill ??
Hi Abhishek, My previous answer was a bit vague as it depends on the specific context. If for example you whished to check that the users details had been fetched before accessing a page then a taglib that uses a business delegate to access an ejb would be a good choice. If however you wanted to process the user's details, an action would be a better choice (indeed form submits should clearly be handled by an action). Some choices are not so clear cut. Sorting a table for instance could be handled by a taglib or a repost to an action that sorts and forwards back to the jsp. I guess I would favor the taglib option here, as I might (heaven forbid) use a framework other than struts in the future. Jon Ridgway -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: 05 December 2001 10:53 To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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] -- 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]
RE: Action an overkill ??
Hello, two comments/questions: - in my opinion, sorting data is somehow business processing. Suppose that you have a long list of results that is paged (ie. retrieved in chunks from the data store). Sorting the data using a different criteria may involve re-accessing the data store to retrieve a different page of data.. and this should not be handled by a JSP. All this to say that I personally see the sorting/resorting in the Action/Model layers. - I've seen a few messages related to using a business delegate to call an EJB. Isn't an EJB a Business Delegate itself? In my case, the EJBs are relatively simple for now, only things like UserEJB.create(UserValueObject) and similar. And I'm calling them directly from my Actions (using a ServiceLocator). I'm not sure I see the advantage of using both a Business Delegate and an EJB... aren't EJBs better in the sense that the app server supports/provides many more services (transactions, object pooling, security, ...)? Thanks. Andrej -Original Message- From: Jon.Ridgway [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:14 AM To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Hi Abhishek, My previous answer was a bit vague as it depends on the specific context. If for example you whished to check that the users details had been fetched before accessing a page then a taglib that uses a business delegate to access an ejb would be a good choice. If however you wanted to process the user's details, an action would be a better choice (indeed form submits should clearly be handled by an action). Some choices are not so clear cut. Sorting a table for instance could be handled by a taglib or a repost to an action that sorts and forwards back to the jsp. I guess I would favor the taglib option here, as I might (heaven forbid) use a framework other than struts in the future. Jon Ridgway -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: 05 December 2001 10:53 To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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
Re: Action an overkill ??
Jon.Ridgway wrote: Some choices are not so clear cut. Sorting a table for instance could be handled by a taglib or a repost to an action that sorts and forwards back to the jsp. I guess I would favor the taglib option here, as I might (heaven forbid) use a framework other than struts in the future. Why not have the delegate do the sorting, as you might (heaven forbid) use something other that taglibs in the future? ;-) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Action an overkill ??
Hi Ted, Yes, very good point. It would indeed be the best place to sort Jon. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: 05 December 2001 15:36 To: Struts Users Mailing List Subject: Re: Action an overkill ?? Jon.Ridgway wrote: Some choices are not so clear cut. Sorting a table for instance could be handled by a taglib or a repost to an action that sorts and forwards back to the jsp. I guess I would favor the taglib option here, as I might (heaven forbid) use a framework other than struts in the future. Why not have the delegate do the sorting, as you might (heaven forbid) use something other that taglibs in the future? ;-) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- 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]
RE: Action an overkill ??
Hi Andrej, Point one below, you a right. I don't think the suggestion is to sort in the JSP, Taglib or Action. The sorting should be delegated via a taglib or jsp to a business class. Point two, the Business Delegate pattern suggests that you should use a simple JavaBean to access all services, such as EJBs, WebServices, COBRA Services etc. This way you can hide the tricky bits of creating the service away from your clients (ie TagLib or Action class). You can also change the type of the service from say an EJB to a WebService without impacting your clients. Jon. -Original Message- From: Sobkowski, Andrej [mailto:[EMAIL PROTECTED]] Sent: 05 December 2001 15:27 To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Hello, two comments/questions: - in my opinion, sorting data is somehow business processing. Suppose that you have a long list of results that is paged (ie. retrieved in chunks from the data store). Sorting the data using a different criteria may involve re-accessing the data store to retrieve a different page of data.. and this should not be handled by a JSP. All this to say that I personally see the sorting/resorting in the Action/Model layers. - I've seen a few messages related to using a business delegate to call an EJB. Isn't an EJB a Business Delegate itself? In my case, the EJBs are relatively simple for now, only things like UserEJB.create(UserValueObject) and similar. And I'm calling them directly from my Actions (using a ServiceLocator). I'm not sure I see the advantage of using both a Business Delegate and an EJB... aren't EJBs better in the sense that the app server supports/provides many more services (transactions, object pooling, security, ...)? Thanks. Andrej -Original Message- From: Jon.Ridgway [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:14 AM To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Hi Abhishek, My previous answer was a bit vague as it depends on the specific context. If for example you whished to check that the users details had been fetched before accessing a page then a taglib that uses a business delegate to access an ejb would be a good choice. If however you wanted to process the user's details, an action would be a better choice (indeed form submits should clearly be handled by an action). Some choices are not so clear cut. Sorting a table for instance could be handled by a taglib or a repost to an action that sorts and forwards back to the jsp. I guess I would favor the taglib option here, as I might (heaven forbid) use a framework other than struts in the future. Jon Ridgway -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: 05 December 2001 10:53 To: 'Struts Users Mailing List' Subject: RE: Action an overkill ?? Thanks for your reply, There is a debate in my team these days on the use of Jsp Tags versus Actions. Some jsp developers feel that ejbs should be accessed via tag libraries, databases should be accessed via tag libraries and for simple rendering things like sorting a table jsp tag libraries should be used. While others like to use Actions for all the things mentioned above. Is there a document somewhere which describes what tasks are better suited for actions and what tasks are better suited for tag libraries. Technically, things mentioned above can be done easily by either as action or as jsp tags.But I want to make a consistent decision through out the application. 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] -Original Message- From: Alexander Jesse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 4:05 PM To: struts-user Subject: RE: Action an overkill ?? Hi, going through the action hides the presentation-implementation from the user's eyes. For example, the user will only see .../do/showTable (or .../showTable.do) in the browser's address line and therefor not be able to bookmark the jsp-file, when you use an action. The action also allows you to change more implementation details without having to change the presentation (JSP-file)... I advocate strict use of actions in every case... = NEVER use a jsp-link, ALWAYS use an action just my two cents... Alexander Jesse -Original Message- From: Abhishek Srivastava [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:54 AM To: Struts-User (E-mail) Subject: Action an overkill ?? 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
