Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff]

Mike Kienenberger wrote:
Set a breakpoint on the line generating the error.
Your first step is to determine which component value is missing from
your form submit.
According to the warning message, I can see that there are several text 
area components which are the problem (I assign the id's myself, so it 
is easy to verify which components it is complaining about). Most of the 
components in this page are generated in java code, and everything looks 
fine inside the factory method responsible for creating the text 
components (isDisabled()==false and isRendered()==true). Visually, 
immediately preceding an attempt to navigate away from this page via 
CommandLink, the fields in question are rendered and enabled. After 
that, I can see my request scoped backing bean get created once the link 
is clicked, but then the warnings are thrown and no navigation takes 
place. In terms of the generated html, it is a monsterous form with 
scads of disabled components, so it is not terribly easy to verify 
anything (my javascript skills suck as well, and that doesn't help). 
However, everything which gets disabled is set inside the java code 
which generates all of the content for the main panel so there ought not 
to be any issues with client side disables.

Once you know that, look at the generated html before the submit and
see if you can determine why the input for that component didn't
submit a value.
OK, what do I look for? I know the component id a priori, so I can 
isolate the 3 times which it occurs in the generated html. Once for the 
component name, once for the id, and once in some javascript tied to a 
sepeate button which does a spell check on the component in question 
(fwiw, the spell check function does not alter either the rendered or 
disabled state of the component and this issue crops up regardless of 
whether or not the spell check function is actually invoked)

I don't see anything in the html which suggests a problem, but I'm not 
altogether sure what to look for.

Shane


On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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