lightbulb432 wrote:
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 impleme
d 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?
Thanks.
--
View this message in context:
http://
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 th
>Unless you plan on being a myfaces core contributor, saying you need to
know all of the internals in order to understand the concepts is like saying
you need to see all of the trees before in order to understand you're
looking at a forest.
That's a pretty big jump you labeled me with. I am sayin
On 12/8/06, lightbulb432 <[EMAIL PROTECTED]> wrote:
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 the
On 12/8/06, Nebinger, David <[EMAIL PROTECTED]> wrote:
For client side state saving, no state information will be kept on the server
(your session information you've stored is still safe). You normally choose
this option when you have large views to deal with or you are serving many end
users
> 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?
I guess if you want to know it all you'd have to s
> >Dude, you're getting yourself bogged down on things that you
> typically
> don't need to understand.
>
> I would disagree. This speaks to what I am trying to
> accomplish right now
> with my datascroller problem. I didn't understand some of
> the details of
> datascroller when I implemen
>Dude, you're getting yourself bogged down on things that you typically
don't need to understand.
I would disagree. This speaks to what I am trying to accomplish right now
with my datascroller problem. I didn't understand some of the details of
datascroller when I implemented it, and now I hav
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.
Thanks.
--
View this message in context:
http://
> How do each of these form fields help JSF do what it does?
> MyFaces is a
> wonderful tool, but I'd like to understand "how" it does what
> it does (on a
> high enough level that it might be explained in a couple of
> detailed replies
> to this post)...because right now it seems a bit "too" tr
ally in those hidden fields) or what? Does the server really store no
state whatsoever about a particular client?
I've read the manuals and tutorials, but I'm still confused on these issues.
Thanks.
--
View this message in context:
http://www.nabble.com/Understanding-JSF-MyFaces-tf2782475.html#a7763279
Sent from the MyFaces - Users mailing list archive at Nabble.com.
12 matches
Mail list logo
