You certainly can do this sort of approach; I have a couple of instances where it was useful to create objects that implemented IActionListeners and use them instead of separate methods. But.... :) It sounds to me like what you really want to do is to create a component, the EditWidgetLink component. That component would contain the listener method responsible for activating the page, and would have a parameter of type "Widget". It would render the direct link with the appropriate parameters. Then, the next time you have an "Edit Widget" place, you can just do something like: <a href="@EditWidgetLink" widget="ognl:myWidget">Edit Widget</a> Or, if the text is always Edit Widget, then you could put the text in the component... or, your component could query the passed in widget for its name and then you'd have Edit <WidgeName>, and so on and so forth. HTH
Robert

Jim Steinberger wrote:

Howdy!



Problem:  I have 9 pages which each have the link: "Edit Widget".  This
link invokes a listener that each page contains: "editWidget(Integer
widgetId)".  This listener, as you'd suspect, queries out the widget by
its primary key and goes to the EditWidgetPage (or, if there's an error,
sets an error message and returns to the calling page).



I only want to create that listener once so as to A) ease maintenance
and B) simplify my page classes by removing clutter (read: cookie-cutter
code).





The solution I'm about to try:

Create a class that implements IActionListener.  For the example above,
it would be named EditWidgetListener.



To query the Widget out, I've been injecting a WidgetService into my
pages via Spring (I'm using the tapestry-spring.jar from
http://wiki.apache.org/jakarta-tapestry/Tapestry4Spring  -- I just now
discovered HLS's
http://howardlewisship.com/tapestry-javaforge/tapestry-spring/ and
haven't tried it).  Similarly, I can have Spring inject such
dependencies into my EditWidgetListener and then use Spring to manage
the class (i.e. dependency-injection notwithstanding, pulling the
listener from Spring's object pool should trump instantiating it
manually each time, right?).  To wit, my DirectLink components would
change from:



< ... jwcid="@DirectLink" ... listener="listener:editWidget" ... >



To:



< ... jwcid="@DirectLink" ... listener="spring:editWidgetListener" ... >





Anyone see any problems with this?  I'm still pretty ignorant of
HiveMind, but my intuitive guess is that I could do the same thing with
HiveMind - I'd still have access to the Spring context (right?), but in
addition I would have access to the HiveMind contexts so I could, say,
inject pages and ASOs into my listener class.  Is that right?



Thanks for any thoughts,

Jim





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

Reply via email to