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]
> >
> >
>
