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?
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.
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.
4) status.index does not resolve in the following code.
<c:forEach items="${ui.tableInfo.properties}" var="foo"
varStatus="status"> <h:outputText value="${foo} and count is
${status.index}"/>
</c:forEach>
Fixed by the fix to 2) as well.
5) Multipart file upload doesn't work - the setFile( ) method never
gets called on the bean, either using a MyFaces implementation or ADF
faces impl.
6) Any input fields inside a multipart file upload form don't persist
to their backing beans. If I remove the multipart tag from the form,
they work fine.
Thanks to Mike's help - my web.xml was invalid and fixed both 5) and 6)
- I had <filters> mixed in with <filter-mapping> and had the ADF filter
after the myfaces one.
I didn't know web.xml sections were order dependent - I guess you learn
something new every day ;-) I posted a copy of the web.xml in a
previous post.
Regards, Murray