Rich's point is that pages are re-used: a fresh instance of a page is not instantiated for each request. So yes you'll have your transfer data rendering in the page, but that doesn't mean that data was collected/built/queried from db or whatever in response to the current request.
AFAIK constructors are not the place to put initialisation stuff: as Rich suggested take a look at the @SetupRender annotation and/or the setupRender() method. R. On Mon, 2011-06-06 at 09:42 -0700, robnangle wrote: > Rich M wrote: > > > > On 06/06/2011 12:20 PM, robnangle wrote: > >> Rich M wrote: > >>> On 06/06/2011 12:04 PM, robnangle wrote: > >>>> No didn't seem to make a difference im afraid. I cant think of anything > >>>> that > >>>> would revert the user back to the previous logged in user? > >>>> > >>>> My updated code now looks like: > >>>> > >>>> @SessionState(create=false) > >>>> @Property > >>>> private User user; > >>>> @Property > >>>> private boolean userExists; > >>>> @Property > >>>> private Transfers transfers; > >>>> > >>>> private boolean adminUser; > >>> Don't know the rest of your code, but if this boolean adminUser > >>> determines whether or not show pages, it should be persisted shouldn't > >>> it? Otherwise the value set here is going to clear. When is > >>> UpdatePoints() called? > >>> > > > >> Well does it have to be persisted? I call the adminUser() in every class > >> where it is necessary. The updatePoints() is the constructor so it will > >> be > >> called when the page is loading? > >> > > > > You might want to refresh your knowledge of the page render lifecycle > > and how pages/components operate in T5, based on your comment here. > > > > http://tapestry.apache.org/page-life-cycle.html > > > > Someone else might be better able to explain, but to my knowledge, a > > page is only constructed a minimal amount of times and re-used within > > the application. The page is not constructed to render a response for a > > request. > > > > You'd be looking to call the logic for a page "loading" or rather being > > requested in the onActivate method, or a render phase like @SetupRender. > > > > As for persisted or not, if you are maintaining a user session in your > > application, might I ask what the point is of recalculating their admin > > status if that never changes within a given session? > > > > http://tapestry.apache.org/persistent-page-data.html > > > > Most likely your page is not loading and assigning the adminUser boolean > > like you are expecting, and after your initial login, it's not calling > > any of that code anymore and thus your privileges appear to regress to a > > normal user, when really you aren't calculating them at all. > > > > You might have an easier time figuring this out using some System.out > > commands or better yet using the built-in logging support @Inject > > private Logger log; and provide a Log4J configuration file in > > src/main/resources > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > Yes I agree with you that it is pointless recalculating whether its an admin > user or not. However that constructor is defientley being called as the > transfers display in a sidebar and if it was not being called the transfers > would not display (also them transfers being persisted would make more sense > too). > > So I dont think its a problem of it not being called or not? > > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Clearing-SessionState-tp4458525p4459190.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
