will do!
Peter
Chris Lewis wrote:
Actually by indirection it is also my problem ;-), and I'd like to
know if you find this not to be true. I have done some digging and
chatting (on this list) about this topic, and for all I've found this
appears to be how it is designed. As such I shape my ideas and plans
around this understanding, so if it's wrong then I'm in trouble ;-).
Share some code if you have some that suggests otherwise, and
hopefully Howard will chime in if I'm off.
sincerely,
chris
Peter Stavrinides wrote:
Hi Chris,
Thanks for the clarification, this is what I had initially
thought... however some quick and dirty tests made me doubt this, I
am not sure why it didn't turn up for me that way, I will have to
check my code again ... not your problem anyway.
Thanks again,
Peter
Chris Lewis wrote:
Hi Peter,
I'll ask Howard to verify what I say here as its a pretty important
issue. Short answer: Yes, you will get the same instance using the
state manager as you would from injection via @ApplicationState...
for simultaneous requests made by the same user (and therefore the
same request/session).
That is a very simplified answer. Its important to understand why
you can use @ApplicationState in a page but not in a singleton
service. If you read both wikis and/or docs on the state manager,
you should already have a basic understanding. Under the hood, T5
IoC uses the state manager to retrieve page members marked as state
objects with the @ApplicationState annotation. Why? Because an
instance of a page class may be accessed simultaneously by many
different requests at the same time. In reality the annotation is
just an indicator that a page member is specific to the current
request, NOT the page. Its up to the IoC container to resolve
exactly what request (session) is associated with the requesting
user, and ultimately which instance of your ASO class. I'm quite
sure this work is done by the state manager.
hope that helps
sincerely,
chris
Peter Stavrinides wrote:
Hi Chris,
Thanks for the great wiki article, I have managed to implement what
I needed using 'Tapestry5HowToCreateADispatcher2'. My
implementation is very similar to the example... it seems to work
great!
One question though regarding my ASO (which is similar to your
permissions ASO), you mention "the object referenced by 'perms' is
an instance specific to the current request" does this mean that I
will *not* get the very same instance if I try inject it in a page
class using the @ApplicationState annotation?
Thanks
Peter
Chris Lewis wrote:
Hello Peter,
It sounds like by 'filter' you mean a servlet filter and not a
Tapestry filter. Your requirements sound a tad exotic to me, but
these wikis should get you on the right track:
http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher
http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2
They focus on implementing authentication/restriction code
completely outside of the 'page' level of the application. The
focus on these is the required infrastructure, so there are some
holes left to be filled. At any rate they should be useful for
you. Note that the same thing can be achieved using a Tapestry
filter:
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/RequestFilter.html
Sincerely,
Chris
Peter Stavrinides wrote:
Hi all
My question is more of a best practice related question, I want
to use a filter to extract my authentication code from the rest
of the application logic, so I can avoid adding this logic to
pages. In addition, one of my authentication requirements
involves some integration with third party applications so I need
to check for authentication headers... to accommodate this I use
a session state object in my app (i.e. a T5 service), which is
available for the duration of a users session.
Implementing an ordinary servlet filter would do the trick for
the authentication part... but then I wouldn't be able to use it
with the IoC service. So:
1. Is there a way to register my filter with Tapestry IoC instead
of registering it in web.xml? (would I create a contribution to
the framework?)
2. Can I inject this service (i.e. my state object )into the
filter? and what does this involve i.e. eager loading etc?
I am not sure I am going about this the right way, if someone has
done something similar could I get some pointers.
Thanks in advance,
Peter
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
