On 27 Sep 2005, at 20:49, Ryan Wynn wrote:
How is the performance/network traffic if using client-side saveState? I have a data model that has hundred of rows.<x-tad-smaller>Met vriendelijke groeten,
Don't know. I have not done any peformance testing as I am really just evaluating jsf and myfaces. I think I would really consider design of the UI carefully. Unless I really was required to display tables or trees of hundreds of rows/nodes, I would make the UI such that only a subset of the information is presented to the user at any point. If there was such a requirement I would suggest that it should be changed - users will be happier.
My test application uses myfaces/spring/hibernate stack. The UI and hibernate are coupled such that the queries have limits and filters passed to them. The application is completely stateless - the jsf tree is saved on the client and all the beans are request scope.
Does anyone know of any performance results/thoughts comparing stateless versus stateful jsf apps?
My guess is that network traffic/marshalling (unmarshalling) of jsf-view still beats having a bunch of users with a session object as long as you keep the saveState stuff to a reasonable amount of data.
=======================================
Ryan Wynn
Websphere Portal Developer
IBM Business Consulting Services - Public Sector
Reston Office: 703-668-2478
Cell: 703-622-1977
[EMAIL PROTECTED]
Dave <[EMAIL PROTECTED]>
09/27/2005 01:46 PM
Please respond to
"MyFaces Discussion"
To
MyFaces Discussion <[email protected]>
cc
Subject
Re: How to deal with ugly issue - Back/Refresh
How is the performance/network traffic if using client-side saveState? I have a data model that has hundred of rows.
Ryan Wynn <[EMAIL PROTECTED]> wrote:
No, I use client that must be why. Thanks.
=======================================
Ryan Wynn
Websphere Portal Developer
IBM Business Consulting Services - Public Sector
Reston Office: 703-668-2478
Cell: 703-622-1977
[EMAIL PROTECTED]
Martin Marinschek <[EMAIL PROTECTED]>
09/27/2005 10:19 AM
Please respond to
"MyFaces Discussion"
To
MyFaces Discussion <[email protected]>
cc
Subject
Re: How to deal with ugly issue - Back/Refresh
It' s only relevant for server side state saving - do you use that?
regards,
Martin
On 9/27/05, Ryan Wynn <[EMAIL PROTECTED]> wrote:
How does this problem present itself? My app is stateless and uses saveState at some points. I have not had any problems with the back button.
=======================================
Ryan Wynn
Websphere Portal Developer
IBM Business Consulting Services - Public Sector
Reston Office: 703-668-2478
Cell: 703-622-1977
[EMAIL PROTECTED]
Werner Punz <[EMAIL PROTECTED]>
Sent by: news <[EMAIL PROTECTED]>
09/27/2005 02:20 AM
Please respond to
"MyFaces Discussion"
To
[email protected]
cc
Subject
Re: How to deal with ugly issue - Back/Refresh
<x-tad-smaller> Ok I think there is a pattern to deal with http post problems,</x-tad-smaller>
<x-tad-smaller> however I have not dealt with it yet, others might be able</x-tad-smaller>
<x-tad-smaller> to help out</x-tad-smaller>
<x-tad-smaller> I think it is called somewhat like redirect after</x-tad-smaller>
<x-tad-smaller> post...</x-tad-smaller>
<x-tad-smaller> You also might have to check out the shale tokens</x-tad-smaller>
<x-tad-smaller> system it might help you out as well.</x-tad-smaller>
<x-tad-smaller> Sorry that I can not help you further.</x-tad-smaller>
<x-tad-smaller> Werner</x-tad-smaller>
<x-tad-smaller> Dave wrote:</x-tad-smaller>
<x-tad-smaller> > HI Werner,</x-tad-smaller>
<x-tad-smaller> > Thanks. <x:saveState> does not work in this case. Data saved using</x-tad-smaller>
<x-tad-smaller> > <saveState> are only available to the immediately following</x-tad-smaller>
<x-tad-smaller> > request.(post back in most cases).</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > When user click Back, the browser says something like "not available</x-tad-smaller>
<x-tad-smaller> > since previous Form post, ask to refresh ". When use click Refresh, the</x-tad-smaller>
<x-tad-smaller> > data saved using <x:saveState> is not there any more because it is not</x-tad-smaller>
<x-tad-smaller> > immediate PO ST back.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Dave</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > */Werner Punz <</x-tad-smaller><x-tad-smaller>[EMAIL PROTECTED]</x-tad-smaller><x-tad-smaller>>/* wrote:</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Dave wrote:</x-tad-smaller>
<x-tad-smaller> > > When a backing bean is dependent on some data that are initialized</x-tad-smaller>
<x-tad-smaller> > > by previous page, it works fine normally. But if user click</x-tad-smaller>
<x-tad-smaller> > Back/Refresh</x-tad-smaller>
<x-tad-smaller> > > on browser, then the data is not available anymore to the backing</x-tad-smaller>
<x-tad-smaller> > bean.</x-tad-smaller>
<x-tad-smaller> > > This will result in NullPointerException because the data is null. How</x-tad-smaller>
<x-tad-smaller> > > to catch this issue and display a nice informative message, definitely</x-tad-smaller>
<x-tad-smaller> > > not Exception? Thanks for ideas. Dave</x-tad-smaller>
<x-tad-smaller> > ></x-tad-smaller>
<x-tad-smaller> > Sorry, my first answer was too short, to clarify things a little bit,</x-tad-smaller>
<x-tad-smaller> > &n bsp; the problem you encounter is due to the request scope, a bean declared</x-tad-smaller>
<x-tad-smaller> > in request scope lives only one request, now if you do a refresh you</x-tad-smaller>
<x-tad-smaller> > might lose</x-tad-smaller>
<x-tad-smaller> > important data along the way, the same goes for back.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > There are various solutions to the problem, the shale token stuff, I</x-tad-smaller>
<x-tad-smaller> > yet have to check out,</x-tad-smaller>
<x-tad-smaller> > but one solution is to use constructs w hich enable scopes bigger</x-tad-smaller>
<x-tad-smaller> > than request.</x-tad-smaller>
<x-tad-smaller> > One solution definitely would be to dump the backend bean into the</x-tad-smaller>
<x-tad-smaller> > session</x-tad-smaller>
<x-tad-smaller> > that way non traversed values would survive a refresh.</x-tad-smaller>
<x-tad-smaller> > Another one would be to use a lot of hidden fields, for the non</x-tad-smaller>
<x-tad-smaller> > visible data which has to survive</x-tad-smaller>
<x-tad-smaller> > which is a maintenance nightmare.</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Generally the cur rently possibly best approach would be to use</x-tad-smaller>
<x-tad-smaller> > x:saveState which stores</x-tad-smaller>
<x-tad-smaller> > beans for every page where a x:saveState tag is hit with the same</x-tad-smaller>
<x-tad-smaller> > declaration,</x-tad-smaller>
<x-tad-smaller> > or to use some kinde of dialog-scoping system:</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Following systems currently are available:</x-tad-smaller>
<x-tad-smaller> > Shale Dialog</x-tad-smaller>
<x-tad-smaller> > Seam</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > Seam at least is rather heavy on the configuration side, but it</x-tad-smaller>
<x-tad-smaller> > looks like the most interesting</x-tad-smaller>
<x-tad-smaller> > approach in this area.</x-tad-smaller>
<x-tad-smaller> > Shale Dialog I have not looked into yet,</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > the possible most lightweight approach however probably is</x-tad-smaller>
<x-tad-smaller> > x:saveState...</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
<x-tad-smaller> > ________ __________________________________________</x-tad-smaller>
<x-tad-smaller> > Do You Yahoo!?</x-tad-smaller>
<x-tad-smaller> > Tired of spam? Yahoo! Mai l has the best spam protection around</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller><x-tad-smaller>http://mail.yahoo.com</x-tad-smaller>
<x-tad-smaller> > </x-tad-smaller>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
Jan Dockx
</x-tad-smaller><x-tad-smaller>
PeopleWare NV - Head Office</x-tad-smaller><x-tad-smaller>
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66 </x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
PeopleWare NV - Branch Office Geel</x-tad-smaller><x-tad-smaller>
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25</x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
http://www.peopleware.be/
</x-tad-smaller><x-tad-smaller>http://www.mobileware.be/</x-tad-smaller>
