Mike Kienenberger wrote:
> If there's no such element, then you need to figure out why the
> element wasn't rendered.
I guess I wasn't clear. The components in question are in the generated
html. They are enabled and rendered and I can't find anything which
might potentially disable them via javascript. Certainly none of the
javascript that I input will do this and I don't see any in the
generated javascript which might either.
> If so, then you need to figure out why there's no submitted value when
> you submit the form -- perhaps submitting the form through some kind
> of proxy which logs all of the values would help.
OK, can you expand on this a bit? Do you mean some 'off the shelf' proxy
or something different? This is what I was getting at with the
PhaseListener, if I could see what was actually making it through, I
might be able to make some sense of what's going on.
Shane
>
> On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote:
>> 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
>>
>>
>
--
Shane
