myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <simon.kitch...@rhe.co.nz>
Subject Re: Understanding JSF/MyFaces
Date Fri, 08 Dec 2006 20:02:20 GMT
lightbulb432 wrote:
> Thanks for your response.
> 
> Which is a good class to set the first breakpoint in, from which I could
> follow out the rest of the processing? Would it be in the generated servlet,
> in some kind of interceptor class (if using JBoss), the Faces Servlet, or
> where?

You might find this page useful:
    http://wiki.apache.org/myfaces/StudyGuide

> 
> If there's absolutely no information stored on the server, then (assuming
> somebody could unencrypt the content of those fields) technically somebody
> could alter the hidden field values, resubmit the form and see something
> different from what they expected, right?

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.

> 
> With server-side state-saving, how is the information passed between the
> client and the server? (cookies, URL, hidden form fields?)

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.

I don't understand what else you are looking for here.

> 
> I understand I'm asking implementation details that I don't "necessarily"
> need to know in order to use JSF, but I nonetheless need to understand the
> concepts. I think it's unwise for a developer to not know (at least on a
> conceptual level) what's going on the in framework or tool that they're
> using. Not to mention the fact that developers often (if not VERY often)
> need to justify these development choices to others within their
> organizations.

It is definitely useful to understand the concepts. However as has been 
pointed out, exactly what javascript and hidden fields are used for a 
particular implementation are not concepts, they are MyFaces 
implementation artifacts.

The JSF concepts are that there are phases (restore-view, 
apply-request-values, validate, etc). And that there is a "component 
tree". And that components have value-bindings that map into managed 
beans (or anything else in request/session/application scopes).

To use java it's useful to have an understanding of classloaders and 
runtime linking. However it's not necessary to learn JVM bytecode for 
most users. And it's certainly not useful for many people to dive into a 
particular JDK's compiler implementation for example.

I certainly don't mean to discourage you from understanding how MyFaces 
works; I've personally downloaded and read the source code and it was 
interesting and useful. However that kind of detail is not really 
appropriate for this user list. If you truly care, I recommend reading 
the "study guide" page on the wiki (and possibly the rest of the wiki 
too), then the source-code then ask questions on the dev list. The 
people who know enough about MyFaces to answer very detailed 
implementation questions are probably too busy to answer a stream of 
open-ended questions like "how does it work?"..

Regards,

Simon

Mime
View raw message