stateful/stateless JSF components

[Thomas DELHOMENIE <th...@wanadoo.fr>]

Hi,
I'm reading some articles that argue on the state saving method of the 
JSF components.
I don't really understand what they mean by talking about stateless and 
stateful, and what's the differences between these 2 methods.
Can somebody give me an little explanation ?

Thanks

Thomas

Re: design question for pushing DOM/XML to client, then display

[Yasushi Okubo <ya...@cabm.rutgers.edu>]

Andrew Robinson wrote:

>It really depends on what affect you are looking for.
>
>A: you want the user to download an XML file as a data file
>Answer 1:
>Write a servlet to build the XML document, set the attachment HTTP
>header to the XML file name and then write the XML document to the
>HttpServletResponse's output stream
>
>Answer 2:
>Write a custom UI component and renderer to spit XML back from your
>JSF page instead of HTML (there are no XML components that I am
>familiar with)
>
>B: you want the user to see an XSLT version of XML data:
>Answer: Really the same as A, but you have to put a reference in the
>XML to the XSLT on the server.
>
>Answer 3: nothing, facelets or JSF is able to spit XHTML back to the
>client, and XHTML is XML using an HTML DTD.
>
>Regarding AJAX: Yes AJAX uses XML, but it generally takes XHTML
>content from a server response an injects it into the page. I don't
>think this is what you are looking for.
>
>If you use the servlet, it will not have access to the faces context,
>so if you don't want to reload the data from the servlet that was
>already loaded via JSF, you will have to use a session scoped class
>that holds your data that you can access from a standard HttpSession
>object (then provide a helper class to load/retrieve the data using
>only servlet classes so that it can be used by both JSF and the
>servlet).
>
>There will be other ways, depending on exactly what you want to do.
>Anyone else with a better suggestion?
>
>On 3/3/06, Yasushi Okubo <ya...@cabm.rutgers.edu> wrote:
>  
>
>>Hi, experts
>>
>>I have a design question for how to push/display DOM/XML page on
>>client.  There is a table data stored in an array that is displayed with
>>datascroller.  I want to add a function to export  this data  in xml
>>format on client.
>>I  am thinking to convert an array to DOM  then use  write function to
>>covert it to XML file.
>>Could someone advise me the best way to display this xml file on the
>>client side without writing it as a file in the directory on the server
>>?  It sounds ajax can to it easily, but do not know how to do yet.
>>
>>Thanks,
>>yasushi
>>
>>
>>    
>>
Thanks Andrew for your feedback.   I appreciate your time and kindness.
yasushi

Re: design question for pushing DOM/XML to client, then display

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

It really depends on what affect you are looking for.

A: you want the user to download an XML file as a data file
Answer 1:
Write a servlet to build the XML document, set the attachment HTTP
header to the XML file name and then write the XML document to the
HttpServletResponse's output stream

Answer 2:
Write a custom UI component and renderer to spit XML back from your
JSF page instead of HTML (there are no XML components that I am
familiar with)

B: you want the user to see an XSLT version of XML data:
Answer: Really the same as A, but you have to put a reference in the
XML to the XSLT on the server.

Answer 3: nothing, facelets or JSF is able to spit XHTML back to the
client, and XHTML is XML using an HTML DTD.

Regarding AJAX: Yes AJAX uses XML, but it generally takes XHTML
content from a server response an injects it into the page. I don't
think this is what you are looking for.

If you use the servlet, it will not have access to the faces context,
so if you don't want to reload the data from the servlet that was
already loaded via JSF, you will have to use a session scoped class
that holds your data that you can access from a standard HttpSession
object (then provide a helper class to load/retrieve the data using
only servlet classes so that it can be used by both JSF and the
servlet).

There will be other ways, depending on exactly what you want to do.
Anyone else with a better suggestion?

On 3/3/06, Yasushi Okubo <ya...@cabm.rutgers.edu> wrote:
> Hi, experts
>
> I have a design question for how to push/display DOM/XML page on
> client.  There is a table data stored in an array that is displayed with
> datascroller.  I want to add a function to export  this data  in xml
> format on client.
> I  am thinking to convert an array to DOM  then use  write function to
> covert it to XML file.
> Could someone advise me the best way to display this xml file on the
> client side without writing it as a file in the directory on the server
> ?  It sounds ajax can to it easily, but do not know how to do yet.
>
> Thanks,
> yasushi
>
>

