You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Murray Brandon <mu...@hotmagna.com> on 2006/04/13 09:38:24 UTC
Re: ADF + myfaces + Facelets completely compatible?
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
Re: clear_formname( ) javascript
Posted by Murray Brandon <mu...@hotmagna.com>.
Any more hints on this one guys?
I've run out of ideas.
Murray Brandon wrote:
> Hey no worries Mario, I'll check out the latest nightly to see if it
> gets rid of the warning.
>
> Can any of you guys fill me in on the source of this clear_formname( )
> method?
> I mean, I can see where it is called from, but is it the myfaces
> filter that's responsible for generating the method?
> >From what I read, my filter-mapping warnings can be ignored - it is
> still processed ok, so the clear_formname( ) should be being created.
> Yet I suspect my myfaces filter is not being loaded correctly. How
> can I tell? Wouldn't that stop the date chooser buttons appearing?
> Mine appear.
>
> Looking at the source of HtmlFormRendererBase it looks like it
> /optionally/ outputs the javascript for the clear_formname( ) method,
> but HtmlButtonRendererBase /always/ adds the call to the method
> onClick= regardless. So I get the javascript error on my page when I
> click on a commandButton saying that clear_formname( ) is not defined.
>
> Have I missed something? Are there circumstances where "set" would be
> empty?
> Maybe I need to set the HIDDEN_COMMAND_INPUTS_SET_ATTR attribute somehow?
>
> eg. (my source is a nightly from a few weeks ago, so forgive me if
> it's not quite the same)
>
> *HtmlFormRendererBase.java *
> //render hidden command inputs
> Set set =
> (Set)component.getAttributes().get(HIDDEN_COMMAND_INPUTS_SET_ATTR);
> *if (set != null && !set.isEmpty()) *
> {
> HtmlRendererUtils.renderHiddenCommandFormParams(writer, set);
>
> String target;
> if (component instanceof HtmlForm)
> {
> target = ((HtmlForm)component).getTarget();
> }
> else
> {
> target =
> (String)component.getAttributes().get(HTML.TARGET_ATTR);
> }
>
> HtmlRendererUtils.renderClearHiddenCommandFormParamsFunction(writer,
>
> component.getClientId(facesContext),
>
> set,
>
> target);
> }
>
> *HtmlButtonRendererBase.java* /always /puts in the javascript for the
> call to the method
>
> /*/call the clear_<formName> method
>
> onClick.append(HtmlRendererUtils.getClearHiddenCommandFormParamsFunctionName(formName)).append("();");*
>
>
> Regards, Murray
>
> PS. I noticed you all working over easter. tsk tsk. ;-)
>
> Mario Ivankovits wrote:
>> Hi!
>>
>> Yes, it was only a warning - no other side effect. It should be fixed now.
>>
>> Sorry for the inconvenience.
>>
>> Ciao,
>> Mario
>>
>>> On 4/14/06, Mike Kienenberger <mk...@gmail.com> wrote:
>>>
>>>
>>>> I've opened http://issues.apache.org/jira/browse/TOMAHAWK-257 on this issue.
>>>>
>>>> I know things work if you use the proposed 1.1.2 MyFaces-core release
>>>> even with the warnings. It's possible that things are breaking if you
>>>> use the 1.1.3 MyFaces-core trunk.
>>>>
>>>>
>>> I ran a quick test, and it doesn't seem to matter if I use 1.1.3 core.
>>> I get the warnings at startup that way, but my filter-mappings are
>>> still correctly used. As near as I can tell, the only effect is an
>>> incorrect warning message, but everything is working as expected.
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@facelets.dev.java.net
>> For additional commands, e-mail: users-help@facelets.dev.java.net
>>
>>
>>
>
Re: ADF + myfaces + Facelets completely compatible?
Posted by Adam Winer <ad...@oracle.com>.
Mike Kienenberger wrote:
> 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?
>
> On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
> 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.
>
> Unless something has regressed recently, MyFaces most certainly
> supports servlet-name. I use it almost exclusively in my web.xml
> file, and it's the recommended way to install the Extensions filter on
> our web site.
>
>
> <!-- extension mapping for adding <script/>, <link/>, and other
> resource tags to JSF-pages -->
> <filter-mapping>
> <filter-name>MyFacesExtensionsFilter</filter-name>
> <!-- servlet-name must match the name of your
> javax.faces.webapp.FacesServlet entry -->
> <servlet-name>FacesServlet</servlet-name>
> </filter-mapping>
Hrm, I was just looking at the very latest WebXmlParser code...
http://svn.apache.org/viewcvs.cgi/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/webapp/webxml/WebXmlParser.java?rev=393150&view=markup
readFilterMapping() here has url-pattern, but not servlet-name.
What am I missing?
-- Adam
Re: ADF + myfaces + Facelets completely compatible?
Posted by Mike Kienenberger <mk...@gmail.com>.
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?
On 4/14/06, Adam Winer <aw...@gmail.com> wrote:
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.
Unless something has regressed recently, MyFaces most certainly
supports servlet-name. I use it almost exclusively in my web.xml
file, and it's the recommended way to install the Extensions filter on
our web site.
<!-- extension mapping for adding <script/>, <link/>, and other
resource tags to JSF-pages -->
<filter-mapping>
<filter-name>MyFacesExtensionsFilter</filter-name>
<!-- servlet-name must match the name of your
javax.faces.webapp.FacesServlet entry -->
<servlet-name>FacesServlet</servlet-name>
</filter-mapping>
Re: ADF + myfaces + Facelets completely compatible?
Posted by Adam Winer <aw...@gmail.com>.
On 4/13/06, Murray Brandon <mu...@hotmagna.com> 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