You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Matthias Wessendorf <ma...@apache.org> on 2006/10/19 21:53:45 UTC

[Faces 1.2] RespStMgr.isPostback()

does anyone know, why the spec says for RespStateMgr.isPostback()


<snip>
For backwards compatability with implementations of
ResponseStateManager prior to JSF 1.2, a default implementation is
provided that consults the ExternalContext's requestParameterMap and
return true if its size is greater than 0.
</snip>

http://foo:port/myapp/random.faces?hack=me


I think we need (for myfaces) to override the method in the htmlRespStMgr..
to check against jsf_state || jsf_state_64 || jsf_view_param

-M

-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Scott O'Bryan <da...@gmail.com>.
Yeah, no doubt.

Matthias Wessendorf wrote:
> agreed with the *spec* point of you.
>
> but again, don't we need to ask the question that craig pointed out?
>
> Let's see how http://host/app/page.faces?foo=bar will
>
> bring fun to the isPostback() thing :)
>
> -M


Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Matthias Wessendorf <ma...@apache.org>.
agreed with the *spec* point of you.

but again, don't we need to ask the question that craig pointed out?

Let's see how http://host/app/page.faces?foo=bar will

bring fun to the isPostback() thing :)

-M

On 10/19/06, Scott O'Bryan <da...@gmail.com> wrote:
> Again, I'm somewhat concerned that if this method is documented to
> return true under the condition that the there is more then one
> parameter, we need to follow that spec.  I wonder if it's too late to
> eratta this to provide functionality rather then implementation in the doc.
>
> Scott
>
> Matthias Wessendorf wrote:
> > oh! not updated... :)
> >
> > I think we can/should override isPostback() in the html....Mgr
> > right?
> >
> > On 10/19/06, Bruno Aranda <br...@gmail.com> wrote:
> >> Mmm, I see, but these two jsf_state params are not present in the 1.1
> >> myfaces impl trunk, due to some changes Martin did to the
> >> HtmlResponseStateManager class a few days ago...
> >>
> >> Bruno
> >>
> >> On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> >> > jsf_state is myfaces. the param was simply forgotten by eg.
> >> > (or at least to specifiy the name of that state_save_param)
> >> >
> >> > javax.faces.ViewState was added to JSF 1.2.
> >> >
> >> > the default needs to check against the param_map_size > 0
> >> > (see javadoc)
> >> >
> >> > you cannot check only agains the javax.faces.ViewState for backward
> >> things.
> >> > So my suggestion was doing the check in our htmlRespMgr against all
> >> these three
> >> > (the two jsf_state guys from myfaces AND javax....)
> >> >
> >> > -M
> >> >
> >> > On 10/19/06, Bruno Aranda <br...@gmail.com> wrote:
> >> > > I see that the jsf_state || jsf_state_64 guys have disappeared from
> >> > > the current 1.1 myfaces implementation and replaced by the
> >> > > "javax.faces.ViewState", used by jsf 1.2, so I guess we can just
> >> > > implement as pointer in the jsf 1.2 javadocs (the default impl just
> >> > > checks for the "javax.faces.ViewState" param,
> >> > >
> >> > > Bruno
> >> > >
> >> > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> >> > > > no, I mean,
> >> > > >
> >> > > > why not just abstract isPost() method and letting the impls
> >> deal with that?
> >> > > >
> >> > > > best would be to check against view_param. ok, that disables
> >> jsf 1.1 from work
> >> > > > so looking for param_map size > 0 is ... ok.
> >> > > >
> >> > > > so each impl can check against view_param (that's jsf 1.2) and!
> >> what
> >> > > > they did for jsf 1.1
> >> > > > the jsf_state || jsf_state_64 in case of myfaces and
> >> com,sun.xxxx in case of RI
> >> > > >
> >> > > > I don't see why checking (inside the IMPL of myfaces) against
> >> > > > jsf_state || jsf_state_64 || jsf_view_param params will break
> >> jsf 1.2
> >> > > >
> >> > > > Since we don't touch the API RespStMgr. guy.
> >> > > >
> >> > > > -M
> >> > > >
> >> > > >
> >> > > > On 10/19/06, Scott O'Bryan <da...@gmail.com> wrote:
> >> > > > > I don't know why it's like this either, but unfortunately the
> >> snipit
> >> > > > > defines a very clear behavior.  Breaking this contract will
> >> break thew
> >> > > > > 1.2 spec.
> >> > > > >
> >> > > > > Scott
> >> > > > >
> >> > > > > Matthias Wessendorf wrote:
> >> > > > > > to fast...  :)
> >> > > > > >
> >> > > > > > my question was, why not as abstract method and let the
> >> details to the
> >> > > > > > impl...
> >> > > > > >
> >> > > > > > and we need to *overhaul* this in htmlResp....
> >> > > > > >
> >> > > > > > -M
> >> > > > > >
> >> > > > > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> >> > > > > >> does anyone know, why the spec says for
> >> RespStateMgr.isPostback()
> >> > > > > >>
> >> > > > > >>
> >> > > > > >> <snip>
> >> > > > > >> For backwards compatability with implementations of
> >> > > > > >> ResponseStateManager prior to JSF 1.2, a default
> >> implementation is
> >> > > > > >> provided that consults the ExternalContext's
> >> requestParameterMap and
> >> > > > > >> return true if its size is greater than 0.
> >> > > > > >> </snip>
> >> > > > > >>
> >> > > > > >> http://foo:port/myapp/random.faces?hack=me
> >> > > > > >>
> >> > > > > >>
> >> > > > > >> I think we need (for myfaces) to override the method in the
> >> > > > > >> htmlRespStMgr..
> >> > > > > >> to check against jsf_state || jsf_state_64 || jsf_view_param
> >> > > > > >>
> >> > > > > >> -M
> >> > > > > >>
> >> > > > > >> --
> >> > > > > >> Matthias Wessendorf
> >> > > > > >> http://tinyurl.com/fmywh
> >> > > > > >>
> >> > > > > >> further stuff:
> >> > > > > >> blog: http://jroller.com/page/mwessendorf
> >> > > > > >> mail: mwessendorf-at-gmail-dot-com
> >> > > > > >>
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Matthias Wessendorf
> >> > > > http://tinyurl.com/fmywh
> >> > > >
> >> > > > further stuff:
> >> > > > blog: http://jroller.com/page/mwessendorf
> >> > > > mail: mwessendorf-at-gmail-dot-com
> >> > > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Matthias Wessendorf
> >> > http://tinyurl.com/fmywh
> >> >
> >> > further stuff:
> >> > blog: http://jroller.com/page/mwessendorf
> >> > mail: mwessendorf-at-gmail-dot-com
> >> >
> >>
> >
> >
>
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Scott O'Bryan <da...@gmail.com>.
Again, I'm somewhat concerned that if this method is documented to 
return true under the condition that the there is more then one 
parameter, we need to follow that spec.  I wonder if it's too late to 
eratta this to provide functionality rather then implementation in the doc.

Scott

Matthias Wessendorf wrote:
> oh! not updated... :)
>
> I think we can/should override isPostback() in the html....Mgr
> right?
>
> On 10/19/06, Bruno Aranda <br...@gmail.com> wrote:
>> Mmm, I see, but these two jsf_state params are not present in the 1.1
>> myfaces impl trunk, due to some changes Martin did to the
>> HtmlResponseStateManager class a few days ago...
>>
>> Bruno
>>
>> On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
>> > jsf_state is myfaces. the param was simply forgotten by eg.
>> > (or at least to specifiy the name of that state_save_param)
>> >
>> > javax.faces.ViewState was added to JSF 1.2.
>> >
>> > the default needs to check against the param_map_size > 0
>> > (see javadoc)
>> >
>> > you cannot check only agains the javax.faces.ViewState for backward 
>> things.
>> > So my suggestion was doing the check in our htmlRespMgr against all 
>> these three
>> > (the two jsf_state guys from myfaces AND javax....)
>> >
>> > -M
>> >
>> > On 10/19/06, Bruno Aranda <br...@gmail.com> wrote:
>> > > I see that the jsf_state || jsf_state_64 guys have disappeared from
>> > > the current 1.1 myfaces implementation and replaced by the
>> > > "javax.faces.ViewState", used by jsf 1.2, so I guess we can just
>> > > implement as pointer in the jsf 1.2 javadocs (the default impl just
>> > > checks for the "javax.faces.ViewState" param,
>> > >
>> > > Bruno
>> > >
>> > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
>> > > > no, I mean,
>> > > >
>> > > > why not just abstract isPost() method and letting the impls 
>> deal with that?
>> > > >
>> > > > best would be to check against view_param. ok, that disables 
>> jsf 1.1 from work
>> > > > so looking for param_map size > 0 is ... ok.
>> > > >
>> > > > so each impl can check against view_param (that's jsf 1.2) and! 
>> what
>> > > > they did for jsf 1.1
>> > > > the jsf_state || jsf_state_64 in case of myfaces and 
>> com,sun.xxxx in case of RI
>> > > >
>> > > > I don't see why checking (inside the IMPL of myfaces) against
>> > > > jsf_state || jsf_state_64 || jsf_view_param params will break 
>> jsf 1.2
>> > > >
>> > > > Since we don't touch the API RespStMgr. guy.
>> > > >
>> > > > -M
>> > > >
>> > > >
>> > > > On 10/19/06, Scott O'Bryan <da...@gmail.com> wrote:
>> > > > > I don't know why it's like this either, but unfortunately the 
>> snipit
>> > > > > defines a very clear behavior.  Breaking this contract will 
>> break thew
>> > > > > 1.2 spec.
>> > > > >
>> > > > > Scott
>> > > > >
>> > > > > Matthias Wessendorf wrote:
>> > > > > > to fast...  :)
>> > > > > >
>> > > > > > my question was, why not as abstract method and let the 
>> details to the
>> > > > > > impl...
>> > > > > >
>> > > > > > and we need to *overhaul* this in htmlResp....
>> > > > > >
>> > > > > > -M
>> > > > > >
>> > > > > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
>> > > > > >> does anyone know, why the spec says for 
>> RespStateMgr.isPostback()
>> > > > > >>
>> > > > > >>
>> > > > > >> <snip>
>> > > > > >> For backwards compatability with implementations of
>> > > > > >> ResponseStateManager prior to JSF 1.2, a default 
>> implementation is
>> > > > > >> provided that consults the ExternalContext's 
>> requestParameterMap and
>> > > > > >> return true if its size is greater than 0.
>> > > > > >> </snip>
>> > > > > >>
>> > > > > >> http://foo:port/myapp/random.faces?hack=me
>> > > > > >>
>> > > > > >>
>> > > > > >> I think we need (for myfaces) to override the method in the
>> > > > > >> htmlRespStMgr..
>> > > > > >> to check against jsf_state || jsf_state_64 || jsf_view_param
>> > > > > >>
>> > > > > >> -M
>> > > > > >>
>> > > > > >> --
>> > > > > >> Matthias Wessendorf
>> > > > > >> http://tinyurl.com/fmywh
>> > > > > >>
>> > > > > >> further stuff:
>> > > > > >> blog: http://jroller.com/page/mwessendorf
>> > > > > >> mail: mwessendorf-at-gmail-dot-com
>> > > > > >>
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Matthias Wessendorf
>> > > > http://tinyurl.com/fmywh
>> > > >
>> > > > further stuff:
>> > > > blog: http://jroller.com/page/mwessendorf
>> > > > mail: mwessendorf-at-gmail-dot-com
>> > > >
>> > >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> > http://tinyurl.com/fmywh
>> >
>> > further stuff:
>> > blog: http://jroller.com/page/mwessendorf
>> > mail: mwessendorf-at-gmail-dot-com
>> >
>>
>
>


Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Matthias Wessendorf <ma...@apache.org>.
oh! not updated... :)

