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 <[EMAIL PROTECTED]>:
> 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
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
>>> 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
>>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
>>>>> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to