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

Reply via email to