design question for pushing DOM/XML to client, then display

[Yasushi Okubo <ya...@cabm.rutgers.edu>]

Hi, experts

I have a design question for how to push/display DOM/XML page on 
client.  There is a table data stored in an array that is displayed with 
datascroller.  I want to add a function to export  this data  in xml 
format on client.
I  am thinking to convert an array to DOM  then use  write function to 
covert it to XML file. 
Could someone advise me the best way to display this xml file on the 
client side without writing it as a file in the directory on the server 
?  It sounds ajax can to it easily, but do not know how to do yet.

Thanks,
yasushi

When myFaces1.1.2 stable release available ?

[Adrien FOURES <af...@sigems.fr>]

Hello!

I want to know when i can download the 1.1.2 myfaces version?
I don't understand why a 1.1.3 snapshot version of myfaces is available, 
whereas the 1.1.2 stable release is not available? it is a over branch 
of project?

Thanks

Adrien

Re: stateful/stateless JSF components

[Adam Winer <aw...@gmail.com>]

I haven't broken down the performance/memory aspect out from overall
benchmarks.  I know that for size of the serialized, Base64'd, gzip'd
content, there's relatively little difference - the Facesbean approach
is maybe 10% better - especially because the arrays full of nulls end
up getting gzip'd down pretty well.  It'd be interesting to see how
the CPU and memory requirements differ in the two strategies

The big wins are first, code complexity (only minimal overrides of
saveState()), and second and more importantly, a central location for
adding optimizations, like I talk about in the second blog entry.  You
*could* implement delta support without a central state object, but
yeesh, what a nightmare!

There's also some significant benefits in this architecture in terms
of rendering performance;   we can retrieve a property far faster than
getAttributes().get("attrname"), which rapidly becomes one of the
major bottlenecks in rendering performance.

-- Adam


On 3/2/06, Werner Punz <we...@gmx.at> wrote:
> Adam I really love the idea of having a central state saving request
> singleton.
>
> Any numbers on how much performance and ram improvement you get with
> this method compared to the classical we do a simplified serialisation
> per component approach myfaces (and probably the ri as well) use.
>
>
>
>
> Adam Winer schrieb:
> > I've written a couple blog entries on this:
> >
> > http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html
> >
> > ... and this morning's:
> >
> > http://sfjsf.blogspot.com/2006/03/how-were-going-to-fix-jsf-state-saving.html
> >
> > Cheers,
> > Adam
> >
>
>

Re: stateful/stateless JSF components

[Werner Punz <we...@gmx.at>]

Adam I really love the idea of having a central state saving request 
singleton.

Any numbers on how much performance and ram improvement you get with 
this method compared to the classical we do a simplified serialisation 
per component approach myfaces (and probably the ri as well) use.




Adam Winer schrieb:
> I've written a couple blog entries on this:
> 
> http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html
> 
> ... and this morning's:
> 
> http://sfjsf.blogspot.com/2006/03/how-were-going-to-fix-jsf-state-saving.html
> 
> Cheers,
> Adam
> 

Re: stateful/stateless JSF components

[Adam Winer <aw...@gmail.com>]

I've written a couple blog entries on this:

http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html

... and this morning's:

http://sfjsf.blogspot.com/2006/03/how-were-going-to-fix-jsf-state-saving.html

Cheers,
Adam


