Philosophy of JSF

[lightbulb432 <ve...@hotmail.com>]

Somewhere in the months of learning and reading about JSF, I’ve lost touch
with the basic concepts. Could somebody please explain why state for the
view needs to be stored to begin with? Could JSF be used in a stateless
manner, or is that not how it is meant and designed to be used?

How do alternatives to JSF like Struts, Struts2, and others handle the
concept of view state? (I don’t recall them storing view state on the server
or serializing it to the rendered HTML, so I’m wondering how they provide
similar functionality.)

I realize this is a total newbie question, but I hope you can explain in
clear and thorough terms the concept of JSF as it relates to other
frameworks out there – I can’t conceptualize it easily, even after having
played around with it for a little while.

Thanks.
-- 
View this message in context: http://www.nabble.com/Philosophy-of-JSF-tf3772976.html#a10667738
Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: Philosophy of JSF

[Andrew Robinson <an...@gmail.com>]

I depends.

With server side state saving, up to # number of serialized component
view states are saved into the HttpSession (where # defaults to 20 I
believe). With client side state saving the component state is
serialized and base 64 encoded and put into an '<input type="hidden"
...>' element.

Backing beans are stored in the HttpSession.

On 5/17/07, lightbulb432 <ve...@hotmail.com> wrote:
>
> Thanks for your response.
>
> The tree model and tree state you mentioned as part of the "external
> object", by that do you mean HttpSession state as opposed to component
> state?
>
> Is server-side component state saved to the HttpSession?
>
> For frameworks apart from JSF, if they want to retain the "component state"
> (meaning the way their page looks, as I realize they don't have components),
> how do they do it - just store variables in the HttpSession, then have their
> JSP code output HTML based on the values of those variables? In this case,
> aren't JSF and other frameworks very similar in this way?
>

Re: Philosophy of JSF

[lightbulb432 <ve...@hotmail.com>]

Thanks for your response.

The tree model and tree state you mentioned as part of the "external
object", by that do you mean HttpSession state as opposed to component
state?

Is server-side component state saved to the HttpSession?

For frameworks apart from JSF, if they want to retain the "component state"
(meaning the way their page looks, as I realize they don't have components),
how do they do it - just store variables in the HttpSession, then have their
JSP code output HTML based on the values of those variables? In this case,
aren't JSF and other frameworks very similar in this way?



Andrew Robinson-5 wrote:
> 
> Answers below (in-line). Please (anyone) feel free to correct any
> mistakes I may have made...
> 
> On 5/17/07, lightbulb432 <ve...@hotmail.com> wrote:
>>
>> Somewhere in the months of learning and reading about JSF, I've lost
>> touch
>> with the basic concepts. Could somebody please explain why state for the
>> view needs to be stored to begin with?
> 
> Well, with facelets, it doesn't really
> 
>> Could JSF be used in a stateless
>> manner, or is that not how it is meant and designed to be used?
> 
> For the most part yes, but probably not desirable
> 
>> How do alternatives to JSF like Struts, Struts2, and others handle the
>> concept of view state?
> 
> The don't, they have no component state
> 
>> I realize this is a total newbie question, but I hope you can explain in
>> clear and thorough terms the concept of JSF as it relates to other
>> frameworks out there – I can't conceptualize it easily, even after having
>> played around with it for a little while.
> 
> JSF is built around components and component states. The idea is to
> produce a web framework that acts much like a GUI framework like
> Swing, but for the web. The component tree is like the AWT/Swing
> component instances that make up a JFrame (for example). Each
> component in a JFrame has properties. Those properties could be simple
> ones, like foreground color, or complex ones like a tree model.
> 
> When a JSF view is rendered, the view is serialized down into its
> state. The actual components are not stored, but their state is. This
> is done by calling componet.saveState recursively on all components in
> the component tree that are not transient.
> 
> Now, JSP requires a "heavy" implementation of the view state because
> once the JSP tags build the components, there is no way to rebuild the
> same component tree during the restore view phase on the next request.
> It therefore needs to store everything about the components, including
> all the value bindings and other attributes.
> 
> Facelets on the other hand uses an XML representation of the view that
> allows the FaceletsViewHandler to create a component tree directly
> from that XML, skipping the tag->component "phase". It has the
> information to reset all the value bindings an other attributes on
> each request and do so reliably.
> 
> Unfortunately for us facelet users, the view state is still saved as
> per needed by JSP and therefore is not optimized for a technology like
> facelets (hopefully JSF 2.0 will continue improving this).
> 
> Also, some component developers choose to save state like if a tree
> node is expanded or not in the component and not as part of an
> external object (like a tree model or a tree state). Should the
> backing beans store all the component specific information that stores
> data state, then the component tree is entirely not needed at all in a
> facelets environment.
> 
> See the following blog posts on going stateless:
> http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html
> http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html
> 
>>
>> Thanks.
>> --
>> View this message in context:
>> http://www.nabble.com/Philosophy-of-JSF-tf3772976.html#a10667738
>> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Philosophy-of-JSF-tf3772976.html#a10669147
Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: Philosophy of JSF

[Andrew Robinson <an...@gmail.com>]

Answers below (in-line). Please (anyone) feel free to correct any
mistakes I may have made...

On 5/17/07, lightbulb432 <ve...@hotmail.com> wrote:
>
> Somewhere in the months of learning and reading about JSF, I've lost touch
> with the basic concepts. Could somebody please explain why state for the
> view needs to be stored to begin with?

Well, with facelets, it doesn't really

> Could JSF be used in a stateless
> manner, or is that not how it is meant and designed to be used?

For the most part yes, but probably not desirable

> How do alternatives to JSF like Struts, Struts2, and others handle the
> concept of view state?

The don't, they have no component state

> I realize this is a total newbie question, but I hope you can explain in
> clear and thorough terms the concept of JSF as it relates to other
> frameworks out there – I can't conceptualize it easily, even after having
> played around with it for a little while.

JSF is built around components and component states. The idea is to
produce a web framework that acts much like a GUI framework like
Swing, but for the web. The component tree is like the AWT/Swing
component instances that make up a JFrame (for example). Each
component in a JFrame has properties. Those properties could be simple
ones, like foreground color, or complex ones like a tree model.

When a JSF view is rendered, the view is serialized down into its
state. The actual components are not stored, but their state is. This
is done by calling componet.saveState recursively on all components in
the component tree that are not transient.

Now, JSP requires a "heavy" implementation of the view state because
once the JSP tags build the components, there is no way to rebuild the
same component tree during the restore view phase on the next request.
It therefore needs to store everything about the components, including
all the value bindings and other attributes.

Facelets on the other hand uses an XML representation of the view that
allows the FaceletsViewHandler to create a component tree directly
from that XML, skipping the tag->component "phase". It has the
information to reset all the value bindings an other attributes on
each request and do so reliably.

Unfortunately for us facelet users, the view state is still saved as
per needed by JSP and therefore is not optimized for a technology like
facelets (hopefully JSF 2.0 will continue improving this).

Also, some component developers choose to save state like if a tree
node is expanded or not in the component and not as part of an
external object (like a tree model or a tree state). Should the
backing beans store all the component specific information that stores
data state, then the component tree is entirely not needed at all in a
facelets environment.

See the following blog posts on going stateless:
http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html
http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html

>
> Thanks.
> --
> View this message in context: http://www.nabble.com/Philosophy-of-JSF-tf3772976.html#a10667738
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>

Re: Philosophy of JSF

[Werner Punz <we...@gmail.com>]

Ted Husted schrieb:

> 
> For the most part, they don't have the concept of View State. If a
> control uses data that is not in the post, and the page needs to be
> presented again (because, say, validation failed), then an
> action-based framework will go and fetch the control data again. (In
> fact, Struts 2 has a special "prepare" method that is used to create
> (or recreate) "View State".) If the data in question is semi-static (a
> drop down list), and the query is cached, then it's a memory-to-memory
> transfer, otherwise, we have to hit the database again. The trade-off
> having JSF automatically process the encoded view state field (whether
> you need it again or not).
> 
Besides that you cannot really do a decent server side based event
processing on top of something like html without some kind of state
saving, it all comes down to the problem you described, do you want to
hit the db and store or traverse additional data manually or have the
framework doing it for you.

The classical example is the savestate component which pushes bean
values over request boundaries without the html inherent hidden field
cascades normally needed in every form on the page. All is done via the
save stating, which serializes the bean at the end of the request and
deserializes it before applying request values.

Re: Philosophy of JSF

[Ted Husted <hu...@apache.org>]

On 5/17/07, lightbulb432 <ve...@hotmail.com> wrote:
> How do alternatives to JSF like Struts, Struts2, and others handle the
> concept of view state?

For the most part, they don't have the concept of View State. If a
control uses data that is not in the post, and the page needs to be
presented again (because, say, validation failed), then an
action-based framework will go and fetch the control data again. (In
fact, Struts 2 has a special "prepare" method that is used to create
(or recreate) "View State".) If the data in question is semi-static (a
drop down list), and the query is cached, then it's a memory-to-memory
transfer, otherwise, we have to hit the database again. The trade-off
having JSF automatically process the encoded view state field (whether
you need it again or not).

-Ted.