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 Mon, 11 Jun 2007 16:05:08 GMT
Mike Kienenberger wrote:
> I'm confused.

That's good, at least I have some company!  :)

> Clearly, something has changed from the time it was sent to the
> browser (generated html) and the time it was received from the browser
> (submitted values).

That's what seems to be the case.

> Also, if the generated html has _id30, clearly there is no explicit
> name for contentPanel.
This particular panel is one of the few things named in the jsp

      <h:panelGrid id="contentPanel" binding="#{reportCardBean.mainPanel}"
                   columns="1" border="1" width="100%" cellspacing="0" 
styleClass="panel"/>

(It's name used to be 'mainPanel' to better match the binding, but it an 
effort to ensure that caching wasn't an issue, I renamed it)

> a) create a simplified example showing the problem, or

If only I'd looked into Selenium earlier, I might have become aware of 
the time at which the problem was introduced... I only see the issue 
once things are large.

> b) post your page code, the generated html, and the form-value pairs
> submitted afterward.
I don't know how much good the creation code would be, since execution 
paths through it all depend on the metadata coming out of the database 
(the components added to the page depend on context like the user 
viewing the page and the attributes of the person being represented on 
the page). I'll send a copy of the generated html shortly (I have reams 
of stuff commented out right now to try to isolate the issue).

Is there any upper limit to the number of components which can reliably 
be rendered? One of the things that my users have requested is lots of 
contextual information, as a result, this page has grown huge. The 
reason I ask is that the discrepancy between id and request params is 
not the only problem. I commented out the code which creates the text 
areas which the warnings complain about, but my navigation issues were 
still not fixed. I can successively comment things out to get back to a 
point where navigation functions again, but I haven't yet tracked down 
the code which kills things (it seems to be in 2 areas). For now, I'm 
working under the rather baseless assumption that the 2 problems are 
interrelated.

Thanks for your efforts so far.

Shane

>
> On 6/8/07, Shane Petroff <shane@mayet.ca> wrote:
>> Mike Kienenberger wrote:
>> > So the question is why does _id30 get translated to contentPanel_1153
>> > and _id33 get translated to contentPanel_1344 on submit?
>> >
>> That would be the question alright... It seems as though the problem
>> actually happens before/during html generation. On submit, it's too 
>> late.
>>
>> > It looks like you've went from automatically generated ids for these
>> > components to explicitly-set (plus some random number) ids for these
>> > components.
>> The parameter map seems like it is the correct one. The text areas in
>> question sit in tabs located on 'mainForm'. Specifically the containment
>> looks like:
>>
>> mainForm (explicitly named)
>>     contentPanel (explicitly named)
>>         Tab_1 (generated id)
>>                 Panel_1 (generated id)
>>                     editableAnecdotalComment548806536 (explicitly named
>> - the numbers at the end refer to a db id)
>>
>> Shane
>> >
>> >
>> > 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
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane


Mime
View raw message