myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <andrew.rw.robin...@gmail.com>
Subject Re: HtmlRendererUtils - There should always be a submitted value
Date Fri, 08 Jun 2007 16:30:35 GMT
I would suggest debugging using an IDE at this point. Check out the
request header variables and then debug through the decode phase. I'd
recommend putting a break point on the warning.

On 6/8/07, Shane Petroff <shane@mayet.ca> wrote:
> Thanks for the suggestions,
>
> In reviewing the potential problems you listed below, I'm still stuck. I
> don't use ajax, so 1) shouldn't be an issue. I don't disable anything in
> javascript, so 2) shouldn't affect me. I only use a single form with
> everything inside it, so 3) shouldn't be an issue either. And I don't
> tie any EL to the disabled/rendered properties (only the value is
> mutated via EL expression).
>
> What do you think would be the best way to diagnose what is going wrong?
> I guess I could attach a PhaseListener and set a breakpoint in there to
> try to dissect what JSF thinks is wrong. I'm at a real loss here since I
> can't see anything wrong and the components which are causing the
> problem are used to capture the most important data I deal with. Thanks
> for the help
>
> Shane
>
>
> Andrew Robinson wrote:
> > That error occurs if there is no submitted value (I know - obvious
> > statement). Several things can cause it though. Here are the ones that
> > are most common IMO (P -> problem, S->Work-around/Solution)
> >
> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> > a4j:region around any component with ajaxSingle set to true to make
> > sure only that component is decoded and updated
> >
> > 2) (P) Element is removed from the client DOM or is disabled *and* the
> > JSF component is not disabled. (S) The client side enabled/rendered
> > should map to the server-side enabled/rendered. Therefore, if you are
> > disabling/removing components on the client, you need to make sure you
> > change the value on the server *before* the apply request values phase
> > (I think that is the correct phase of the error).
> >
> > 3) (P) Component is not inside of the form that was submitted. (S1) Do
> > not use multiple forms if doing so, instead use the subForm component
> > in the sandbox with one form or use one or multiple forms with
> > a4j:region if using A4J. (S2) make sure all components that implement
> > EditableValueHolder are placed inside of a UIForm component.
> >
> > 4) (P) The EL expression tied to the rendered or disabled property of
> > the component is not view specific and has been changed by another
> > view or is changed before the apply request values phase. (S) Make
> > sure the rendered and/or disabled properties of components do not
> > change after rendering and before the apply request values.
> >
> > -Andrew
> >
> > On 6/5/07, Shane Petroff <shane@mayet.ca> wrote:
> >> Mike Kienenberger wrote:
> >> > I've also had it happen if the page changes and the facelets component
> >> > tree (or jsp page) is still cached somewhere.
> >> I'm almost completely certain it is not a caching issue (although it
> >> would be good to know if one could configure Tomcat not to cache
> >> anything, ever...) I've hand nuked caches several times and tried
> >> executing on a different machine (Tomcat running on the localhost in
> >> both cases).
> >>
> >> Shane
> >> >   Same idea -- the
> >> > expected submitted page elements do not match the actual submitted
> >> > page elements.
> >> >
> >> > On 6/5/07, Shane Petroff <shane@mayet.ca> wrote:
> >> >>
> >> >> I am having some strange navigation problems (once again...) and the
> >> >> only clue I have is the warning below.
> >> >>
> >> >> HtmlRendererUtils - There should always be a submitted value for an
> >> >> input if it is rendered, its form is submitted, and it is not
> >> disabled
> >> >> or read-only.
> >> >>
> >> >> In Googling the error message, it seems that the problem should be
> >> >> related to using Javascript to disable a control which my-faces
> >> expects
> >> >> to get a value from. The warning goes on to name the component in
> >> >> question, but there isn't any Javascript which touches these text
> >> areas,
> >> >> in fact there isn't any Javascript which disables anything. The
> >> >> components which are (in theory) causing the warning are certainly
> >> not
> >> >> disabled visually and for the most part they all contain text.
> >> They also
> >> >> happen to be created in Java code, so there is no jsp to post here.
> >> >>
> >> >> Can anyone give me a more detailed interpretation of what the warning
> >> >> means and when it arises?
> >> >>
> >> >> --
> >> >> Shane
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Mime
View raw message