myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lightbulb432 <>
Subject Re: Understanding JSF/MyFaces
Date Fri, 08 Dec 2006 21:22:07 GMT

Simon Kitching-3 wrote:
> Yep. That's why there is an option to encrypt the client-side state.
> However in general it's not necessary; all the user can do is stuff up 
> their own use of the app. Remember that all JSF does is pass data 
> through to managed beans that then implement the business logic; that 
> java code should only allow users to perform valid operations.

What about their ability to mess with converters and validators? I'm sure
the managed beans would have some assumptions about the data passed in to
them based on the converters and validators and other things used. Are these
also serialized to the client?

> The controller tree state is stored in the user's http session.
> A hidden field is needed in the page in order to ensure that when a user 
> clicks the "back" button, or runs multiple windows in parallel, that the 
> right controller state is pulled from the user's http session; myfaces 
> keeps the last N controller trees in the session where N is configurable 
> precisely in order to support back buttons when using server-side state.

Sorry, what do you mean by "controller" tree state? Did you mean component?

Could you please expand on this back button issue? I'm sure it's not just
the fact that you're viewing an outdated page that hasn't been refreshed
with the most current data (as I'm guessing that could be simply solved by
setting the page to not be cached.) Is it similar to the issue with, for
example, online banking, where you click the back button and it gives a
browser error? What is the back button issue, and how does JSF help to
resolve it?

View this message in context:
Sent from the MyFaces - Users mailing list archive at

View raw message