You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Travis Reeder <tr...@gmail.com> on 2005/11/30 23:16:52 UTC
Re: JSF flaw
That is great to hear about the window id! I brought this exact thing
up a long time ago calling it windowScope or frameScope. It's one of
those must have things like the back button support.
Travis
On 10/9/05, Simon Kitching <sk...@obsidium.com> wrote:
> Just for anyone who might be interested, I was reading the JSF 1.2 spec
> today, and it has created a thing called a "window id" in addition to a
> "view id". This might be aimed at better support for exactly this sort
> of problem. Of course that spec isn't finalised yet (nor implemented).
>
> Andrew robinson wrote:
> > What is your state saving method? You probably have your state saved to
> > the server, it will only remember the state from the last post, and
> > therefore you will not be able to post from past pages. Best thing to do
> > is set your state saving method to client.
> >
> > -Andrew
> >
> > On 10/9/05, *Dave* <javaone9@yahoo.com <ma...@yahoo.com>> wrote:
> >
> > Hello,
> > I have a problem with JSF which seems to be a JSF flaw. Any idea is
> > appreciated.
> >
> > suppose I have JSF page A, when user click a link in page A, a page
> > B is opened in a new window. At this moment, the server side JSF
> > view root is page B. If user click submit button in page A, all form
> > data(not submitted yet) will be lost in page A because JSF think it
> > is an initial request and goes to render phase immediately(no model
> > update). From user's view, it is a post back to submit data.
> >
> > Popping up a new window is very common . Any idea to solve this
> > problem? or It is JSF, no way. Thanks!
> >
> > Dave
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> > Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
> > <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.com/unlimited/>
> >
> >
> >
>
>
Re: JSF flaw
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Mike,
yes, of course I meant transient - have been thinking about the
immediate attribute too much the last week, as I have been giving a
course and that was the single least understood concept of JSF ;)
and no, saveState/restoreState don't need to check - look into all the
standard components, none does it.
regards,
Martin
On 12/2/05, Mike Kienenberger <mk...@gmail.com> wrote:
> That's exactly the code I was looking at, assuming you meant
> "transient" rather than "immediate," which is what got me wondering.
>
> Up to this point, I always thought it was the responsibility of
> saveState/restoreState to check transient, but now I'm thinking that
> I've been doing it wrong.
>
> Thanks!
>
> On 12/2/05, Martin Marinschek <ma...@gmail.com> wrote:
> > On lookup, I see that there is nothing. I do remember a discussion
> > about this at some time, though. But that's a long time ago, maybe I
> > am wrong.
> >
> > You don't need to change behaviour - if you look into UIComponentBase,
> > you see that based on the value of immediate saveState/restoreState
> > will be called or not.
> >
> > regards,
> >
> > Martin
> >
> >
> >
> > On 12/1/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > > On 12/1/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > > @1: yes, I have sometimes thought about this as well - saying that a
> > > > certain part of the page is exempt from state saving might be nice.
> > > > There was this transient attribute once for components, but hasn't it
> > > > been deprecated?
> > >
> > > I don't see anything transient being deprecated. One thing I wonder
> > > about is whether the saveState/restoreState method code needs to
> > > explicitly change behavior based on the value of transient, or if it's
> > > always the responsibility of the caller to check the transient value.
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: JSF flaw
Posted by Mike Kienenberger <mk...@gmail.com>.
That's exactly the code I was looking at, assuming you meant
"transient" rather than "immediate," which is what got me wondering.
Up to this point, I always thought it was the responsibility of
saveState/restoreState to check transient, but now I'm thinking that
I've been doing it wrong.
Thanks!
On 12/2/05, Martin Marinschek <ma...@gmail.com> wrote:
> On lookup, I see that there is nothing. I do remember a discussion
> about this at some time, though. But that's a long time ago, maybe I
> am wrong.
>
> You don't need to change behaviour - if you look into UIComponentBase,
> you see that based on the value of immediate saveState/restoreState
> will be called or not.
>
> regards,
>
> Martin
>
>
>
> On 12/1/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > On 12/1/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > @1: yes, I have sometimes thought about this as well - saying that a
> > > certain part of the page is exempt from state saving might be nice.
> > > There was this transient attribute once for components, but hasn't it
> > > been deprecated?
> >
> > I don't see anything transient being deprecated. One thing I wonder
> > about is whether the saveState/restoreState method code needs to
> > explicitly change behavior based on the value of transient, or if it's
> > always the responsibility of the caller to check the transient value.
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: JSF flaw
Posted by Martin Marinschek <ma...@gmail.com>.
On lookup, I see that there is nothing. I do remember a discussion
about this at some time, though. But that's a long time ago, maybe I
am wrong.
You don't need to change behaviour - if you look into UIComponentBase,
you see that based on the value of immediate saveState/restoreState
will be called or not.
regards,
Martin
On 12/1/05, Mike Kienenberger <mk...@gmail.com> wrote:
> On 12/1/05, Martin Marinschek <ma...@gmail.com> wrote:
> > @1: yes, I have sometimes thought about this as well - saying that a
> > certain part of the page is exempt from state saving might be nice.
> > There was this transient attribute once for components, but hasn't it
> > been deprecated?
>
> I don't see anything transient being deprecated. One thing I wonder
> about is whether the saveState/restoreState method code needs to
> explicitly change behavior based on the value of transient, or if it's
> always the responsibility of the caller to check the transient value.
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: JSF flaw
Posted by Mike Kienenberger <mk...@gmail.com>.
On 12/1/05, Martin Marinschek <ma...@gmail.com> wrote:
> @1: yes, I have sometimes thought about this as well - saying that a
> certain part of the page is exempt from state saving might be nice.
> There was this transient attribute once for components, but hasn't it
> been deprecated?
I don't see anything transient being deprecated. One thing I wonder
about is whether the saveState/restoreState method code needs to
explicitly change behavior based on the value of transient, or if it's
always the responsibility of the caller to check the transient value.
Re: JSF flaw
Posted by Martin Marinschek <ma...@gmail.com>.
@1: yes, I have sometimes thought about this as well - saying that a
certain part of the page is exempt from state saving might be nice.
There was this transient attribute once for components, but hasn't it
been deprecated?
@2: Yes, but there is always component binding for such things, right?
regards,
Martin
On 12/1/05, Yee CN <ye...@streamyx.com> wrote:
> As a reference in ASP.NET state saving is always at the client - there is no
> option to save in server. Somehow M'soft managed to get the framework
> running at very decent speed. I am wondering whether we can achieve some of
> the efficiencies in ASP.NET.
>
> Some of the 'good' things that I observed are:
> - The viewstate of a component is not saved automatically, you need to
> configured explicitly whether a component is to participate in ViewState.
>
> - Value binding is not offered, which means component values are set
> programmatically. However it also means that programmer has much more
> control over the binding of data to the components. For example a dataTable
> will NOT be regenerated twice on every postback. In asp.net you can
> configure to save its viewstate and forget about it altogether until the
> user click something that requires refreshing the table data.
>
> I have contemplated forging value binding altogether and adopt a more
> ASP.NET style of doing JSF. I like to hear what you Guru have to say about
> it.
>
> Regards,
> Yee
>
> -----Original Message-----
> From: Travis Reeder [mailto:treeder@gmail.com]
> Sent: Thursday, 1 December 2005 6:17 AM
> To: MyFaces Discussion
> Subject: Re: JSF flaw
>
> That is great to hear about the window id! I brought this exact thing
> up a long time ago calling it windowScope or frameScope. It's one of
> those must have things like the back button support.
>
> Travis
>
> On 10/9/05, Simon Kitching <sk...@obsidium.com> wrote:
> > Just for anyone who might be interested, I was reading the JSF 1.2 spec
> > today, and it has created a thing called a "window id" in addition to a
> > "view id". This might be aimed at better support for exactly this sort
> > of problem. Of course that spec isn't finalised yet (nor implemented).
> >
> > Andrew robinson wrote:
> > > What is your state saving method? You probably have your state saved to
> > > the server, it will only remember the state from the last post, and
> > > therefore you will not be able to post from past pages. Best thing to do
> > > is set your state saving method to client.
> > >
> > > -Andrew
> > >
> > > On 10/9/05, *Dave* <javaone9@yahoo.com <ma...@yahoo.com>>
> wrote:
> > >
> > > Hello,
> > > I have a problem with JSF which seems to be a JSF flaw. Any idea is
> > > appreciated.
> > >
> > > suppose I have JSF page A, when user click a link in page A, a page
> > > B is opened in a new window. At this moment, the server side JSF
> > > view root is page B. If user click submit button in page A, all form
> > > data(not submitted yet) will be lost in page A because JSF think it
> > > is an initial request and goes to render phase immediately(no model
> > > update). From user's view, it is a post back to submit data.
> > >
> > > Popping up a new window is very common . Any idea to solve this
> > > problem? or It is JSF, no way. Thanks!
> > >
> > > Dave
> > >
> > >
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > > Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
> > >
> <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.c
> om/unlimited/>
> > >
> > >
> > >
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
RE: JSF flaw
Posted by Yee CN <ye...@streamyx.com>.
As a reference in ASP.NET state saving is always at the client - there is no
option to save in server. Somehow M'soft managed to get the framework
running at very decent speed. I am wondering whether we can achieve some of
the efficiencies in ASP.NET.
Some of the 'good' things that I observed are:
- The viewstate of a component is not saved automatically, you need to
configured explicitly whether a component is to participate in ViewState.
- Value binding is not offered, which means component values are set
programmatically. However it also means that programmer has much more
control over the binding of data to the components. For example a dataTable
will NOT be regenerated twice on every postback. In asp.net you can
configure to save its viewstate and forget about it altogether until the
user click something that requires refreshing the table data.
I have contemplated forging value binding altogether and adopt a more
ASP.NET style of doing JSF. I like to hear what you Guru have to say about
it.
Regards,
Yee
-----Original Message-----
From: Travis Reeder [mailto:treeder@gmail.com]
Sent: Thursday, 1 December 2005 6:17 AM
To: MyFaces Discussion
Subject: Re: JSF flaw
That is great to hear about the window id! I brought this exact thing
up a long time ago calling it windowScope or frameScope. It's one of
those must have things like the back button support.
Travis
On 10/9/05, Simon Kitching <sk...@obsidium.com> wrote:
> Just for anyone who might be interested, I was reading the JSF 1.2 spec
> today, and it has created a thing called a "window id" in addition to a
> "view id". This might be aimed at better support for exactly this sort
> of problem. Of course that spec isn't finalised yet (nor implemented).
>
> Andrew robinson wrote:
> > What is your state saving method? You probably have your state saved to
> > the server, it will only remember the state from the last post, and
> > therefore you will not be able to post from past pages. Best thing to do
> > is set your state saving method to client.
> >
> > -Andrew
> >
> > On 10/9/05, *Dave* <javaone9@yahoo.com <ma...@yahoo.com>>
wrote:
> >
> > Hello,
> > I have a problem with JSF which seems to be a JSF flaw. Any idea is
> > appreciated.
> >
> > suppose I have JSF page A, when user click a link in page A, a page
> > B is opened in a new window. At this moment, the server side JSF
> > view root is page B. If user click submit button in page A, all form
> > data(not submitted yet) will be lost in page A because JSF think it
> > is an initial request and goes to render phase immediately(no model
> > update). From user's view, it is a post back to submit data.
> >
> > Popping up a new window is very common . Any idea to solve this
> > problem? or It is JSF, no way. Thanks!
> >
> > Dave
> >
> >
> >
> >
> >
> >
------------------------------------------------------------------------
> > Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
> >
<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.c
om/unlimited/>
> >
> >
> >
>
>