Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
Hey Matthias!
Can you give me a concrete use case in
which RI could break without this?
I would test it during the week-end.
thanks,
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Christi,
yes I forgot, that I renamed the method :-)
We now *decorate* the HTML_BASIC (see log of the class)
We currently only replace these three.
I am not really sure, it it works without that...
There might be some issues...
Can you do me a favor ?
check with RI 1.2_07 ?
(they changed something on renderKit loading etc. there)
If it works fine for you there, I'll check again with our internal things,
and I'll finally remove that code.
Thanks!
-M
On Thu, Apr 10, 2008 at 10:57 AM, [EMAIL PROTECTED] wrote:
hi, this is where I found out what happens exactly:
//
// This RenderKit decorates the standard BASIC_HTML,
// but we need to replace some renderers with our own.
//
private void _modifyBasicHTMLRenderKit()
{
// We render UIForms with our own renderer
addRenderer(UIForm.COMPONENT_FAMILY,
javax.faces.Form,
new HtmlFormRenderer());
// And we render UICommandLink with our own renderer
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Link,
new HtmlCommandLinkRenderer());
// In jsf 1.1_02 the ri FormRenderer writes out script used by
// h:commandButton. Since we override the RI FormRenderer, we also
// need to override the commandButton renderer:
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Button,
new HtmlCommandButtonRenderer());
}
If you say now it should work, can we remove it ?
at least for 1.2 version.
thanks for the support
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
whoops...
shitty Gmail...
On Thu, Apr 10, 2008 at 10:20 AM, Matthias Wessendorf
[EMAIL PROTECTED]
wrote:
I found something surprising, while working on a Tomahawk
application,
in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.*
components
like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some exceptions
in
the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is
tr:document
to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and
containing
an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd on
component :
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class:
org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class:
javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:420)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:401)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(PPRPanelGroupRenderer.java:93)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:543)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.encodeTriggeredComponents(PPRPhaseListener.java:288)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.processPartialPageRequest(PPRPhaseListener.java:169)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.beforePhase(PPRPhaseListener.java:94)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73)
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
Try to include an h:commandLink / in a tr:form/ or the other way
round and see if you can submit the form like this - if it works, all
should be well.
It should work with RI 1.2, but also with 1.1 departing from 1.1_04, I think.
regards,
Martin
On 4/11/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hey Matthias!
Can you give me a concrete use case in
which RI could break without this?
I would test it during the week-end.
thanks,
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Christi,
yes I forgot, that I renamed the method :-)
We now *decorate* the HTML_BASIC (see log of the class)
We currently only replace these three.
I am not really sure, it it works without that...
There might be some issues...
Can you do me a favor ?
check with RI 1.2_07 ?
(they changed something on renderKit loading etc. there)
If it works fine for you there, I'll check again with our internal things,
and I'll finally remove that code.
Thanks!
-M
On Thu, Apr 10, 2008 at 10:57 AM, [EMAIL PROTECTED] wrote:
hi, this is where I found out what happens exactly:
//
// This RenderKit decorates the standard BASIC_HTML,
// but we need to replace some renderers with our own.
//
private void _modifyBasicHTMLRenderKit()
{
// We render UIForms with our own renderer
addRenderer(UIForm.COMPONENT_FAMILY,
javax.faces.Form,
new HtmlFormRenderer());
// And we render UICommandLink with our own renderer
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Link,
new HtmlCommandLinkRenderer());
// In jsf 1.1_02 the ri FormRenderer writes out script used by
// h:commandButton. Since we override the RI FormRenderer, we also
// need to override the commandButton renderer:
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Button,
new HtmlCommandButtonRenderer());
}
If you say now it should work, can we remove it ?
at least for 1.2 version.
thanks for the support
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
whoops...
shitty Gmail...
On Thu, Apr 10, 2008 at 10:20 AM, Matthias Wessendorf
[EMAIL PROTECTED]
wrote:
I found something surprising, while working on a Tomahawk
application,
in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.*
components
like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some
exceptions
in
the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is
tr:document
to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and
containing
an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd on
component :
{Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class:
org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class:
javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:420)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:401)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(PPRPanelGroupRenderer.java:93)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:543)
at
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
Yeah,
I know there was some work done, in that area,
but... I am lazy... :) so never bothered to check back
;-)
On Fri, Apr 11, 2008 at 10:15 AM, Martin Marinschek
[EMAIL PROTECTED] wrote:
Try to include an h:commandLink / in a tr:form/ or the other way
round and see if you can submit the form like this - if it works, all
should be well.
It should work with RI 1.2, but also with 1.1 departing from 1.1_04, I think.
regards,
Martin
On 4/11/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hey Matthias!
Can you give me a concrete use case in
which RI could break without this?
I would test it during the week-end.
thanks,
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Christi,
yes I forgot, that I renamed the method :-)
We now *decorate* the HTML_BASIC (see log of the class)
We currently only replace these three.
I am not really sure, it it works without that...
There might be some issues...
Can you do me a favor ?
check with RI 1.2_07 ?
(they changed something on renderKit loading etc. there)
If it works fine for you there, I'll check again with our internal
things,
and I'll finally remove that code.
Thanks!
-M
On Thu, Apr 10, 2008 at 10:57 AM, [EMAIL PROTECTED] wrote:
hi, this is where I found out what happens exactly:
//
// This RenderKit decorates the standard BASIC_HTML,
// but we need to replace some renderers with our own.
//
private void _modifyBasicHTMLRenderKit()
{
// We render UIForms with our own renderer
addRenderer(UIForm.COMPONENT_FAMILY,
javax.faces.Form,
new HtmlFormRenderer());
// And we render UICommandLink with our own renderer
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Link,
new HtmlCommandLinkRenderer());
// In jsf 1.1_02 the ri FormRenderer writes out script used by
// h:commandButton. Since we override the RI FormRenderer, we also
// need to override the commandButton renderer:
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Button,
new HtmlCommandButtonRenderer());
}
If you say now it should work, can we remove it ?
at least for 1.2 version.
thanks for the support
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
whoops...
shitty Gmail...
On Thu, Apr 10, 2008 at 10:20 AM, Matthias Wessendorf
[EMAIL PROTECTED]
wrote:
I found something surprising, while working on a Tomahawk
application,
in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.*
components
like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some
exceptions
in
the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is
tr:document
to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and
containing
an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd
on
component :
{Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class:
org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class:
javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
I found something surprising, while working on a Tomahawk application, in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.* components like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some exceptions in the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is tr:document to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and containing an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd on component :
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id: j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class: org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:420)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:401)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(PPRPanelGroupRenderer.java:93)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:543)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.encodeTriggeredComponents(PPRPhaseListener.java:288)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.processPartialPageRequest(PPRPhaseListener.java:169)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.beforePhase(PPRPhaseListener.java:94)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:134)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.myfaces.webapp.MyFacesServlet.service(MyFacesServlet.java:100)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.db.gto.coo.itsg.gui.login.LoginFilter.doHttpFilter(LoginFilter.java:131)
at
com.db.gto.coo.itsg.gui.filter.SpringJSFFilterBase.doFilter(SpringJSFFilterBase.java:47)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:226)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:70)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:63)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
whoops...
shitty Gmail...
On Thu, Apr 10, 2008 at 10:20 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I found something surprising, while working on a Tomahawk application, in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.* components like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some exceptions in the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is tr:document to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and containing an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd on component
:
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id: j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class: org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:420)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:401)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(PPRPanelGroupRenderer.java:93)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:543)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.encodeTriggeredComponents(PPRPhaseListener.java:288)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.processPartialPageRequest(PPRPhaseListener.java:169)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.beforePhase(PPRPhaseListener.java:94)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:134)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.myfaces.webapp.MyFacesServlet.service(MyFacesServlet.java:100)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.db.gto.coo.itsg.gui.login.LoginFilter.doHttpFilter(LoginFilter.java:131)
at
com.db.gto.coo.itsg.gui.filter.SpringJSFFilterBase.doFilter(SpringJSFFilterBase.java:47)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:226)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:70)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:63)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
at
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
The reason Trinidad is doing this was a bug in the early versions of
the JSF-RI - there the form and the link were interlinked, and you
could not use one without the other. The only chance Trinidad would
have got this work was by overwriting the renderers. Now, this should
not be necessary anymore!
regards,
Martin
On 4/10/08, Cristi Toth [EMAIL PROTECTED] wrote:
Hi,
I found something surprising, while working on a Tomahawk application, in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.* components like
Form, HtmlCommandButton and HtmlCommandLink.
Why is this needed?
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some exceptions in the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is tr:document to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and containing an
h:commandButton to work.
i got this stack trace on a PPR submit:
*javax.faces.FacesException*: Exception while calling encodeEnd on component
: {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id: j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class: org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at javax.faces.component.UIComponentBase.encodeEnd(*
UIComponentBase.java:559*)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(*
RendererUtils.java:420*)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(*
RendererUtils.java:401*)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(*
PPRPanelGroupRenderer.java:93*)
at javax.faces.component.UIComponentBase.encodeChildren(*
UIComponentBase.java:543*)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.encodeTriggeredComponents(*
PPRPhaseListener.java:288*)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.processPartialPageRequest(*
PPRPhaseListener.java:169*)
at org.apache.myfaces.custom.ppr.PPRPhaseListener.beforePhase(*
PPRPhaseListener.java:94*)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(
*PhaseListenerManager.java:73*)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(*
LifecycleImpl.java:134*)
at javax.faces.webapp.FacesServlet.service(*FacesServlet.java:152*)
at org.apache.myfaces.webapp.MyFacesServlet.service(*
MyFacesServlet.java:100*)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
*ApplicationFilterChain.java:290*)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)
at com.db.gto.coo.itsg.gui.login.LoginFilter.doHttpFilter(*
LoginFilter.java:131*)
at com.db.gto.coo.itsg.gui.filter.SpringJSFFilterBase.doFilter(*
SpringJSFFilterBase.java:47*)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
*ApplicationFilterChain.java:235*)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(*
ExtensionsFilter.java:226*)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
*ApplicationFilterChain.java:235*)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(*
OncePerRequestFilter.java:70*)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
*ApplicationFilterChain.java:235*)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)
at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(*
RequestContextFilter.java:63*)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(*
OncePerRequestFilter.java:75*)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
*ApplicationFilterChain.java:235*)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(*
ApplicationFilterChain.java:206*)
at
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(*
CharacterEncodingFilter.java:96*)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(*
OncePerRequestFilter.java:75*)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
hi, this is where I found out what happens exactly:
//
// This RenderKit decorates the standard BASIC_HTML,
// but we need to replace some renderers with our own.
//
private void _modifyBasicHTMLRenderKit()
{
// We render UIForms with our own renderer
addRenderer(UIForm.COMPONENT_FAMILY,
javax.faces.Form,
new HtmlFormRenderer());
// And we render UICommandLink with our own renderer
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Link,
new HtmlCommandLinkRenderer());
// In jsf 1.1_02 the ri FormRenderer writes out script used by
// h:commandButton. Since we override the RI FormRenderer, we also
// need to override the commandButton renderer:
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Button,
new HtmlCommandButtonRenderer());
}
If you say now it should work, can we remove it ?
at least for 1.2 version.
thanks for the support
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
whoops...
shitty Gmail...
On Thu, Apr 10, 2008 at 10:20 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
I found something surprising, while working on a Tomahawk application,
in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.* components
like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some exceptions in
the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is tr:document
to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and containing
an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd on
component :
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class: org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:420)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:401)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(PPRPanelGroupRenderer.java:93)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:543)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.encodeTriggeredComponents(PPRPhaseListener.java:288)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.processPartialPageRequest(PPRPhaseListener.java:169)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.beforePhase(PPRPhaseListener.java:94)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:134)
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.myfaces.webapp.MyFacesServlet.service(MyFacesServlet.java:100)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.db.gto.coo.itsg.gui.login.LoginFilter.doHttpFilter(LoginFilter.java:131)
at
com.db.gto.coo.itsg.gui.filter.SpringJSFFilterBase.doFilter(SpringJSFFilterBase.java:47)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:226)
at
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
Christi,
yes I forgot, that I renamed the method :-)
We now *decorate* the HTML_BASIC (see log of the class)
We currently only replace these three.
I am not really sure, it it works without that...
There might be some issues...
Can you do me a favor ?
check with RI 1.2_07 ?
(they changed something on renderKit loading etc. there)
If it works fine for you there, I'll check again with our internal things,
and I'll finally remove that code.
Thanks!
-M
On Thu, Apr 10, 2008 at 10:57 AM, [EMAIL PROTECTED] wrote:
hi, this is where I found out what happens exactly:
//
// This RenderKit decorates the standard BASIC_HTML,
// but we need to replace some renderers with our own.
//
private void _modifyBasicHTMLRenderKit()
{
// We render UIForms with our own renderer
addRenderer(UIForm.COMPONENT_FAMILY,
javax.faces.Form,
new HtmlFormRenderer());
// And we render UICommandLink with our own renderer
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Link,
new HtmlCommandLinkRenderer());
// In jsf 1.1_02 the ri FormRenderer writes out script used by
// h:commandButton. Since we override the RI FormRenderer, we also
// need to override the commandButton renderer:
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Button,
new HtmlCommandButtonRenderer());
}
If you say now it should work, can we remove it ?
at least for 1.2 version.
thanks for the support
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
whoops...
shitty Gmail...
On Thu, Apr 10, 2008 at 10:20 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
I found something surprising, while working on a Tomahawk application,
in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.* components
like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some exceptions in
the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is
tr:document
to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and
containing
an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd on
component :
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class: org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class: javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:420)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:401)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(PPRPanelGroupRenderer.java:93)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:543)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.encodeTriggeredComponents(PPRPhaseListener.java:288)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.processPartialPageRequest(PPRPhaseListener.java:169)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.beforePhase(PPRPhaseListener.java:94)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:134)
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.myfaces.webapp.MyFacesServlet.service(MyFacesServlet.java:100)
at
