myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: HtmlRendererUtils - There should always be a submitted value
Date Fri, 08 Jun 2007 21:41:34 GMT
The cause is probably that

mainForm:_id30:_id33:editableAnecdotalComment548806536 !=
mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536

So the question is why does _id30 get translated to contentPanel_1153
and _id33 get translated to contentPanel_1344 on submit?

It looks like you've went from automatically generated ids for these
components to explicitly-set (plus some random number) ids for these
components.


On 6/8/07, Shane Petroff <shane@mayet.ca> wrote:
> 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.

On 6/8/07, Shane Petroff <shane@mayet.ca> wrote:
> Mike Kienenberger wrote:
> > Another way would be to set a breakpoint somewhere and
> > check what's in the request parameter map for the current request.
> OK, what I've done is to add a Servlet Filter to the mix (in looking at
> example code, it seems that the filter may come in handy down the line).
> What I figured was that the filter will get processed early, and is
> therefore a good place to set a breakpoint to examine request
> parameters. (Although as I write this I'm wondering about filter
> ordering and the Extensions filter) It seems as though the component
> id's do not correspond to the request parameters which make it through
> to the filter. In the generated html I have
>
> id="mainForm:_id30:_id33:editableAnecdotalComment548806536"
>
> and in the request I have
>
> param:
> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536,
>
> value: [Ljava.lang.String;@1fff293
>
> The "editableAnecdotalComment548806536" portion is the ID that I set.
> All of the _idXX components get mapped to different parameter names
> (contentPanel happens to be the name I assigned to the main panel on the
> jsp page whose binding attribute I use to build up dynamic content).
> Since all component id's get mapped, I don't yet see a problem. I
> haven't tried stepping into anything outside my own code yet, but I
> guess that's next on the list.
>
> Shane
>
> > You can save the generated html to a file and manually change the url
> > to something else that will trap and log the values.
> >
> > Lots of different options, but the key is to verify that there is no
> > value being submitted for your component, which is what the error
> > message is claming.
> >
> > On 6/8/07, Shane Petroff <shane@mayet.ca> wrote:
> >> 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 <shane@mayet.ca> 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 <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
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Mime
View raw message