On 3/2/06, Werner Punz <we...@gmx.at> wrote:
> Thomas DELHOMENIE schrieb:
> > Hi,
> > I'm reading some articles that argue on the state saving method of the
> > JSF components.
> > I don't really understand what they mean by talking about stateless and
> > stateful, and what's the differences between these 2 methods.
> > Can somebody give me an little explanation ?
> >
> I hope I get it right ;-)
> We are in a server side rendered environment here and try to emulate a
> rich client programming model.
> So we have a gui with a table, a tab control and a tree.
> In a normal ui all the components know their states, for instance which
> tab is chosen which part of the tree is open etc.. events are triggered
> which then are handled, all within the same context.
>
> Now we have this nasty thing html, which only knows how to render itself
> and basic form mechanisms no states of components, no events except
> simple form actions nothing,
>
> JSF and other component oriented frameworks try to eliminate this
> deficiency by adding another state layer on top, so that components know
> their states over the request cycle. This is done usually either by
> client side or server side state saving. Client side, lots of hidden
> fields, cookies or whatever are dragged along while the user interface
> changes, server side the components serialize their state away and then
> recycle it after the are gone over the request boundaray, load it and
> then during rendering reuse it to reflect user interface changes.
>
> the main problem with this approach (you probably read the Hookoom blog)
> is that it is very generic and a form can consist of hundreds of user
> interface elements all of them doing the serialisation thing. JSF
> already uses a lightweight serialisation approach, but for really high
> loads with lots of users this might still be way to problematic (have in
> mind that state saving is a burden on the server ramwise and also
> processor time wise), many of those components often do not need an
> expensive state saving cycle only some of them do.
>
>
> I hope that sums it up.
>
>

Re: AW: AW: stateful/stateless JSF components

[Werner Punz <we...@gmx.at>]

Matthias Kahlau schrieb:
>> And if it is true what you say then the load savings due to the client
>> side tab switching on the myfaces tabbed pane is even more, because you
>> stream the entire data only once instead of at hitting the tab every time.
> 
> You're right, but I think developers should make design decisions in favor
> of the user, if that's possible. And users with a slow network connection
> won't be happy if they have bad response times because of streaming the
> entire data of all tabs at once. Maybe users do not need the data of
> inactive tabs at all.
> 
> 
> Regards,
> 
> Matthias
> 

You are definitely right in this case, I dont know the component code
too much, I think it is probably not a bug but merely a shortcut from
the developer of this component, so that the code of the client side and
server side state saving does not differ too much.
That is my personal guess on this.

Re: AW: stateful/stateless JSF components

[Adam Winer <aw...@gmail.com>]

It's not quite that straightforward;  if each tab is showing
results of a different query, loading all the content up front
can result in a brutal load time for the first page.  You could
end up significantly increasing the load on the database tier.

There's lots of trade-offs to consider;  user performance,
app server scalability, database scalability, etc.

-- Adam


On 3/3/06, Werner Punz <we...@gmx.at> wrote:
> I dont know, I do not know the code of this component too much, anyway
> my point was that if you do client side tab switching you reduce server
> side load tremendously, either way in any case because with client side
> tab switching you trigger only one request at all.
>
> And I think adding some stateful behavior on the client generally can
> help to resolve a lot of problems, where the server nowadays still has
> to keep the load and state saving.
>
> And if it is true what you say then the load savings due to the client
> side tab switching on the myfaces tabbed pane is even more, because you
> stream the entire data only once instead of at hitting the tab every time.
>
>
>
>
> Matthias Kahlau schrieb:
> >> The classical example is a tabbed pane. With a server side rendered, you
> >> trigger a request at every tab change going through all the hoops, with
> >> a client side one, you have to do more loading upfront because you load
> >> all the components and values, but in the best case that is it, even if
> >> you switch the tabs 100 times you wont trigger any other request onto
> >> the server until save is hit.
> >
> > I think there's no difference between client-side and server-side
> > tab-switching of the MyFaces panelTabbedPane regarding the rendering
> > behaviour. I did expect that, when using server-side tab-switching, only the
> > active tab's content would be rendered, but looking at the HTML source
> > returned with the response showed me, that the content of all tabs is
> > contained. The contents of the inactive tabs are only made invisible by
> > using CSS.
> >
>
>

AW: AW: stateful/stateless JSF components

[Matthias Kahlau <mk...@web.de>]

> And if it is true what you say then the load savings due to the client
> side tab switching on the myfaces tabbed pane is even more, because you
> stream the entire data only once instead of at hitting the tab every time.

