struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Bond" <>
Subject RE: Where to put non action associated data
Date Mon, 01 Aug 2011 17:36:36 GMT
Thanks for the feedback.. my first thought was to use interceptors but I
decided against this since in principle I mainly use interceptors for stuff
like setting up ThreadLocals for the request, auditing requests and for
access control etc. but not for business logic. Action chaining also entered
my mind but I have never used it.

Dave is right in that I didn't really want my actions or business services
to know about other 'plugins' so whilst the search is carried out in a
service with results returned to the action the service or the action
wouldn't know about additional ebay / google stuff. As far as I can see, I
either register these plugins with the business service and make calls to
them when necessary or I fire an event. The first of these options would
require my service to know about the possibility of plugins and to call each
of those present, the second allows anything in the system to respond to the
event. In this case I'm thinking that registering with the service may be
better - code would be more obvious, debugging easier and there's one place
to handle exceptions etc.

Despite the above, tweaking the view template chosen may not be so easy but
in reality it probably wouldn't be too much trouble to put something on the
stack as part of the action to tell the view which external results to
show.. I'll come back to that :)

Again, cheers for the ideas,

-----Original Message-----
From: Dave Newton [] 
Sent: 01 August 2011 14:39
To: Struts Users Mailing List
Subject: Re: Where to put non action associated data

Yep, a service is the canonical solution--my impression was that the OP was
trying to avoid *any* knowledge of the additional search stuff, but
composing capabilities via services sure seems like the easiest thing to do.


On Mon, Aug 1, 2011 at 9:32 AM, Aaron Brown <>
> If I were coding the search part, I'd probably place the secondary 
> piece inside a searching business service. Your action would 
> instantiate a search business service and ask it to get search results 
> based on a query string. The business service would do that and also 
> (based on whatever business logic you like) would do whatever extra 
> things were appropriate. The action never knows or cares about it, and 
> your low-level data access piece doesn't know either. It's the service 
> layer's job to understand the complexities and related activities that 
> go with the basic requests from the Action.
> My two cents.
>  - Aaron
> On Sun, Jul 31, 2011 at 12:50 PM, Marcus Bond <>
>> Hi,
>> Say I have a form where user can carry out a product search which 
>> hits an action and returns a list of results - easy.. however in 
>> response to the user changing their search criteria I want to also 
>> generate some search terms which would be passed through to Ebay, 
>> google ads etc.. but not within my action which is designed with one 
>> purpose in mind - to search my db (the action doesn't know about 
>> google ads, ebay, AWS or any other thing that comes along). Gut 
>> reaction here is to fire an event (say product changed) and have some 
>> listeners do the work of generating the relevant google / ebay stuff and
storing this in the users session.
>> Firstly, is this how most of you would go about it?
>> Secondly in terms of the view side of things, whilst normally my 
>> action would simply return 'success' I may want to tweak the view 
>> depending upon which external source returned the best results 
>> (currently I use tiles but I don't think I can or should dynamically 
>> switch the result after my action has processed).. How would you 
>> tackle this? By adding logic to the tile / template jsp or some other
>> Can any of you share experiences of using Struts in apps like this 
>> and how you tackled similar scenarios or if maybe another framework is
more suited?
>> You'll have to bear with me here since all my work thus far has had 
>> no need to collaborate data from multiple sources in one page.
>> Regards and thanks in advance,
>> Marcus
> --
> Aaron Brown :
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message