You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "CRANFORD, CHRIS" <Ch...@setech.com> on 2011/08/09 15:51:30 UTC

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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Where's ideal for this logic?

Posted by Aaron Brown <aa...@thebrownproject.com>.
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 <je...@yahoo.com> wrote:
> Hey Chris -- Can you utilize an interceptor(s) for any of your biz-logic?
>
> jb
> /
>
> From: "CRANFORD, CHRIS" <Ch...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org



-- 
Aaron Brown : aaron@thebrownproject.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Where's ideal for this logic?

Posted by Jeff Black <je...@yahoo.com>.
Hey Chris -- Can you utilize an interceptor(s) for any of your biz-logic?
 
jb
/

From: "CRANFORD, CHRIS" <Ch...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org