How is the performance/network traffic if using client-side saveState? I have a data model that has hundred of rows.
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
|
|
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
|
|
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
|
|
Ok I think there is a pattern to deal with http post problems,
however I have not dealt with it yet, others might be able
to help out
I think it is called somewhat like redirect after
post...
You also might have to check out the shale tokens
system it might help you out as well.
Sorry that I can not help you further.
Werner
Dave wrote:
> HI Werner,
> Thanks. <x:saveState> does not work in this case. Data saved using
> <saveState> are only available to the immediately following
> request.(post back in most cases).
>
> When user click Back, the browser says something like "not available
> since previous Form post, ask to refresh ". When use click Refresh, the
> data saved using <x:saveState> is not there any more because it is not
> immediate PO ST back.
>
> Dave
>
> */Werner Punz <[EMAIL PROTECTED]>/* wrote:
>
> Dave wrote:
> > When a backing bean is dependent on some data that are initialized
> > by previous page, it works fine normally. But if user click
> Back/Refresh
> > on browser, then the data is not available anymore to the backing
> bean.
> > This will result in NullPointerException because the data is null. How
> > to catch this issue and display a nice informative message, definitely
> > not Exception? Thanks for ideas. Dave
> >
> Sorry, my first answer was too short, to clarify things a little bit,
> &n bsp; the problem you encounter is due to the request scope, a bean declared
> in request scope lives only one request, now if you do a refresh you
> might lose
> important data along the way, the same goes for back.
>
> There are various solutions to the problem, the shale token stuff, I
> yet have to check out,
> but one solution is to use constructs w hich enable scopes bigger
> than request.
> One solution definitely would be to dump the backend bean into the
> session
> that way non traversed values would survive a refresh.
> Another one would be to use a lot of hidden fields, for the non
> visible data which has to survive
> which is a maintenance nightmare.
>
> Generally the cur rently possibly best approach would be to use
> x:saveState which stores
> beans for every page where a x:saveState tag is hit with the same
> declaration,
> or to use some kinde of dialog-scoping system:
>
> Following systems currently are available:
> Shale Dialog
> Seam
>
> Seam at least is rather heavy on the configuration side, but it
> looks like the most interesting
> approach in this area.
> Shale Dialog I have not looked into yet,
>
> the possible most lightweight approach however probably is
> x:saveState...
>
>
> ________ __________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mai l has the best spam protection around
> http://mail.yahoo.com
>
--
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.
