Re: T5 how to control login state
lls it to go on. After the dispatcher/requestHandler code executes what is the next dispatcher/filter in line? How can I find that out? Thanks again guys! --Michael -Original Message- From: Chris Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 2:31 PM To: Tapestry users Subject: Re: T5 how to control login state Michael, I'm pretty sure tapestry has no such mechanism. The short answer to your question is that you'd have to store these things (page names of failed/unauthorized access attempts) as an ASO, and then pull it out after logging in. I've not worked with a system like you're talking about, but am glad that T5 is lacking in XML. However something like this could probably useful, and may be doable in the form of some service. First of all I should point out the link to how you can implement a redirect exception: http://wiki.apache.org/tapestry/Tapestry5RedirectException This is a bit of a hack, but demonstrates how you can get the exception back, as well as use decoration. I think what you want is attainable through services, and probably as a dispatcher. I'll need someone with a more thorough understanding of T5 to chime in on this, especially someone that has used what you are looking for. If a dispatcher handles the request, it is responsible for sending the response (HTTP and content) to the client. With that you should have the basics for what you want. You may also have this option with RequestFilters, but I'm not sure. Anyway, someone with more knowledge on the workings would be good to hear. I'd like to know how you fare as I'm always in the market for a better way to do things. Sincerely, chris Nguyen, Michael wrote: Thiago, I know that on pages or components navigation is controlled by the return type. ( page class, String, etc) My question has to do with how to deal with navigation before any page or component renders. In other frameworks you can have a workflows specified outside the application in XML, a database, etc. These workflows determine page flow. In tapestry, however this is not the case that I've seen. I've partially implemented what Chris just posted about the Dispatcher but using the RequestFilter like Massimo suggested. What I don't know how to do is to cleanly specify where to go after logging the user in without having to manually stuff something into the HttpSession about where to return in the page flow. Any ideas? --Michael -Original Message- From: Thiago H de Paula Figueiredo [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 10:52 AM To: Tapestry users Subject: Re: T5 how to control login state On Wed, 07 Nov 2007 16:40:45 -0200, Nguyen, Michael <[EMAIL PROTECTED]> wrote: Chris, Is it standard practice in Tapestry for page redirects to throw exceptions? That's true for Tapestry 4.x, but not for Tapestry 5. -- Thiago H. de Paula Figueiredo Desenvolvedor, Instrutor e Consultor de Tecnologia Eteg Tecnologia da Informação Ltda. http://www.eteg.com.br - 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]
RE: T5 how to control login state
Hi, Though I'm still in the design phase of my work flow mechanism I would like to share it here as it seems you are looking for something similar. I store a Workflow Object in ASO containing a List containing the pages to walk though, and a child WorkFlow containing a potential sub WorkFlow. I will initially populate these objects hardcoded when needed, but these could obviously come from any DataSource created at startup or page action. I have a GenericPage which all my pages extend and catches all action and form requests. It will redirect to the next page in the workflow object and remove it from the List. If there is a child WorFlow, the redirect page will be obtained from there until there are no more. This approach currently relies on using submits or action links, but can easily be altered to also work on pagelinks. I'm using a GenericPage because I already have one, but this could obviously also be achieved with a RequestFilter (or Dispatcher?? haven't looked into those yet ;-) Next to that I also will build a component to print out the workflow state giving me a generic navigation tool for all my wizards/workflows. I played with apache Shale-Dialog (with apache myfaces) for a while and liked the possibilities but found the configuration somewhat hard to get my head around. If you already have a code base that reads out your work flow config I don't think it will be hard to make this work with T5. Cheers, Joost -Original Message- From: Nguyen, Michael [mailto:[EMAIL PROTECTED] Sent: Thursday, November 08, 2007 12:01 PM To: Tapestry users Subject: RE: T5 how to control login state Chris/Thiago: Thanks for the responses. What I'm getting at is trying to see if it is at all possible to allow page flow control reside outside of code. The reason for this is that I don't want to have to make code changes if I want a different flow. Externalizing the workflow makes this possible. It also defines a clear path of execution for a given request. We currently have our workflows defined in XML, which is read in on applcation start. At any point in time during the execution of the workflow, I can print out it's expected route of execution. I'll know the entire decision tree up front before anything executes. Being that it is outside of code, I can view the workflow while the application is offline as well. Having a workflow engine can help differentiate code from business logic. Our current implementation resembles the State pattern I believe. Imagine this, there are a given set of instructions ( externally defined workflow); each represent an action a user can take within the application. ( ie search, open a document, etc). Each workflow can be composed of many steps or instructions. The application acts as the interpreter of the workflow. It makes no decision of its own. All it knows about is the current state of the workflow. The actions the application takes depends on the current state of the workflow. Each step ( state) defines a set of possible actions to take based upon the result of the last action which it passes to the application and which the application passes back to the workflow. By doing it this way, you can easily add new workflows without having to touch any code. For instance, you could combine a series of searches in one workflow. There are many open source workflow engines around. You can find a few at this link here: http://java-source.net/open-source/workflow-engines We currently have our own engine we implemented with our current architecture. I am trying to figure out a way to integrate it into Tapestry. As for my initial question, it seems that using the ASO mechanism you describe is the way to go for now. I agree with you that currently an answer probably lies in services. However, I'm not too familiar with Tapestry to the extent to understand how to hook up the AccessDispatcher/RequestHandler to some service that handles the redirection. I guess I need more detailed information of the request handling. From the docs, the service() methods return true or false. A true tells it processor the request has finished and false tells it to go on. After the dispatcher/requestHandler code executes what is the next dispatcher/filter in line? How can I find that out? Thanks again guys! --Michael -Original Message- From: Chris Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 2:31 PM To: Tapestry users Subject: Re: T5 how to control login state Michael, I'm pretty sure tapestry has no such mechanism. The short answer to your question is that you'd have to store these things (page names of failed/unauthorized access attempts) as an ASO, and then pull it out after logging in. I've not worked with a system like you're talking about, but am glad that T5 is lacking in XML. However something like this could probably useful, and may be
RE: T5 how to control login state
Chris/Thiago: Thanks for the responses. What I'm getting at is trying to see if it is at all possible to allow page flow control reside outside of code. The reason for this is that I don't want to have to make code changes if I want a different flow. Externalizing the workflow makes this possible. It also defines a clear path of execution for a given request. We currently have our workflows defined in XML, which is read in on applcation start. At any point in time during the execution of the workflow, I can print out it's expected route of execution. I'll know the entire decision tree up front before anything executes. Being that it is outside of code, I can view the workflow while the application is offline as well. Having a workflow engine can help differentiate code from business logic. Our current implementation resembles the State pattern I believe. Imagine this, there are a given set of instructions ( externally defined workflow); each represent an action a user can take within the application. ( ie search, open a document, etc). Each workflow can be composed of many steps or instructions. The application acts as the interpreter of the workflow. It makes no decision of its own. All it knows about is the current state of the workflow. The actions the application takes depends on the current state of the workflow. Each step ( state) defines a set of possible actions to take based upon the result of the last action which it passes to the application and which the application passes back to the workflow. By doing it this way, you can easily add new workflows without having to touch any code. For instance, you could combine a series of searches in one workflow. There are many open source workflow engines around. You can find a few at this link here: http://java-source.net/open-source/workflow-engines We currently have our own engine we implemented with our current architecture. I am trying to figure out a way to integrate it into Tapestry. As for my initial question, it seems that using the ASO mechanism you describe is the way to go for now. I agree with you that currently an answer probably lies in services. However, I'm not too familiar with Tapestry to the extent to understand how to hook up the AccessDispatcher/RequestHandler to some service that handles the redirection. I guess I need more detailed information of the request handling. From the docs, the service() methods return true or false. A true tells it processor the request has finished and false tells it to go on. After the dispatcher/requestHandler code executes what is the next dispatcher/filter in line? How can I find that out? Thanks again guys! --Michael -Original Message- From: Chris Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 2:31 PM To: Tapestry users Subject: Re: T5 how to control login state Michael, I'm pretty sure tapestry has no such mechanism. The short answer to your question is that you'd have to store these things (page names of failed/unauthorized access attempts) as an ASO, and then pull it out after logging in. I've not worked with a system like you're talking about, but am glad that T5 is lacking in XML. However something like this could probably useful, and may be doable in the form of some service. First of all I should point out the link to how you can implement a redirect exception: http://wiki.apache.org/tapestry/Tapestry5RedirectException This is a bit of a hack, but demonstrates how you can get the exception back, as well as use decoration. I think what you want is attainable through services, and probably as a dispatcher. I'll need someone with a more thorough understanding of T5 to chime in on this, especially someone that has used what you are looking for. If a dispatcher handles the request, it is responsible for sending the response (HTTP and content) to the client. With that you should have the basics for what you want. You may also have this option with RequestFilters, but I'm not sure. Anyway, someone with more knowledge on the workings would be good to hear. I'd like to know how you fare as I'm always in the market for a better way to do things. Sincerely, chris Nguyen, Michael wrote: > Thiago, > I know that on pages or components navigation is controlled by the return > type. ( page class, String, etc) My question has to do with how to deal with > navigation before any page or component renders. In other frameworks you can > have a workflows specified outside the application in XML, a database, etc. > These workflows determine page flow. In tapestry, however this is not the > case that I've seen. > > I've partially implemented what Chris just posted about the Dispatcher > but using the RequestFilter like Massimo suggested. What I don'
Re: T5 how to control login state
Michael, I'm pretty sure tapestry has no such mechanism. The short answer to your question is that you'd have to store these things (page names of failed/unauthorized access attempts) as an ASO, and then pull it out after logging in. I've not worked with a system like you're talking about, but am glad that T5 is lacking in XML. However something like this could probably useful, and may be doable in the form of some service. First of all I should point out the link to how you can implement a redirect exception: http://wiki.apache.org/tapestry/Tapestry5RedirectException This is a bit of a hack, but demonstrates how you can get the exception back, as well as use decoration. I think what you want is attainable through services, and probably as a dispatcher. I'll need someone with a more thorough understanding of T5 to chime in on this, especially someone that has used what you are looking for. If a dispatcher handles the request, it is responsible for sending the response (HTTP and content) to the client. With that you should have the basics for what you want. You may also have this option with RequestFilters, but I'm not sure. Anyway, someone with more knowledge on the workings would be good to hear. I'd like to know how you fare as I'm always in the market for a better way to do things. Sincerely, chris Nguyen, Michael wrote: Thiago, I know that on pages or components navigation is controlled by the return type. ( page class, String, etc) My question has to do with how to deal with navigation before any page or component renders. In other frameworks you can have a workflows specified outside the application in XML, a database, etc. These workflows determine page flow. In tapestry, however this is not the case that I've seen. I've partially implemented what Chris just posted about the Dispatcher but using the RequestFilter like Massimo suggested. What I don't know how to do is to cleanly specify where to go after logging the user in without having to manually stuff something into the HttpSession about where to return in the page flow. Any ideas? --Michael -Original Message- From: Thiago H de Paula Figueiredo [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 10:52 AM To: Tapestry users Subject: Re: T5 how to control login state On Wed, 07 Nov 2007 16:40:45 -0200, Nguyen, Michael <[EMAIL PROTECTED]> wrote: Chris, Is it standard practice in Tapestry for page redirects to throw exceptions? That's true for Tapestry 4.x, but not for Tapestry 5. -- Thiago H. de Paula Figueiredo Desenvolvedor, Instrutor e Consultor de Tecnologia Eteg Tecnologia da Informação Ltda. http://www.eteg.com.br - 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]
Re: T5 how to control login state
Em Wed, 07 Nov 2007 18:31:35 -0200, Nguyen, Michael <[EMAIL PROTECTED]> escreveu: Thiago, Hi, Michael! I know that on pages or components navigation is controlled by the return type. ( page class, String, etc) My question has to do with how to deal with navigation before any page or component renders. In other frameworks you can have a workflows specified outside the application in XML, a database, etc. These workflows determine page flow. In tapestry, however this is not the case that I've seen. Now I've understood what you want. Sorry, I can't help you. Coming from a Struts background, anything that resembles page navigation rules not written in Java code makes me feel sick (or angry, depending on the moment). :) Thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 how to control login state
Thiago, I know that on pages or components navigation is controlled by the return type. ( page class, String, etc) My question has to do with how to deal with navigation before any page or component renders. In other frameworks you can have a workflows specified outside the application in XML, a database, etc. These workflows determine page flow. In tapestry, however this is not the case that I've seen. I've partially implemented what Chris just posted about the Dispatcher but using the RequestFilter like Massimo suggested. What I don't know how to do is to cleanly specify where to go after logging the user in without having to manually stuff something into the HttpSession about where to return in the page flow. Any ideas? --Michael -Original Message- From: Thiago H de Paula Figueiredo [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 10:52 AM To: Tapestry users Subject: Re: T5 how to control login state On Wed, 07 Nov 2007 16:40:45 -0200, Nguyen, Michael <[EMAIL PROTECTED]> wrote: > Chris, > Is it standard > practice in Tapestry for page redirects to throw exceptions? That's true for Tapestry 4.x, but not for Tapestry 5. -- Thiago H. de Paula Figueiredo Desenvolvedor, Instrutor e Consultor de Tecnologia Eteg Tecnologia da Informação Ltda. http://www.eteg.com.br - 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]
Re: T5 how to control login state
On Wed, 07 Nov 2007 16:40:45 -0200, Nguyen, Michael <[EMAIL PROTECTED]> wrote: Chris, Is it standard practice in Tapestry for page redirects to throw exceptions? That's true for Tapestry 4.x, but not for Tapestry 5. -- Thiago H. de Paula Figueiredo Desenvolvedor, Instrutor e Consultor de Tecnologia Eteg Tecnologia da Informação Ltda. http://www.eteg.com.br - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 how to control login state
Chris, Thanks for your insightful wiki on this subject. This seems a much lighter weight solution to the Acegi Authentication. ( the latter requires many more jar file downloads related to Spring) I do have a question that's been on my mind for some time now. Is it standard practice in Tapestry for page redirects to throw exceptions? Is there another method that preserves the current state after a redirection? Say for instance, a user bookmarks a page and returns to it two days later. How does one determine the resultant page after a successful login? Using the current code, the user's session would be invalid and forced to the login page when trying to access the bookmark via an exception. How would you save the destination url for the user after he/she logs in successfully? Rather is there a "standard" way that Tapestry does this? Would you have to put it into the ASM and then access the ASM during login to determine the users destination? Is there another mechanism? Thanks, Michael -Original Message- From: Chris Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 8:10 AM To: Tapestry users Subject: Re: T5 how to control login state I've created a new article to supplement the first, showing how to access thread-specific ASOs from a singleton service. It's on the wiki: http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 sincerely, chris Angelo Chen wrote: > Hi Chris, > > I'm interested in your approach and read already the wiki, you spent a > lot to explain the concept behind, can you also provide a > simple/complete sample code for that? thanks. > > A.C. > > > Chris Lewis-5 wrote: > >> I'll update the wiki. >> >> chris >> >> >> lyifan wrote: >> >>> Thanks a lot everyone. Finally the BasePase way works >>> >>> But the d >>> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
I've created a new article to supplement the first, showing how to access thread-specific ASOs from a singleton service. It's on the wiki: http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2 sincerely, chris Angelo Chen wrote: Hi Chris, I'm interested in your approach and read already the wiki, you spent a lot to explain the concept behind, can you also provide a simple/complete sample code for that? thanks. A.C. Chris Lewis-5 wrote: I'll update the wiki. chris lyifan wrote: Thanks a lot everyone. Finally the BasePase way works But the d
Re: T5 how to control login state
Hi Chris, I'm interested in your approach and read already the wiki, you spent a lot to explain the concept behind, can you also provide a simple/complete sample code for that? thanks. A.C. Chris Lewis-5 wrote: > > > I'll update the wiki. > > chris > > > lyifan wrote: >> Thanks a lot everyone. Finally the BasePase way works >> >> But the d > -- View this message in context: http://www.nabble.com/T5-how-to-control-login-state-tf4744201.html#a13625879 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
Hi Chris, Is the wiki article updated? I'd like to try that approach. the wiki site seems down as of this moment. A.C. Chris Lewis-5 wrote: > > Marcus, > > I would like to expand on this as it does seem perferable. > > chris > > Marcus wrote: >> Hi Massimo, >> >> Can you post some code about this RequestFilter solution ? >> >> Thanks, >> >> Marcus >> >> - >> 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] > > > -- View this message in context: http://www.nabble.com/T5-how-to-control-login-state-tf4744201.html#a13623915 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
On Nov 5, 2007 9:32 PM, Marcus <[EMAIL PROTECTED]> wrote: > Hi Massimo, > > Can you post some code about this RequestFilter solution ? It's really the same as with the Dispatcher both API has just one method, thanks Howard! So the example in the wiki is adaptable to the RequestFilter just implement the: boolean service(Request request, Response response, RequestHandler handler) method. As Chris will update the wiki I'll try to contribute some. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
Marcus, It works fundamentally the same as using a dispatcher, with the benefit that it runs before the dispatcher pipeline. The big difference is you'd implement RequestFilter instead of Dispatcher, and you'd contribute to that pipeline accordingly. Keep in mind that you will face the same issues regarding ASOs, which can be solved in the same way as with dispatchers. That is, implement your Dispatcher or RequestFilter so that the constructor takes an ApplicationStateManager instance, and then auto-bind in your app module (or build if you require more initialization). I would like to expand on this as it does seem perferable. chris Marcus wrote: Hi Massimo, Can you post some code about this RequestFilter solution ? Thanks, Marcus - 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]
Re: T5 how to control login state
Hi Massimo, Can you post some code about this RequestFilter solution ? Thanks, Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
That's a good point. It would seem to me that the earlier we can check and allow or deny access, the better. I haven't looked into when services like ComponentClassResolver are instantiated, but as long as the basic services (such as that one) are available, I think RequestFilters would be the way to go. I'll post a new wiki covering the @ApplicationState problem, and then perhaps we can explore using RequestFilters and address the issues listed at the end of the first article. Thanks for the good idea Massimo :-). Massimo Lusetti wrote: On Nov 5, 2007 2:02 PM, Chris Lewis <[EMAIL PROTECTED]> wrote: Regarding the dispatcher article (which I wrote), your problem is that you are attempting to use @ApplicationState in a service, and this is not possible, at least in this case. Why? Because state is based on the request, and services are by default singletons. This means you have one instance of your access controller servicing 1 or 10 or 100 simultaneous requests at once. As such, its not possible to use @ApplicationState. I've implemented the same as a RequestFilter which sits on layer above dispatchers. Actually i don't know if this kind of feature is better implemented as a Dispatcher or a RequestFilter... maybe it depends on what you're protecting.
Re: T5 how to control login state
On Nov 5, 2007 2:02 PM, Chris Lewis <[EMAIL PROTECTED]> wrote: > Regarding the dispatcher article (which I wrote), your problem is that > you are attempting to use @ApplicationState in a service, and this is > not possible, at least in this case. Why? Because state is based on the > request, and services are by default singletons. This means you have one > instance of your access controller servicing 1 or 10 or 100 simultaneous > requests at once. As such, its not possible to use @ApplicationState. I've implemented the same as a RequestFilter which sits on layer above dispatchers. Actually i don't know if this kind of feature is better implemented as a Dispatcher or a RequestFilter... maybe it depends on what you're protecting. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
Lyifan (and anyone else considering page extention for access control),
First off, in my opinion centralizing access logic in a base page and
forcing protected pages to extend it is an anti-pattern
(http://en.wikipedia.org/wiki/Anti-pattern), and should therefore be
avoided.
Regarding the dispatcher article (which I wrote), your problem is that
you are attempting to use @ApplicationState in a service, and this is
not possible, at least in this case. Why? Because state is based on the
request, and services are by default singletons. This means you have one
instance of your access controller servicing 1 or 10 or 100 simultaneous
requests at once. As such, its not possible to use @ApplicationState.
However it is possible to access request specific data in your service.
I have implemented this, but after reading your message and looking at
my article, I see I didn't touch this important issue. I will update it
soon.
Here's what you need to do.
First remove the @ApplicationState from your service - you can't use it
from a singleton service.
Next, get friendly with the ApplicationStateManager
(http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/ApplicationStateManager.html).
This is a service that can access state objects on for the current request.
Finally, implement your access controller so that it receives an
instance of the ASM in its constructor, and cache that reference as a
member:
...snip
public SingletonAccessControllerImpl(ApplicationStateManager asm) {
this.asm = asm;
}
...snip
Assuming you used auto binding for the service as shown in the article,
T IoC will handle creating your access controller and providing the
needed ASM. Now you can use the ASM to check for state information on a
per-request basis.
I'll update the wiki.
chris
lyifan wrote:
Thanks a lot everyone. Finally the BasePase way works
But the dispatcher way still doesn't work.
lyifan wrote:
I am a 100% new user for tapestry. Currently I'm working on 5.0.5, but I
got stuck from the just beginning.
I want to implement a kind of user access controller. All the pages,
excepts for the login page, can be accessed by authenticated users only.
users who hasn't passed the authentication will be redirected to the login
page to input their user name and password, and then, if the user name and
password are correct, they will see the page they want
I think this is a very very simple thing to do.But after a few days
working, I am very frustrated.
Firstly, I've tried the onActivate method. My code looks like below:
class BasePage {
@ApplicationState
private UserIdentity _userIdentity;
private boolean _userIdentityExists;
Object onActivate() {
if( !_userIdentityExists)
return "Login"; //Login is my login page
return null;
}
}
And the I visited http://localhost:8080/myapp(default page is start), I
got a blank empty page. There is nothing at all on the browser. But I can
see the login page when I went to http://localhost:8080/myapp/login
After that I found an article at
http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher. According
to this, I created my dispatcher. But I found ASO doesn't work in my
dispatcher class.
boolean _myIdentityExists always be false.
And if I contribute it use "before:PageRender", the dispatch method would
not be invoked then I visit the default start page. I had to use
"before:RootPath". Following it my dispatcher class code:
public class SessionController implements Dispatcher {
@ApplicationState
private MyIdentity _myIdentity;
private boolean _myIdentityExists;
public SessionController() {
System.out.println("SessionController: SessionController
created.");
}
public boolean dispatch(Request request, Response response) throws
IOException {
System.out.println("Requesting " + request.getPath());
if (! _myIdentityExists ) { // _myIdentityExists always be false
if( _myIdentity == null ) { // here MyIdentity won't be
created
_myIdentity = new MyIdentity(); // I have to
create it by myself.
System.out.println("SessionController: Identity does
not exist.");
response.sendRedirect("login");
return true; // this works, I can see the
login page correctly.
}else
System.out.println("SessionController: Identity
exists.");
}
return false;
}
}
and here is the code in AppModule:
public void
contributeMasterDispatcher(OrderedConfiguration configuration,
@InjectService("SessionController") Dispatcher
sessionController) {
configuration.add("SessionController", sessionControll
Re: T5 how to control login state
Thanks a lot everyone. Finally the BasePase way works
But the dispatcher way still doesn't work.
lyifan wrote:
>
> I am a 100% new user for tapestry. Currently I'm working on 5.0.5, but I
> got stuck from the just beginning.
>
> I want to implement a kind of user access controller. All the pages,
> excepts for the login page, can be accessed by authenticated users only.
> users who hasn't passed the authentication will be redirected to the login
> page to input their user name and password, and then, if the user name and
> password are correct, they will see the page they want
>
> I think this is a very very simple thing to do.But after a few days
> working, I am very frustrated.
>
> Firstly, I've tried the onActivate method. My code looks like below:
>
> class BasePage {
> @ApplicationState
> private UserIdentity _userIdentity;
> private boolean _userIdentityExists;
>
> Object onActivate() {
>
> if( !_userIdentityExists)
> return "Login"; //Login is my login page
>
> return null;
> }
> }
>
> And the I visited http://localhost:8080/myapp(default page is start), I
> got a blank empty page. There is nothing at all on the browser. But I can
> see the login page when I went to http://localhost:8080/myapp/login
>
> After that I found an article at
> http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher. According
> to this, I created my dispatcher. But I found ASO doesn't work in my
> dispatcher class.
> boolean _myIdentityExists always be false.
>
> And if I contribute it use "before:PageRender", the dispatch method would
> not be invoked then I visit the default start page. I had to use
> "before:RootPath". Following it my dispatcher class code:
>
> public class SessionController implements Dispatcher {
>
> @ApplicationState
> private MyIdentity _myIdentity;
> private boolean _myIdentityExists;
>
> public SessionController() {
> System.out.println("SessionController: SessionController
> created.");
> }
>
> public boolean dispatch(Request request, Response response) throws
> IOException {
> System.out.println("Requesting " + request.getPath());
>
> if (! _myIdentityExists ) { // _myIdentityExists always be false
> if( _myIdentity == null ) { // here MyIdentity won't be
> created
> _myIdentity = new MyIdentity(); // I have to
> create it by myself.
> System.out.println("SessionController: Identity
> does not exist.");
> response.sendRedirect("login");
>return true; // this works, I can see the
> login page correctly.
> }else
> System.out.println("SessionController: Identity
> exists.");
> }
>
> return false;
> }
> }
>
> and here is the code in AppModule:
> public void
> contributeMasterDispatcher(OrderedConfiguration configuration,
> @InjectService("SessionController") Dispatcher
> sessionController) {
> configuration.add("SessionController", sessionController,
> "before:PageRender");
> }
>
>
> before:PageRender and before:Asset do not call dispatch method,
> before:RootPath does
>
> I set the session timeout to 1 min in the web.xml.
>
> 1
>
>
> After 1 min, I came to the start page.supposedly, I would be redirected to
> the login page because session is timeout. But I could still visit the
> start page, which meas _myIdentity is still in the Session after the
> timeout. Is it a bug or I shouldn't create it by myself?
>
--
View this message in context:
http://www.nabble.com/T5-how-to-control-login-state-tf4744201.html#a13576094
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
HI lyifan,
Rename page Login to Start,
/src/main/java//base/ProtectedPage.java
public class ProtectedPage
{
@ApplicationState
private Visit _visit;
// getters and setters of _visit
public Object onActivate() {
if (!_visit.isLogged())
return "Login"; // Go to Login page.
return null;// Ok.
}
}
/src/main/java//pages/Start.java
public class Start {
@ApplicationState
private Visit _visit;
...
public String onSuccess() {
// If login ok.
_visit.setLogin("UserName");
...
}
...
}
/src/main/java//util/Visit.java
public class Visit implements Serializable {
private String _login;
public boolean isLogged() { return (this._login!=null); }
// geters and setters
}
/src/main/java//pages/AnyProtectedPage.java
public class AnyProtectedPage extends ProtectedPage { ... }
this should work.
Marcus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
You've had the misfortune to run into this bug quicker than most. Follow the advice here: http://wiki.apache.org/tapestry/Tapestry5RootPathEmptyResponse And everyone, please vote for this bug! Cheers, Nick. Josh Canfield wrote: Your BasePage class should be in /src/main/java//base/ Your Start class should be in /src/main/java//pages/ and extend BasePage Try adding a breakpoint in your BasePage's onActivate, and your Start's onActivate to make sure they are getting called. Josh On 11/3/07, lyifan <[EMAIL PROTECTED]> wrote: It still doesn't work, Marcus I've changed the onActivate method to public Marcus-11 wrote: Add getters and setters ASO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/T5-how-to-control-login-state-tf4744201.html#a13567511 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]
Re: T5 how to control login state
Your BasePage class should be in /src/main/java//base/ Your Start class should be in /src/main/java//pages/ and extend BasePage Try adding a breakpoint in your BasePage's onActivate, and your Start's onActivate to make sure they are getting called. Josh On 11/3/07, lyifan <[EMAIL PROTECTED]> wrote: > > > It still doesn't work, Marcus > I've changed the onActivate method to public > > > Marcus-11 wrote: > > > > Add getters and setters ASO. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/T5-how-to-control-login-state-tf4744201.html#a13567511 > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > - > 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.
Re: T5 how to control login state
It still doesn't work, Marcus I've changed the onActivate method to public Marcus-11 wrote: > > Add getters and setters ASO. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/T5-how-to-control-login-state-tf4744201.html#a13567511 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
Thank you Marcus. But I can't understand where to add getters and setters. Do you mean put getters and setters to ASO class or to a certain class where declares an ASO? Marcus-11 wrote: > > Add getters and setters ASO. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/T5-how-to-control-login-state-tf4744201.html#a13566970 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
Add getters and setters ASO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 how to control login state
HI lyifan, Your first code should work, as Start.java extends BasePage. just try: ... public Object onActivate() ... Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
