myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Petroff <sh...@mayet.ca>
Subject Re: HtmlRendererUtils - There should always be a submitted value
Date Fri, 08 Jun 2007 21:32:51 GMT
Andrew Robinson wrote:
> 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.
At the point where the warning is logged, 
component.getClientId(FacesContext) doesn't return a value contained in 
the request parameter map. While that's good for me to know, I'm 
guessing you guys already knew that :) What could cause the mismatch? 
Thanks in advance.

Shane
>
> 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
>>
>>
>


-- 
Shane


Mime
View raw message