Tapestry only takes care of the objects that you tell it to manage. So
while you won't be able to make "new User()" work that way, you can
register a UserFactory (or UserSource or UserBuilder or whatever) in
Tapestry and call
_userFactory.newUser();
public static void bind(ServiceBinder binder) {
binder.bind(UserFactory.class, UserFactoryImpl.class);
}
If your User object depends on services then the factory can set them
via the constructor, or setter methods. It's not the same as the magic
of @Inject, but it keeps the logic nice and localized.
Josh
On Fri, Apr 4, 2008 at 2:25 PM, Nguyen, Michael
<[EMAIL PROTECTED]> wrote:
> Thanks for your response. I actually already did this. What I wanted to
> get away from was passing the request object around so much. I should
> be able to say new User() without having to worry about getting a
> reference to the request. I guess I should have included that in my
> initial email.
>
> Thanks again !
>
> --Michael
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Josh Canfield
> Sent: Friday, April 04, 2008 12:55 PM
> To: Tapestry users
>
> Subject: Re: accessing requestglobals inside dispatcher and other data
> support classes
>
> Take another look at Dispatcher 2. It takes an ApplicationStateManager
> as a parameter to the constructor. Add your RequestGlobals to the
> constructor in the same way. Tapestry will wire up the configured
> object.
>
> public SingletonAccessControllerImpl(ApplicationStateManager
> asm, RequestGlobals globals) {
> this.asm = asm;
> this.globals = globals;
> }
>
> Josh
>
> On Fri, Apr 4, 2008 at 12:09 PM, Nguyen, Michael
> <[EMAIL PROTECTED]> wrote:
> > The code I uploaded was there to illustrate. I stepped through with a
>
> > debugger to find that those instance variables are null once I am
> > inside any method. I figured that I was doing something wrong so I
> > didn't want to confuse matters and put references to the objects in
> the sample.
> >
> > Thanks for the clarification on UserPermissions.
> > However, shouldn't dispatchers have access to the RequestGlobals
> > service considering it is part of the request processing flow? If not,
>
> > how do I obtain the IP address of the user coming in? I intend on
> > validating the user during the execution of the AccessController
> > Dispatcher. My intention is to perform user authentication during
> this process.
> >
> > My goal is to provide an authentication mechanism that is transparent
> > to the pages. The entire application is not accessible unless you are
>
> > authenticated. Thus, I want to alleviate the responsibliity of that
> > away from the page classes. Once a user logs in, he/she should be
> > able to go anywhere in the application. The dispatcher should
> > determine if the user has a valid session and direct the user to the
> > appropriate pages if the user's session expires and somehow handle
> > returning the user to the current request after successfully logging
> in.
> >
> > The key thing for me is that the remote IP address will be used for IP
>
> > authentication. That information is not available through the Request
>
> > object.
> >
> > Does this make any sense? Am I approaching this the wrong way?
> >
> > Thanks,
> > Michael
> >
> >
> >
> > -----Original Message-----
> > From: Jonathan Barker [mailto:[EMAIL PROTECTED]
> > Sent: Friday, April 04, 2008 11:49 AM
> > To: 'Tapestry users'
> > Subject: RE: accessing requestglobals inside dispatcher and other data
>
> > support classes
> >
> > Michael,
> >
> > This is not a page class, so Tapestry will not process your
> injections.
> >
> > You also haven't used either of your injected properties, so why are
> > they there?
> >
> >
> > Jonathan
> >
> > > -----Original Message-----
> > > From: mnguyen21 [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, April 04, 2008 2:29 PM
> > > To: users@tapestry.apache.org
> > > Subject: accessing requestglobals inside dispatcher and other data
> > > support classes
> > >
> > >
> > > Hi everybody,
> > > I'm basically starting to learn T5 all over again. I'm trying to
> > > implement an AccessController based on Chris Lewis' articles and
> > > have hit a roadblock.
> > > http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher
> > > Dispatcher1
> > > http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2
> > > Dispatcher2
> > >
> > > I can't seem to access the requestGlobals Service in either the
> > > dispatcher or any of the User classes. I've tried adding the
> > > following to each of the
> > > classes:
> > >
> > > @Inject
> > > @Service("RequestGlobals")
> > > private RequestGlobals requestGlobals;
> > >
> > > Inside the dispatcher I try to create a UserPermissions object.
> > > This object requires things from the session and request. I thought
>
> > > I would try to inject the requestGlobals into the UserPermissions
> class.
> >
> > > The reason I need the RequestGlobals service is that Request does
> > > not contain the remote IP address of the current request, only the
> > > HttpServletRequest object does.
> > >
> > > Each time this results in a null value for requestGlobals.
> > > According to the wiki, "RequestGlobals" is a readily available
> > > service I should just be able to inject into any other page. Am I
> > > interpreting this wrong? Is there something I need to do in the
> > > AppModule class in order to make the RequestGlobals service
> available to my classes?
> > >
> > >
> > > Thanks,
> > > Michael
> > >
> > > btw, I've uploaded a copy of my "UserPermissions" class ( its called
>
> > > UserSettings now) for reference.
> > >
> > > http://www.nabble.com/file/p16495148/UserSettings.java
> > > UserSettings.java
> > > --
> > > View this message in context: http://www.nabble.com/accessing-
> > > requestglobals-inside-dispatcher-and-other-data-support-classes-
> > > tp16495148p16495148.html
> > > Sent from the Tapestry - User mailing list archive at Nabble.com.
> > >
> > >
> > > --------------------------------------------------------------------
> > > - 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]
> >
> >
>
>
>
> --
> --
> TheDailyTube.com. Sign up and get the best new videos on the internet
> delivered fresh to your inbox.
>
> ---------------------------------------------------------------------
> 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]
>
>
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
