One possibility you could use to separate the code responsibility might be to collect your data into objects and dump those objects directly into the view as JSON, or even fetch the data AJAX style using a separate action/view. Since your chart renders are different from page to page and are being handled by javascript already, you could just dump the data straight into javascript space at the outset and handle the different chart views completely in javascript instead of in the action or the view.
I don't know if this is the best way, necessarily, but I've often found that when I need lots of javascript access to application data, it helps to just get that data into JSON as soon as possible so all the cards are on the table and I'm free to add new javascript functionality without much (or any) change to the java side of the picture. - Aaron On Tue, Aug 9, 2011 at 12:36 PM, Jeff Black <jeffrey.bl...@yahoo.com> wrote: > Hey Chris -- Can you utilize an interceptor(s) for any of your biz-logic? > > jb > / > > From: "CRANFORD, CHRIS" <chris.cranf...@setech.com> > To: user@struts.apache.org > Sent: Tuesday, August 9, 2011 8:51 AM > Subject: Where's ideal for this logic? > > > I have several actions that instantiate a business service to query KPI > statistics from our database. The KPI statistics are gathered using > projection-based Hibernate queries on several domain entity objects. > We are representing the KPIs in the view using a jQuery-based chart > library. > > Does it make sense to constrain the business service layer to simply > retrieving the summary data information and leave the action class to > inspecting the summary data and generating the chart DTO objects used in > the JSP for rendering needs or would others have specialized methods in > the business service to create the chart DTO objects too really keeping > the action lean? > > There are ways to minimize code bloat regardless of where I place the > logic, but I'm looking for the most ideal place. Since each graphs > render is unique and specific to the report parameters and > configurations of that specific report, one action may simple generate a > single bar chart where the next may generate a bar chart with a spline > overlay and an additional pie chart all in a single view. > > Lastly, has anyone else looked at the library from Highcharts and have > any input, thoughts, or suggestions on your past use? > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org -- Aaron Brown : aa...@thebrownproject.com --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