I think we can/should override isPostback() in the html....Mgr
right?

On 10/19/06, Bruno Aranda <br...@gmail.com> wrote:
> Mmm, I see, but these two jsf_state params are not present in the 1.1
> myfaces impl trunk, due to some changes Martin did to the
> HtmlResponseStateManager class a few days ago...
>
> Bruno
>
> On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > jsf_state is myfaces. the param was simply forgotten by eg.
> > (or at least to specifiy the name of that state_save_param)
> >
> > javax.faces.ViewState was added to JSF 1.2.
> >
> > the default needs to check against the param_map_size > 0
> > (see javadoc)
> >
> > you cannot check only agains the javax.faces.ViewState for backward things.
> > So my suggestion was doing the check in our htmlRespMgr against all these three
> > (the two jsf_state guys from myfaces AND javax....)
> >
> > -M
> >
> > On 10/19/06, Bruno Aranda <br...@gmail.com> wrote:
> > > I see that the jsf_state || jsf_state_64 guys have disappeared from
> > > the current 1.1 myfaces implementation and replaced by the
> > > "javax.faces.ViewState", used by jsf 1.2, so I guess we can just
> > > implement as pointer in the jsf 1.2 javadocs (the default impl just
> > > checks for the "javax.faces.ViewState" param,
> > >
> > > Bruno
> > >
> > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > no, I mean,
> > > >
> > > > why not just abstract isPost() method and letting the impls deal with that?
> > > >
> > > > best would be to check against view_param. ok, that disables jsf 1.1 from work
> > > > so looking for param_map size > 0 is ... ok.
> > > >
> > > > so each impl can check against view_param (that's jsf 1.2) and! what
> > > > they did for jsf 1.1
> > > > the jsf_state || jsf_state_64 in case of myfaces and com,sun.xxxx in case of RI
> > > >
> > > > I don't see why checking (inside the IMPL of myfaces) against
> > > > jsf_state || jsf_state_64 || jsf_view_param params will break jsf 1.2
> > > >
> > > > Since we don't touch the API RespStMgr. guy.
> > > >
> > > > -M
> > > >
> > > >
> > > > On 10/19/06, Scott O'Bryan <da...@gmail.com> wrote:
> > > > > I don't know why it's like this either, but unfortunately the snipit
> > > > > defines a very clear behavior.  Breaking this contract will break thew
> > > > > 1.2 spec.
> > > > >
> > > > > Scott
> > > > >
> > > > > Matthias Wessendorf wrote:
> > > > > > to fast...  :)
> > > > > >
> > > > > > my question was, why not as abstract method and let the details to the
> > > > > > impl...
> > > > > >
> > > > > > and we need to *overhaul* this in htmlResp....
> > > > > >
> > > > > > -M
> > > > > >
> > > > > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > > >> does anyone know, why the spec says for RespStateMgr.isPostback()
> > > > > >>
> > > > > >>
> > > > > >> <snip>
> > > > > >> For backwards compatability with implementations of
> > > > > >> ResponseStateManager prior to JSF 1.2, a default implementation is
> > > > > >> provided that consults the ExternalContext's requestParameterMap and
> > > > > >> return true if its size is greater than 0.
> > > > > >> </snip>
> > > > > >>
> > > > > >> http://foo:port/myapp/random.faces?hack=me
> > > > > >>
> > > > > >>
> > > > > >> I think we need (for myfaces) to override the method in the
> > > > > >> htmlRespStMgr..
> > > > > >> to check against jsf_state || jsf_state_64 || jsf_view_param
> > > > > >>
> > > > > >> -M
> > > > > >>
> > > > > >> --
> > > > > >> Matthias Wessendorf
> > > > > >> http://tinyurl.com/fmywh
> > > > > >>
> > > > > >> further stuff:
> > > > > >> blog: http://jroller.com/page/mwessendorf
> > > > > >> mail: mwessendorf-at-gmail-dot-com
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > > http://tinyurl.com/fmywh
> > > >
> > > > further stuff:
> > > > blog: http://jroller.com/page/mwessendorf
> > > > mail: mwessendorf-at-gmail-dot-com
> > > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Bruno Aranda <br...@gmail.com>.
Mmm, I see, but these two jsf_state params are not present in the 1.1
myfaces impl trunk, due to some changes Martin did to the
HtmlResponseStateManager class a few days ago...

Bruno

On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> jsf_state is myfaces. the param was simply forgotten by eg.
> (or at least to specifiy the name of that state_save_param)
>
> javax.faces.ViewState was added to JSF 1.2.
>
> the default needs to check against the param_map_size > 0
> (see javadoc)
>
> you cannot check only agains the javax.faces.ViewState for backward things.
> So my suggestion was doing the check in our htmlRespMgr against all these three
> (the two jsf_state guys from myfaces AND javax....)
>
> -M
>
> On 10/19/06, Bruno Aranda <br...@gmail.com> wrote:
> > I see that the jsf_state || jsf_state_64 guys have disappeared from
> > the current 1.1 myfaces implementation and replaced by the
> > "javax.faces.ViewState", used by jsf 1.2, so I guess we can just
> > implement as pointer in the jsf 1.2 javadocs (the default impl just
> > checks for the "javax.faces.ViewState" param,
> >
> > Bruno
> >
> > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > no, I mean,
> > >
> > > why not just abstract isPost() method and letting the impls deal with that?
> > >
> > > best would be to check against view_param. ok, that disables jsf 1.1 from work
> > > so looking for param_map size > 0 is ... ok.
> > >
> > > so each impl can check against view_param (that's jsf 1.2) and! what
> > > they did for jsf 1.1
> > > the jsf_state || jsf_state_64 in case of myfaces and com,sun.xxxx in case of RI
> > >
> > > I don't see why checking (inside the IMPL of myfaces) against
> > > jsf_state || jsf_state_64 || jsf_view_param params will break jsf 1.2
> > >
> > > Since we don't touch the API RespStMgr. guy.
> > >
> > > -M
> > >
> > >
> > > On 10/19/06, Scott O'Bryan <da...@gmail.com> wrote:
> > > > I don't know why it's like this either, but unfortunately the snipit
> > > > defines a very clear behavior.  Breaking this contract will break thew
> > > > 1.2 spec.
> > > >
> > > > Scott
> > > >
> > > > Matthias Wessendorf wrote:
> > > > > to fast...  :)
> > > > >
> > > > > my question was, why not as abstract method and let the details to the
> > > > > impl...
> > > > >
> > > > > and we need to *overhaul* this in htmlResp....
> > > > >
> > > > > -M
> > > > >
> > > > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > >> does anyone know, why the spec says for RespStateMgr.isPostback()
> > > > >>
> > > > >>
> > > > >> <snip>
> > > > >> For backwards compatability with implementations of
> > > > >> ResponseStateManager prior to JSF 1.2, a default implementation is
> > > > >> provided that consults the ExternalContext's requestParameterMap and
> > > > >> return true if its size is greater than 0.
> > > > >> </snip>
> > > > >>
> > > > >> http://foo:port/myapp/random.faces?hack=me
> > > > >>
> > > > >>
> > > > >> I think we need (for myfaces) to override the method in the
> > > > >> htmlRespStMgr..
> > > > >> to check against jsf_state || jsf_state_64 || jsf_view_param
> > > > >>
> > > > >> -M
> > > > >>
> > > > >> --
> > > > >> Matthias Wessendorf
> > > > >> http://tinyurl.com/fmywh
> > > > >>
> > > > >> further stuff:
> > > > >> blog: http://jroller.com/page/mwessendorf
> > > > >> mail: mwessendorf-at-gmail-dot-com
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > > http://tinyurl.com/fmywh
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Matthias Wessendorf <ma...@apache.org>.
jsf_state is myfaces. the param was simply forgotten by eg.
(or at least to specifiy the name of that state_save_param)

javax.faces.ViewState was added to JSF 1.2.

the default needs to check against the param_map_size > 0
(see javadoc)

you cannot check only agains the javax.faces.ViewState for backward things.
So my suggestion was doing the check in our htmlRespMgr against all these three
(the two jsf_state guys from myfaces AND javax....)

-M

On 10/19/06, Bruno Aranda <br...@gmail.com> wrote:
> I see that the jsf_state || jsf_state_64 guys have disappeared from
> the current 1.1 myfaces implementation and replaced by the
> "javax.faces.ViewState", used by jsf 1.2, so I guess we can just
> implement as pointer in the jsf 1.2 javadocs (the default impl just
> checks for the "javax.faces.ViewState" param,
>
> Bruno
>
> On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > no, I mean,
> >
> > why not just abstract isPost() method and letting the impls deal with that?
> >
> > best would be to check against view_param. ok, that disables jsf 1.1 from work
> > so looking for param_map size > 0 is ... ok.
> >
> > so each impl can check against view_param (that's jsf 1.2) and! what
> > they did for jsf 1.1
> > the jsf_state || jsf_state_64 in case of myfaces and com,sun.xxxx in case of RI
> >
> > I don't see why checking (inside the IMPL of myfaces) against
> > jsf_state || jsf_state_64 || jsf_view_param params will break jsf 1.2
> >
> > Since we don't touch the API RespStMgr. guy.
> >
> > -M
> >
> >
> > On 10/19/06, Scott O'Bryan <da...@gmail.com> wrote:
> > > I don't know why it's like this either, but unfortunately the snipit
> > > defines a very clear behavior.  Breaking this contract will break thew
> > > 1.2 spec.
> > >
> > > Scott
> > >
> > > Matthias Wessendorf wrote:
> > > > to fast...  :)
> > > >
> > > > my question was, why not as abstract method and let the details to the
> > > > impl...
> > > >
> > > > and we need to *overhaul* this in htmlResp....
> > > >
> > > > -M
> > > >
> > > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > >> does anyone know, why the spec says for RespStateMgr.isPostback()
> > > >>
> > > >>
> > > >> <snip>
> > > >> For backwards compatability with implementations of
> > > >> ResponseStateManager prior to JSF 1.2, a default implementation is
> > > >> provided that consults the ExternalContext's requestParameterMap and
> > > >> return true if its size is greater than 0.
> > > >> </snip>
> > > >>
> > > >> http://foo:port/myapp/random.faces?hack=me
> > > >>
> > > >>
> > > >> I think we need (for myfaces) to override the method in the
> > > >> htmlRespStMgr..
> > > >> to check against jsf_state || jsf_state_64 || jsf_view_param
> > > >>
> > > >> -M
> > > >>
> > > >> --
> > > >> Matthias Wessendorf
> > > >> http://tinyurl.com/fmywh
> > > >>
> > > >> further stuff:
> > > >> blog: http://jroller.com/page/mwessendorf
> > > >> mail: mwessendorf-at-gmail-dot-com
> > > >>
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Bruno Aranda <br...@gmail.com>.
I see that the jsf_state || jsf_state_64 guys have disappeared from
the current 1.1 myfaces implementation and replaced by the
"javax.faces.ViewState", used by jsf 1.2, so I guess we can just
implement as pointer in the jsf 1.2 javadocs (the default impl just
checks for the "javax.faces.ViewState" param,

Bruno

On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> no, I mean,
>
> why not just abstract isPost() method and letting the impls deal with that?
>
> best would be to check against view_param. ok, that disables jsf 1.1 from work
> so looking for param_map size > 0 is ... ok.
>
> so each impl can check against view_param (that's jsf 1.2) and! what
> they did for jsf 1.1
> the jsf_state || jsf_state_64 in case of myfaces and com,sun.xxxx in case of RI
>
> I don't see why checking (inside the IMPL of myfaces) against
> jsf_state || jsf_state_64 || jsf_view_param params will break jsf 1.2
>
> Since we don't touch the API RespStMgr. guy.
>
> -M
>
>
> On 10/19/06, Scott O'Bryan <da...@gmail.com> wrote:
> > I don't know why it's like this either, but unfortunately the snipit
> > defines a very clear behavior.  Breaking this contract will break thew
> > 1.2 spec.
> >
> > Scott
> >
> > Matthias Wessendorf wrote:
> > > to fast...  :)
> > >
> > > my question was, why not as abstract method and let the details to the
> > > impl...
> > >
> > > and we need to *overhaul* this in htmlResp....
> > >
> > > -M
> > >
> > > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > >> does anyone know, why the spec says for RespStateMgr.isPostback()
> > >>
> > >>
> > >> <snip>
> > >> For backwards compatability with implementations of
> > >> ResponseStateManager prior to JSF 1.2, a default implementation is
> > >> provided that consults the ExternalContext's requestParameterMap and
> > >> return true if its size is greater than 0.
> > >> </snip>
> > >>
> > >> http://foo:port/myapp/random.faces?hack=me
> > >>
> > >>
> > >> I think we need (for myfaces) to override the method in the
> > >> htmlRespStMgr..
> > >> to check against jsf_state || jsf_state_64 || jsf_view_param
> > >>
> > >> -M
> > >>
> > >> --
> > >> Matthias Wessendorf
> > >> http://tinyurl.com/fmywh
> > >>
> > >> further stuff:
> > >> blog: http://jroller.com/page/mwessendorf
> > >> mail: mwessendorf-at-gmail-dot-com
> > >>
> > >
> > >
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Craig McClanahan <cr...@apache.org>.
On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> no, I mean,
>
> why not just abstract isPost() method and letting the impls deal with
> that?


It looks like the JSF 1.2 EG used this pattern a lot, when they added new
methods to existing classes ... see for example FacesContext.getELContext().
Leaving the new method abstract would have caused old applications loading
this class to break, so they had to make the new methods concrete.  Why they
didn't just go ahead and implement the newly desired behavior is a question
for them, though.

Craig

Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Matthias Wessendorf <ma...@apache.org>.
no, I mean,

why not just abstract isPost() method and letting the impls deal with that?

best would be to check against view_param. ok, that disables jsf 1.1 from work
so looking for param_map size > 0 is ... ok.

so each impl can check against view_param (that's jsf 1.2) and! what
they did for jsf 1.1
the jsf_state || jsf_state_64 in case of myfaces and com,sun.xxxx in case of RI

I don't see why checking (inside the IMPL of myfaces) against
jsf_state || jsf_state_64 || jsf_view_param params will break jsf 1.2

Since we don't touch the API RespStMgr. guy.

-M


On 10/19/06, Scott O'Bryan <da...@gmail.com> wrote:
> I don't know why it's like this either, but unfortunately the snipit
> defines a very clear behavior.  Breaking this contract will break thew
> 1.2 spec.
>
> Scott
>
> Matthias Wessendorf wrote:
> > to fast...  :)
> >
> > my question was, why not as abstract method and let the details to the
> > impl...
> >
> > and we need to *overhaul* this in htmlResp....
> >
> > -M
> >
> > On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> >> does anyone know, why the spec says for RespStateMgr.isPostback()
> >>
> >>
> >> <snip>
> >> For backwards compatability with implementations of
> >> ResponseStateManager prior to JSF 1.2, a default implementation is
> >> provided that consults the ExternalContext's requestParameterMap and
> >> return true if its size is greater than 0.
> >> </snip>
> >>
> >> http://foo:port/myapp/random.faces?hack=me
> >>
> >>
> >> I think we need (for myfaces) to override the method in the
> >> htmlRespStMgr..
> >> to check against jsf_state || jsf_state_64 || jsf_view_param
> >>
> >> -M
> >>
> >> --
> >> Matthias Wessendorf
> >> http://tinyurl.com/fmywh
> >>
> >> further stuff:
> >> blog: http://jroller.com/page/mwessendorf
> >> mail: mwessendorf-at-gmail-dot-com
> >>
> >
> >
>
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Scott O'Bryan <da...@gmail.com>.
I don't know why it's like this either, but unfortunately the snipit 
defines a very clear behavior.  Breaking this contract will break thew 
1.2 spec.

Scott

Matthias Wessendorf wrote:
> to fast...  :)
>
> my question was, why not as abstract method and let the details to the 
> impl...
>
> and we need to *overhaul* this in htmlResp....
>
> -M
>
> On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
>> does anyone know, why the spec says for RespStateMgr.isPostback()
>>
>>
>> <snip>
>> For backwards compatability with implementations of
>> ResponseStateManager prior to JSF 1.2, a default implementation is
>> provided that consults the ExternalContext's requestParameterMap and
>> return true if its size is greater than 0.
>> </snip>
>>
>> http://foo:port/myapp/random.faces?hack=me
>>
>>
>> I think we need (for myfaces) to override the method in the 
>> htmlRespStMgr..
>> to check against jsf_state || jsf_state_64 || jsf_view_param
>>
>> -M
>>
>> -- 
>> Matthias Wessendorf
>> http://tinyurl.com/fmywh
>>
>> further stuff:
>> blog: http://jroller.com/page/mwessendorf
>> mail: mwessendorf-at-gmail-dot-com
>>
>
>


Re: [Faces 1.2] RespStMgr.isPostback()

Posted by Matthias Wessendorf <ma...@apache.org>.
to fast...  :)

my question was, why not as abstract method and let the details to the impl...

and we need to *overhaul* this in htmlResp....

-M

On 10/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> does anyone know, why the spec says for RespStateMgr.isPostback()
>
>
> <snip>
> For backwards compatability with implementations of
> ResponseStateManager prior to JSF 1.2, a default implementation is
> provided that consults the ExternalContext's requestParameterMap and
> return true if its size is greater than 0.
> </snip>
>
> http://foo:port/myapp/random.faces?hack=me
>
>
> I think we need (for myfaces) to override the method in the htmlRespStMgr..
> to check against jsf_state || jsf_state_64 || jsf_view_param
>
> -M
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com