[JSF] Client state

[Michael Jouravlev <jm...@gmail.com>]

Can JSF store component state completely on client, that is, using
Javascript objects? I could not find anything besides _viewstate-like
juggling between client and server.

I think it would be nice if an application could try to save viewstate
on client, and if Javascript were turned off, the viewstate would be
submitted to server and stored there in the session.

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] Client state

["Frank W. Zammetti" <fz...@omnytex.com>]

> On 1/23/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> Yes, that's correct... with every document loaded into the
>> browser, anything that existed before is wiped out.  I'm not aware of
>> any
>> way around that (and it sure sounds like a security problem if there
>> was).
>> A hidden frame is the typical solution in such cases...
>
> So, there are ways besides Ajax? This is good to hear.

Yep, but they tend to be flowned upon by most.  For whatever reason,
frames have gotten a really bad rap over the years.  The three options I
am aware of are frames, hidden fields and URL rewriting, and AJAX.

>> Of course, now
>> you can do it with AJAX... you load one page in the beginning that
>> contains your AJAX code and a single <div>... every request you make to
>> the server goes through an XMLHttpRequest object, and the results are
>> stuck into that <div>... this can be a whole page, so in a sense your
>> creating a browser inside a browser :)
>
> Yeah, I know, I do that myself. I was curious about independent pages.
> This hidden frame thing... Can it work while actual page content is
> changed *and* page address is updated in the address line?

Frames are in essence separate browser instances crammed together... well,
not *quite*, I suppose it's more like multiple tabs in a browser where the
content of each tab is shown together.  So, if you change the content of
one, even if its redirecting to another URL, the content of the other is
completely unaffected.

With frames, the URL you see in the address bar rarely corresponds to
anything useful...  That's one of the reasons people started to dislike
frames... it tended to make bookmarking more difficult, i.e., if you have
two frames, they each build up their own history, so if you try and
bookmark a page, you may have content in one frame that doesn't correspond
to what's in the other (think of a menu frame that changes according to
what page is dislpayed in the other frame)... usually what you bookmark
was the address of only a single frame anyway, and that doesn't really get
you what you want because then the content of the other is underfined (and
more than likely when you try and go back to the bookmark, it's not a
frameset any more because that's likely not what got bookmarked anyway).

To get around these problems requires you to write Javascript that can
properly be sure all frames involved are updated.  For instance, if you
click a link that brings you to page A in frame A, and you need page A1 in
frame A1 to be present, you would need to write code in page A that,
onLoad, loaded page A1 into frame A1 as well.  It allows you to do some
really cool things, but it's definitely more work and more error-prone.

> Michael.

Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] Client state

[Michael Jouravlev <jm...@gmail.com>]

On 1/23/06, Gary VanMatre <gv...@comcast.net> wrote:
> >From: Michael Jouravlev <jm...@gmail.com>
> >
> > Can JSF store component state completely on client, that is, using
> > Javascript objects? I could not find anything besides _viewstate-like
> > juggling between client and server.
> >
>
> JSF has an option to store the state of the page as a hidden field in the client.
> It's serialized objects that represent the component tree.  Client state is more
> for handling the browser back/ dirty page more than making state available for javascript.

This is what I call _viewstate juggling, hate it. Is it different from
similar thing in ASP.NET?

On 1/23/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Yes, that's correct... with every document loaded into the
> browser, anything that existed before is wiped out.  I'm not aware of any
> way around that (and it sure sounds like a security problem if there was).
> A hidden frame is the typical solution in such cases...

So, there are ways besides Ajax? This is good to hear.

> Of course, now
> you can do it with AJAX... you load one page in the beginning that
> contains your AJAX code and a single <div>... every request you make to
> the server goes through an XMLHttpRequest object, and the results are
> stuck into that <div>... this can be a whole page, so in a sense your
> creating a browser inside a browser :)

Yeah, I know, I do that myself. I was curious about independent pages.
This hidden frame thing... Can it work while actual page content is
changed *and* page address is updated in the address line?

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] Client state

["Frank W. Zammetti" <fz...@omnytex.com>]

On Mon, January 23, 2006 1:11 pm, Michael Jouravlev said:
> I am not a Javacript pro, yet ;) So, on a new request Javascript
> objects are gone? I see.

No problem :)  Yes, that's correct... with every document loaded into the
browser, anything that existed before is wiped out.  I'm not aware of any
way around that (and it sure sounds like a security problem if there was).
 A hidden frame is the typical solution in such cases... Of course, now
you can do it with AJAX... you load one page in the beginning that
contains your AJAX code and a single <div>... every request you make to
the server goes through an XMLHttpRequest object, and the results are
stuck into that <div>... this can be a whole page, so in a sense your
creating a browser inside a browser :)

> Michael.

Frank


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] Client state

[Michael Jouravlev <jm...@gmail.com>]

On 1/23/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> How could you possibly do this without using frames?  Every page request
> would obliviate any values you had stored.  Frames allows you to do this,
> I've done it many times with a hidden frame for client-side persistence,
> but  without frames, I don't see how this could be possible.

I am not a Javacript pro, yet ;) So, on a new request Javascript
objects are gone? I see.

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] Client state

["Frank W. Zammetti" <fz...@omnytex.com>]

How could you possibly do this without using frames?  Every page request
would obliviate any values you had stored.  Frames allows you to do this,
I've done it many times with a hidden frame for client-side persistence,
but  without frames, I don't see how this could be possible.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com

On Mon, January 23, 2006 12:55 pm, Michael Jouravlev said:
> Can JSF store component state completely on client, that is, using
> Javascript objects? I could not find anything besides _viewstate-like
> juggling between client and server.
>
> I think it would be nice if an application could try to save viewstate
> on client, and if Javascript were turned off, the viewstate would be
> submitted to server and stored there in the session.
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org