That works great! Thanks for all the help. I'm almost starting to like all this new Hivemind stuff ;)
RMC p.s. actually it makes a great deal of sense On 12/14/05, Ron Piterman <[EMAIL PROTECTED]> wrote: > > I have an improvement for you :) > if you add an interface to your service point "ConnectionProxy", say A, > *and* your class MyController exposes a public class "setXXX(A)" *and* > hivemind does have only *one* service point of interface A, it will be > autowired to MyController: hivemind will call setXXX(a), where a is the > service ConnectionProxy, constructed by hivemind. > > So, you can have a bunch of different services, and if each one is > defined by a unique interface, all you need is (love) expose in your > implementation class a set method, and hivemind does the work. no need > to <set-object>... > > that makes thing alot easier when you have more than 2 services and many > dependencies. you don't have to <set-object> for each dependency, but > make sure the service-pont-interface is unique. > > > Ralph Churchill wrote: > > I think I have a solution, but it still seems a little cumbersome. > > > > Each of my pages already delegates its business logic to a "controller" > > class. The "controller" classes, in turn, use DAOs. So, in each page I > > <inject> a controller as a property and use a hivemind service: > > > > <inject property="homeController" object="service:Controller"/> > > > > I define the controller service point, like so and give it another > property, > > "connection": > > > > <service-point id="Controller"> > > <invoke-factory> > > <construct class="MyController"> > > <set-object property="connection" > > value="service:ConnectionProxy"/> > > </construct> > > </invoke-factory> > > </service-point> > > > > <service-point id="ConnectionProxy"> > > <invoke-factory model="threaded"> > > <construct class="MyConnectionProxy"/> > > </invoke-factory> > > </service-point> > > > > This works great! Is this an acceptable way to do things? The only issue > I > > have is that I have to create an unnecessary interface, "Controller", > for > > each page's controller class. Any comments/suggestions? > > > > RMC > > > > On 12/13/05, Ralph Churchill <[EMAIL PROTECTED]> wrote: > > > >>Are you talk about this article? > >> > >>http://www.theserverside.com/articles/article.tss?l=HivemindBuzz > >> > >>Thanks. > >> > >>RMC > >> > >>On 12/13/05, Ron Piterman <[EMAIL PROTECTED]> wrote: > >> > >>>Didier LAFFORGUE wrote: > >>> > >>>>In Tapestry 3.0.3, I had a simple way to get a connection for each > >>>>request: all my pages extended a special page (implementing > >>>>PageRenderListener) which did some stuffs as: check the if the current > >>> > >>>>user was authentified, ...etc and open a connection ! > >>>>The code: > >>>> > >>>>/** The special Page */ > >>>>public class SpecialPage extends BasePage implements > >>>>PageValidateListener, PageRenderListener { > >>>> ... > >>>> public void pageBeginRender(PageEvent event) { > >>>> // open a new connection > >>>> } > >>>> > >>>> public void pageEndRender(PageEvent event) { > >>>> // close the connection > >>>> } > >>>>} > >>>> > >>>>public class MyPage extends SpecialPage { > >>>> > >>>> > >>>>} > >>>> > >>>>I think this solution is not the best in Tapestry 4.0 but it must > >>> > >>>work. > >>> > >>>>The big problem is that you have to refactor all your existing pages > >>> > >>>to > >>> > >>>>extend SpecialPage. > >>> > >>>Read thoroughly (does it spell like that?) the article about hivemind > in > >>>'the server side'. There is an example there for just what you are > >>>trying to do. > >>>In Tapestry 4 you use a services layer approach, which, imo, is *much* > >>>better then solving this in the UI layer, like you did in 3. It > >>>seperates concerns and is, in end effect, much better to work with. > >>> > >>> > >>> > >>>> > >>>> > >>>>----- Original Message ----- From: "Ron Piterman" < [EMAIL PROTECTED]> > >>>>To: <[email protected]> > >>>>Sent: Tuesday, December 13, 2005 1:23 AM > >>>>Subject: Re: Tapestry4 setupForRequest "replacement"? > >>>> > >>>> > >>>> > >>>>>what about wrapping an object around your initialization and using it > >>>>>in a hivemind threaded model? > >>>>> > >>>>>Ralph Churchill wrote: > >>>>> > >>>>> > >>>>>>In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a > >>>>>>DataSource from JNDI, open a Connection from it and make the > >>> > >>>Connection > >>> > >>>>>>accessible via static methods to my DAO classes. I closed Connection > >>> > >>>via > >>> > >>>>>>overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC > >>> > >>>>>>-- no > >>>>>>Hibernate, Spring, etc. > >>>>>> > >>>>>>This simple scheme has worked very well so far. > >>>>>> > >>>>>>I'm looking for an equivalent in Tapestry4. I have seen this sort of > >>> > >>>>>>question posed numerous times, but not sufficiently answered. I'm > >>>>>>wondering, > >>>>>>what is the best way to implement functionality similar to this? I > >>>>>>have some > >>>>>>ideas: using RequestGlobals, injecting a service with a "request" or > >>>>>>"thread" scope, etc. > >>>>>> > >>>>>>Please note: for my configuration, a servlet filter is not a viable > >>>>>>option. > >>>>>>Thanks. > >>>>>> > >>>>>>RMC > >>>>>> > >>>>> > >>>>> > >>>>>--------------------------------------------------------------------- > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: > [EMAIL PROTECTED] > >>> > >>>> > >>>> > >>>>This message contains information that may be privileged or > >>> > >>>confidential > >>> > >>>>and is the property of the Capgemini Group. It is intended only for > >>> > >>>the > >>> > >>>>person to whom it is addressed. If you are not the intended recipient, > >>> > >>>>you are not authorized to read, print, retain, copy, disseminate, > >>>>distribute, or use this message or any part thereof. If you receive > >>>>this message in error, please notify the sender immediately and > >>> > >>>delete > >>> > >>>>all copies of this message. > >>>> > >>>> > >>>>--------------------------------------------------------------------- > >>>>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] > >