You're right, but I think developers should make design decisions in favor
of the user, if that's possible. And users with a slow network connection
won't be happy if they have bad response times because of streaming the
entire data of all tabs at once. Maybe users do not need the data of
inactive tabs at all.


Regards,

Matthias

> -----Ursprüngliche Nachricht-----
> Von: users-return-18128-mkahlau=web.de@myfaces.apache.org
> [mailto:users-return-18128-mkahlau=web.de@myfaces.apache.org]Im Auftrag
> von Werner Punz
> Gesendet: Freitag, 3. März 2006 12:30
> An: users@myfaces.apache.org
> Betreff: Re: AW: stateful/stateless JSF components
>
>
> I dont know, I do not know the code of this component too much, anyway
> my point was that if you do client side tab switching you reduce server
> side load tremendously, either way in any case because with client side
> tab switching you trigger only one request at all.
>
> And I think adding some stateful behavior on the client generally can
> help to resolve a lot of problems, where the server nowadays still has
> to keep the load and state saving.
>
> And if it is true what you say then the load savings due to the client
> side tab switching on the myfaces tabbed pane is even more, because you
> stream the entire data only once instead of at hitting the tab every time.
>
>
>
>
> Matthias Kahlau schrieb:
> >> The classical example is a tabbed pane. With a server side
> rendered, you
> >> trigger a request at every tab change going through all the hoops, with
> >> a client side one, you have to do more loading upfront because you load
> >> all the components and values, but in the best case that is it, even if
> >> you switch the tabs 100 times you wont trigger any other request onto
> >> the server until save is hit.
> >
> > I think there's no difference between client-side and server-side
> > tab-switching of the MyFaces panelTabbedPane regarding the rendering
> > behaviour. I did expect that, when using server-side
> tab-switching, only the
> > active tab's content would be rendered, but looking at the HTML source
> > returned with the response showed me, that the content of all tabs is
> > contained. The contents of the inactive tabs are only made invisible by
> > using CSS.
> >
>

Re: AW: stateful/stateless JSF components

[Werner Punz <we...@gmx.at>]

I dont know, I do not know the code of this component too much, anyway
my point was that if you do client side tab switching you reduce server
side load tremendously, either way in any case because with client side
tab switching you trigger only one request at all.

And I think adding some stateful behavior on the client generally can
help to resolve a lot of problems, where the server nowadays still has
to keep the load and state saving.

And if it is true what you say then the load savings due to the client
side tab switching on the myfaces tabbed pane is even more, because you
stream the entire data only once instead of at hitting the tab every time.




Matthias Kahlau schrieb:
>> The classical example is a tabbed pane. With a server side rendered, you
>> trigger a request at every tab change going through all the hoops, with
>> a client side one, you have to do more loading upfront because you load
>> all the components and values, but in the best case that is it, even if
>> you switch the tabs 100 times you wont trigger any other request onto
>> the server until save is hit.
> 
> I think there's no difference between client-side and server-side
> tab-switching of the MyFaces panelTabbedPane regarding the rendering
> behaviour. I did expect that, when using server-side tab-switching, only the
> active tab's content would be rendered, but looking at the HTML source
> returned with the response showed me, that the content of all tabs is
> contained. The contents of the inactive tabs are only made invisible by
> using CSS.
> 

AW: stateful/stateless JSF components

[Matthias Kahlau <mk...@web.de>]

> The classical example is a tabbed pane. With a server side rendered, you
> trigger a request at every tab change going through all the hoops, with
> a client side one, you have to do more loading upfront because you load
> all the components and values, but in the best case that is it, even if
> you switch the tabs 100 times you wont trigger any other request onto
> the server until save is hit.

I think there's no difference between client-side and server-side
tab-switching of the MyFaces panelTabbedPane regarding the rendering
behaviour. I did expect that, when using server-side tab-switching, only the
active tab's content would be rendered, but looking at the HTML source
returned with the response showed me, that the content of all tabs is
contained. The contents of the inactive tabs are only made invisible by
using CSS.

I use MyFaces Nightly 20051130 - maybe it's a problem with this version
only.


Regards,

Matthias

