On 4/13/06, Murray Brandon <[EMAIL PROTECTED]> wrote:
> I've gone through to explain the ones I've resolved (2,4,5,6):
> > 1) <h:commandButton> tags render an input button that refers to
> > non-existent javascript named after the form I am in scope of. eg.
> > clear_userEditForm( ); Why? Is this a known bug? Surely other
> > people out there know why this is happening? The javascript reference
> > is rendered by MyFaces.
> Still a problem even with the latest nightly myfaces. Would like to
> know where the clear_formname( ) method is supposed to come from, so I
> can track down this one.
> I get some log warnings from myfaces which might have something to do
> with it:
> Apr 13, 2006 6:55:37 AM
> org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser readFilterMapping
> *WARNING: Ignored element 'servlet-name' as child of 'filter-mapping'.*
> Apr 13, 2006 6:55:37 AM
> org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser readFilterMapping
> WARNING: Ignored element 'servlet-name' as child of 'filter-mapping'.
>
> <filter-mapping>
> <filter-name>AdfFacesFilter</filter-name>
> <servlet-name>FacesServlet</servlet-name>
> </filter-mapping>
> <filter-mapping>
> <filter-name>MyFacesExtensionsFilter</filter-name>
> <servlet-name>FacesServlet</servlet-name>
> </filter-mapping>
>
> Perhaps because my filter-mappings are defined before my servlets?
Filter mappings must come before servlets. You're seeing a bug
in the MyFaces's WebXmlParser code - it only understands
url-pattern. I suspect that this means you need to change
the ExtensionsFilter mapping from servlet-name to url-pattern,
which will probably fix up #1, but you should also file a bug against
MyFaces to support servlet-name mappings for ExtensionsFilter.
> > 2) The following ADF table example does not create a 'row' entity and
> > hence I see only headers and no rows of content. The drop-down knows
> > there are 150 records in the results list, so it is resolving
> > mob.userList.results perfectly ok, I just get no data. Surely this
> > should work "out of the box"?
> >
> > <af:table id="t1" summary="My Summary"
> > value="#{mob.userList.results}" var="row" rows="10">
> > <af:column id="c1" sortProperty="surname">
> > <f:facet name="header">
> > <af:outputText value="Surname"/>
> > </f:facet>
> > <af:outputText id="c2" value="#{row.surname}"/>
> > </af:column>
> > </af:table>
> This was due to us using JSF 1.1 EL resolution. It turns out we were
> intercepting the resolve for the iterated table entry, and the
> ELContext.isPropertyResolved( ) was still set from the previous (totally
> unrelated call). I turned off our custom resolvers and hey presto,
> suspect module identified. I have the ADF table working fine now.
Hrm - why is ELContext.isPropertyResolved() true? What previous,
unrelated call set it, and why is it still unset? Something seems
fishy here - it's possible there's bugs in Facelets' support for JSF
1.1 resolvers.
But I'm certainly glad it's not an ADF table bug. ;)
> > 3) Unless I define unique id tags on every component, I cannot avoid
> > duplicate IDs when I use facelet <ui:include commands. This is a show
> > stopper for our project.
> Have not checked for this with the latest myfaces nightly.
Hopefully, that'll fix it.
-- Adam
