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: <tapestry-user@jakarta.apache.org>
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]