> -----Ursprüngliche Nachricht-----
> Von: users-return-18110-mkahlau=web.de@myfaces.apache.org
> [mailto:users-return-18110-mkahlau=web.de@myfaces.apache.org]Im Auftrag
> von Werner Punz
> Gesendet: Freitag, 3. März 2006 00:05
> An: users@myfaces.apache.org
> Betreff: Re: stateful/stateless JSF components
>
>
> Thomas DELHOMENIE schrieb:
> > Thank you Werner for your answer.
> >
> > If I understand what you say, a stateless component doesn't
> exist on the
> > server between 2 requests, that's right ?
> > And a component like h:outputText doesn't need to be stateful contrary
> > to a more complex component like a tree, am I right ?
> >
> well in certain situations it makes sense to have outputtext being state
> aware but in many not, and that is the real problem.
> In a classical rich client ui every component you use is state aware per
> default without any costs, but adding that layer to a server side
> rendered ui on top of a stateless protocol is a huge burden.
> The main problem is where do you draw the boundaries of having to have a
> stateful component and a non stateful.
>
> <h:outputText value="show this text"/> for sure can be non stateful
>
> with
> <h:outputText value="#{something dynamic}"/> you already might have a
> problem on your hands in some conditions.
>
> (output text probably is a bad example nevertheless lets leave it)
>
> So where do you draw the line and where can you draw it automatically.
> I am not sure if it is a good idea to go entirely stateless, you would
> lose the biggest advantage of jsf the programming model of a rich client
> ui that way, you would end up with a simplified Struts.
>
> I only see two solutions, give the users the opportunity to turn off the
> stateful behavior on component level, and the one Adam Winer was
> showing, improve the state saving on algorithmic level. (After reading
> Adams blog, I see a huge potential here)
>
> But at one point there always will be a tradeoff, but that tradeoff has
> to be done manually on non stateful frameworks as well, with myriads of
> hidden fields or session states kept around programmatically to keep the
> ui states.
>
> Becoming more dynamic on the client side also might be a reduction on
> the burden, not because you reduce states that way (after all the ajaxed
> and javascripted ui states have to survive a request cycle) but because
> you can reduce server side load tremendously that way.
> The classical example is a tabbed pane. With a server side rendered, you
> trigger a request at every tab change going through all the hoops, with
> a client side one, you have to do more loading upfront because you load
> all the components and values, but in the best case that is it, even if
> you switch the tabs 100 times you wont trigger any other request onto
> the server until save is hit.
>

Re: stateful/stateless JSF components

[Werner Punz <we...@gmx.at>]

Thomas DELHOMENIE schrieb:
> Thank you Werner for your answer.
> 
> If I understand what you say, a stateless component doesn't exist on the 
> server between 2 requests, that's right ?
> And a component like h:outputText doesn't need to be stateful contrary 
> to a more complex component like a tree, am I right ?
> 
well in certain situations it makes sense to have outputtext being state 
aware but in many not, and that is the real problem.
In a classical rich client ui every component you use is state aware per 
default without any costs, but adding that layer to a server side 
rendered ui on top of a stateless protocol is a huge burden.
The main problem is where do you draw the boundaries of having to have a 
stateful component and a non stateful.

<h:outputText value="show this text"/> for sure can be non stateful

with
<h:outputText value="#{something dynamic}"/> you already might have a 
problem on your hands in some conditions.

(output text probably is a bad example nevertheless lets leave it)

So where do you draw the line and where can you draw it automatically.
I am not sure if it is a good idea to go entirely stateless, you would 
lose the biggest advantage of jsf the programming model of a rich client 
ui that way, you would end up with a simplified Struts.

I only see two solutions, give the users the opportunity to turn off the 
stateful behavior on component level, and the one Adam Winer was 
showing, improve the state saving on algorithmic level. (After reading 
Adams blog, I see a huge potential here)

But at one point there always will be a tradeoff, but that tradeoff has 
to be done manually on non stateful frameworks as well, with myriads of 
hidden fields or session states kept around programmatically to keep the 
ui states.

