struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Pratt" <thechrispr...@gmail.com>
Subject Re: looking for suggestion regarding interceptor
Date Thu, 10 Jul 2008 18:41:48 GMT
Oh, I see.  Since we have a need to cache much of our data between
requests (rather than fetching the data from the back end systems on
every action request), we have more code that would have to be copied
to each execute method (using your scheme).  So in our case it
relieves a lot of headaches to have that code in one location.  Thanks
for the explanation.
  (*Chris*)

On Thu, Jul 10, 2008 at 11:28 AM, Gabriel Belingueres
<belingueres@gmail.com> wrote:
> Spring only inject the service. The data returned by the service is
> holded into an instance variable of the action (or I could just store
> the data in session or application scope).
>
> Spring dependencies are wired this way:
>
> Service <--- Cache  <--- DAO
>
>
> Ex:
>
> class MyAction extends ActionSupport {
>
>  private Service service; // with its setter
>  private List<Data> list; // with its setter and getter
>
>  public String execute() {
>    list = service.getData();
>    return SUCCESS;
>  }
>
> }
>
>
> 2008/7/10 Chris Pratt <thechrispratt@gmail.com>:
>> I guess I'm confused.  If Spring is injecting the data, why do you
>> need it to also inject the Service?
>>  (*Chris*)
>>
>> On Thu, Jul 10, 2008 at 10:41 AM, Gabriel Belingueres
>> <belingueres@gmail.com> wrote:
>>> IMHO both approaches are similar, as the intention is to inject the
>>> required data when you need it. The difference is that you created
>>> both an interface and an interceptor to perform the injection, while I
>>> relied on Spring to do this work.
>>>
>>> As a general rule I think on writing custom interceptors only when
>>> there is some generic pre/post processing that would need to take on a
>>> set of actions but that are not part of regular functional
>>> requirements.
>>>
>>> See between the lines:
>>>
>>> 2008/7/10 Chris Pratt <thechrispratt@gmail.com>:
>>>> But then your Service Bean/DAO has to be injected into every Action
>>>> that might need to load it
>>>
>>> Yes, in the same way you need to implement the xxxAware interface in
>>> every action that need to access the data.
>>>
>>>> and the code to check for the Data Object
>>>> and load it,
>>>
>>> Not quite; this is the job of Spring, I only declare it one time in
>>> the spring configuration xml file.
>>>
>>>>then store it to the context has to be Cut-n-Pasted
>>>
>>> Don't know what you meant here. There is not too much C&P. Just 2
>>> instance variables: one for the service, and the other for the data.
>>> Same as implementing the interface and declaring a variable to hold
>>> the data.
>>>
>>>> between each of those Actions.  Way too many chances for Cut-n-Paste
>>>> errors or incomplete fixes for my taste.  By using the Interceptor
>>>> that code is consolidated in one place and the only thing the Action
>>>> has to worry about it what it was created specifically to accomplish,
>>>> not all the other housekeeping chores.
>>>>  (*Chris*)
>>>>
>>>> On Wed, Jul 9, 2008 at 6:10 PM, Gabriel Belingueres
>>>> <belingueres@gmail.com> wrote:
>>>>> Wow it is amazing how S2 can be used.
>>>>> This is a use of interceptor I've never seen before.
>>>>>
>>>>> IMHO, I think it is too much trouble to declare an xxxAware interface
>>>>> and an xxxInterceptor to just share the same database data across
>>>>> multiple pages. I would stick to store the data in session or
>>>>> application scope. You have available the SessionAware and
>>>>> ApplicationAware interfaces that injects into an action a
>>>>> java.util.Map that usually is enough for testability.
>>>>>
>>>>> My own common solution to this problem would be to use Spring to
>>>>> inject a service bean into the action that would retrieve the category
>>>>> list from a cache (OSCache works great for me and has easy Spring
>>>>> integration.) When data is not in the cache or it times-out, it is
>>>>> read from the database.
>>>>>
>>>>> 2008/7/9 Chris Pratt <thechrispratt@gmail.com>:
>>>>>> That's usually how I start.  The one thing I usually add is an Aware
>>>>>> interface that allows me to inject the value into my Actions when
it's
>>>>>> needed.  So in your case I'd add a simple interface:
>>>>>>
>>>>>> interface CategoryListAware {
>>>>>>  void setCategoryList(List<Category> categories);
>>>>>> }
>>>>>>
>>>>>> And at the end of your interceptor I'd add:
>>>>>>
>>>>>> Object action = invocation.getAction();
>>>>>> if(action instanceof CategoryListAware) {
>>>>>>  ((CategoryListAware)action).setCategoryList(categoryList);
>>>>>> }
>>>>>>
>>>>>> That way you can add the Interceptor to your default stack and the
>>>>>> Actions that need the category list can have it injected without
>>>>>> having to have any knowledge about the Session.  (which makes the
>>>>>> system much easier to unit test).
>>>>>>
>>>>>>  (*Chris*)
>>>>>>
>>>>>> On Wed, Jul 9, 2008 at 3:28 PM, Dhiraj Thakur <desi.tek.org@gmail.com>
wrote:
>>>>>>> Hello there,
>>>>>>>
>>>>>>> There are 4 jsp page in which i want to show same category by
retrieving it
>>>>>>> from database.
>>>>>>>  What is the best way to do that? should i write a intercepter
which will
>>>>>>> retrieve Category from database and store it in session?
>>>>>>> something like this
>>>>>>>
>>>>>>>
>>>>>>>        if (session.getAttribute("category") == null) {
>>>>>>>
>>>>>>>            CategoryDAO categoryDAO = new CategoryDAO();
>>>>>>>
>>>>>>>            categoryList = categoryDAO.listCategory();
>>>>>>>
>>>>>>>            session.setAttribute(ConfigAPP.CATEGORY_KEY, categoryList);
>>>>>>>
>>>>>>>            categoryList = (List)
>>>>>>> session.getAttribute(ConfigAPP.CATEGORY_KEY);
>>>>>>>
>>>>>>>            System.out.println(categoryList.size());
>>>>>>>
>>>>>>>        } else {
>>>>>>>            categoryList = categoryList = (List)
>>>>>>> session.getAttribute(ConfigAPP.CATEGORY_KEY);
>>>>>>>        }
>>>>>>>
>>>>>>>
>>>>>>> or is there any other way to do that ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Dhiraj*
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

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


Mime
View raw message