Becoming more dynamic on the client side also might be a reduction on 
the burden, not because you reduce states that way (after all the ajaxed 
and javascripted ui states have to survive a request cycle) but because 
you can reduce server side load tremendously that way.
The classical example is a tabbed pane. With a server side rendered, you 
trigger a request at every tab change going through all the hoops, with 
a client side one, you have to do more loading upfront because you load 
all the components and values, but in the best case that is it, even if 
you switch the tabs 100 times you wont trigger any other request onto 
the server until save is hit.

Re: stateful/stateless JSF components

[Thomas DELHOMENIE <th...@wanadoo.fr>]

Thank you Werner for your answer.

If I understand what you say, a stateless component doesn't exist on the 
server between 2 requests, that's right ?
And a component like h:outputText doesn't need to be stateful contrary 
to a more complex component like a tree, am I right ?

Werner Punz a écrit :
> Thomas DELHOMENIE schrieb:
>> Hi,
>> I'm reading some articles that argue on the state saving method of 
>> the JSF components.
>> I don't really understand what they mean by talking about stateless 
>> and stateful, and what's the differences between these 2 methods.
>> Can somebody give me an little explanation ?
>>
> I hope I get it right ;-)
> We are in a server side rendered environment here and try to emulate a 
> rich client programming model.
> So we have a gui with a table, a tab control and a tree.
> In a normal ui all the components know their states, for instance 
> which tab is chosen which part of the tree is open etc.. events are 
> triggered which then are handled, all within the same context.
>
> Now we have this nasty thing html, which only knows how to render 
> itself and basic form mechanisms no states of components, no events 
> except simple form actions nothing,
>
> JSF and other component oriented frameworks try to eliminate this 
> deficiency by adding another state layer on top, so that components 
> know their states over the request cycle. This is done usually either 
> by client side or server side state saving. Client side, lots of 
> hidden fields, cookies or whatever are dragged along while the user 
> interface changes, server side the components serialize their state 
> away and then recycle it after the are gone over the request 
> boundaray, load it and then during rendering reuse it to reflect user 
> interface changes.
>
> the main problem with this approach (you probably read the Hookoom 
> blog) is that it is very generic and a form can consist of hundreds of 
> user interface elements all of them doing the serialisation thing. JSF 
> already uses a lightweight serialisation approach, but for really high 
> loads with lots of users this might still be way to problematic (have 
> in mind that state saving is a burden on the server ramwise and also 
> processor time wise), many of those components often do not need an 
> expensive state saving cycle only some of them do.
>
>
> I hope that sums it up.
>
>
>

Re: stateful/stateless JSF components

[Werner Punz <we...@gmx.at>]

Thomas DELHOMENIE schrieb:
> Hi,
> I'm reading some articles that argue on the state saving method of the 
> JSF components.
> I don't really understand what they mean by talking about stateless and 
> stateful, and what's the differences between these 2 methods.
> Can somebody give me an little explanation ?
> 
I hope I get it right ;-)
We are in a server side rendered environment here and try to emulate a 
rich client programming model.
So we have a gui with a table, a tab control and a tree.
In a normal ui all the components know their states, for instance which 
tab is chosen which part of the tree is open etc.. events are triggered 
which then are handled, all within the same context.

Now we have this nasty thing html, which only knows how to render itself 
and basic form mechanisms no states of components, no events except 
simple form actions nothing,

JSF and other component oriented frameworks try to eliminate this 
deficiency by adding another state layer on top, so that components know 
their states over the request cycle. This is done usually either by 
client side or server side state saving. Client side, lots of hidden 
fields, cookies or whatever are dragged along while the user interface 
changes, server side the components serialize their state away and then 
recycle it after the are gone over the request boundaray, load it and 
then during rendering reuse it to reflect user interface changes.

the main problem with this approach (you probably read the Hookoom blog) 
is that it is very generic and a form can consist of hundreds of user 
interface elements all of them doing the serialisation thing. JSF 
already uses a lightweight serialisation approach, but for really high 
loads with lots of users this might still be way to problematic (have in 
mind that state saving is a burden on the server ramwise and also 
processor time wise), many of those components often do not need an 
expensive state saving cycle only some of them do.


I hope that sums it up.