A book on Apache MyFaces?

[rashmip]

Hi,

I am an acquisition editor for Packt Publishing working on Apache. We are 
currently planning to develop a book on Apache MyFaces.

Packt publishes a range of books, with a particular focus on Open Source tools. 
We pay authors in the form of a royalty and an advance against that royalty. 
Our royalty offers are much higher than most tech publishers. We also support 
open source projects through an Open Source royalty. This means that when we 
publish a Joomla book, the Joomla project will receive a share of the book's 
revenue. The book would go beyond what's covered in the current Joomla manual 
by covering the wider topic of Network Attached Storage, showing how to choose 
appropriate configurations for different scenarios, and trouble shooting, among 
other things. It won't assume readers are already familiar with RAID, for 
example, or other storage-specific topics. It will teach the overall concepts 
of Joomla alongside the specific implementation in Joomla. 

I would like to call you on board to write this book. Please let me know if 
this sound interesting to you. 

Of course, if you like the sound of writing but you believe there are other 
topics that you would be better suited to write about then please let me know. 
I'm always on the look out for new ideas, especially Apache topics.

I look forward to hearing from you.

Thanks,
Rashmi

Re: [Trinidad] why does Trinidad override javax.faces.* renderers?

[Matthias Wessendorf]

> 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.StandardContex

Re: [Trinidad] why does Trinidad override javax.faces.* renderers?

[Matthias Wessendorf]

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.Applicat

Re: [proposal] jsf validation with annotations

[Martin Marinschek]

Hi Gerhard,

seems the community is leaning towards a new submodule (Cagatay's -1
is only one of the many votes). But - as Mario said - let the code
speak first!

regards,

Martin

On 4/9/08, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> I think so too.  Having a sub-project of a sub-project might be a little
> infrastructure heavy, there is nothing to say that Sev-en couldn't
> become it's own MyFaces subproject that's intended to be used in a
> MyFaces/Orchestra type environment.
>
> I also agree it should my a MyFaces wide decision because it impacts
> expectations on the renderkits.
>
> Scott
>
> Kito D. Mann wrote:
> > I think Mario has made some very good points...
> >
> >
> >> -Original Message-
> >> From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, April 09, 2008 5:14 AM
> >> To: MyFaces Development
> >> Subject: Re: [proposal] jsf validation with annotations
> >>
> >> Hi!
> >>
> >>> my position on this is we could make sev-en part of orchestra, if the
> >>> orchestra crew really, really wants it. If not, this should just be a
> >>> separate sub-module in MyFaces. It is interesting enough to stand on
> >>> its own.
> >>>
> >>>
> >> First, Orchestra is part of the MyFaces community, so it really, really
> >> should be a decision the MyFaces community felt, and not a "Orchestra
> >> Team" only one.
> >>
> >> Anyway, I think this is a question on how we position Orchestra.
> >> If it is a strong position against JBoss Seam, then it probably might
> >> make sense to include everything which makes life easier for the
> >> developer into Orchestra - just as Seam tries to do.
> >> However, then we loose one of the strongest arguments pro Orchestra:
> >> Being a lightweight Conversation-Centric Library.
> >>
> >> If, we could add it as sub-module to Orchestra, but I think the best
> >> place for sev-en (would like to see a new name anyway) is to be a
> >> submodule of MyFaces. But first I'd like to see the technical details
> >> of
> >> how the sev-en core works. e.g. in the examples I've seen a lot of
> >> converter wrapper stuff ...
> >>
> >> Building an official MyFaces Maven Artifact which bootup a development
> >> environment (MyFaces Fullstack) with what we think on need for
> >> development of any-range-sized applications would be more approriate
> >> then. Such a project could include sev-en too.
> >>
> >> Ciao,
> >> Mario
> >>
> >
> >
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [Trinidad] why does Trinidad override javax.faces.* renderers?

[Martin Marinschek]

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(*
> OncePerReques

Re: [Trinidad] why does Trinidad override javax.faces.* renderers?

[cristi . toth]

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

[jira] Commented: (MYFACES-1848) JSP regular exceptions causes vlack page output

[Guy Bashan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587542#action_12587542
 ] 

Guy Bashan commented on MYFACES-1848:
-

This bug is pretty annoying and can be simulated very easily:
Generate a regular jsp page that throws exception.
Run the page regularly (not through faces) and you will see the exception on 
the screen.
Run the page through faces and you will get a blank page.

> JSP regular exceptions causes vlack page output
> ---
>
> Key: MYFACES-1848
> URL: https://issues.apache.org/jira/browse/MYFACES-1848
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 1.2.2
>Reporter: Guy Bashan
>
> The new JSF (1.2.2) outputs a nice formatted exception message (with session 
> variables, view and full stacktrace).
> But when I get error in the page caused by JSP, I simply see a blank page (I 
> am able to see the exception itself in the console ...)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [proposal] jsf validation with annotations

[Matthias Wessendorf]

true!

On Wed, Apr 9, 2008 at 8:28 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> I think so too.  Having a sub-project of a sub-project might be a little
> infrastructure heavy, there is nothing to say that Sev-en couldn't become
> it's own MyFaces subproject that's intended to be used in a
> MyFaces/Orchestra type environment.
>
>  I also agree it should my a MyFaces wide decision because it impacts
> expectations on the renderkits.
>
>  Scott
>
>
>
>  Kito D. Mann wrote:
>
> > I think Mario has made some very good points...
> >
> >
> >
> > > -Original Message-
> > > From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, April 09, 2008 5:14 AM
> > > To: MyFaces Development
> > > Subject: Re: [proposal] jsf validation with annotations
> > >
> > > Hi!
> > >
> > >
> > > > my position on this is we could make sev-en part of orchestra, if the
> > > > orchestra crew really, really wants it. If not, this should just be a
> > > > separate sub-module in MyFaces. It is interesting enough to stand on
> > > > its own.
> > > >
> > > >
> > > >
> > > First, Orchestra is part of the MyFaces community, so it really, really
> > > should be a decision the MyFaces community felt, and not a "Orchestra
> > > Team" only one.
> > >
> > > Anyway, I think this is a question on how we position Orchestra.
> > > If it is a strong position against JBoss Seam, then it probably might
> > > make sense to include everything which makes life easier for the
> > > developer into Orchestra - just as Seam tries to do.
> > > However, then we loose one of the strongest arguments pro Orchestra:
> > > Being a lightweight Conversation-Centric Library.
> > >
> > > If, we could add it as sub-module to Orchestra, but I think the best
> > > place for sev-en (would like to see a new name anyway) is to be a
> > > submodule of MyFaces. But first I'd like to see the technical details
> > > of
> > > how the sev-en core works. e.g. in the examples I've seen a lot of
> > > converter wrapper stuff ...
> > >
> > > Building an official MyFaces Maven Artifact which bootup a development
> > > environment (MyFaces Fullstack) with what we think on need for
> > > development of any-range-sized applications would be more approriate
> > > then. Such a project could include sev-en too.
> > >
> > > Ciao,
> > > Mario
> > >
> > >
> >
> >
> >
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Trinidad] why does Trinidad override javax.faces.* renderers?

[Matthias Wessendorf]

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

Quickstart + Archetypes...

[Matthias Wessendorf]

Hello,

we now finally have release for our archetypes (thanks leonardo).

During ACon, I noticed that:
http://wicket.apache.org/quickstart.html

I like that. So question is ... should we "borrow" that idea?
Udo, Gerald and I really like that!
We not only need version, we also need a selection of our projects
(that currently support archetypes).

Or do you think is the current description in our wiki enough ?

-M

-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: Quickstart + Archetypes...

[Martin Marinschek]

very good - we should do it.

regards,

Martin

On 4/10/08, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Hello,
>
> we now finally have release for our archetypes (thanks leonardo).
>
> During ACon, I noticed that:
> http://wicket.apache.org/quickstart.html
>
> I like that. So question is ... should we "borrow" that idea?
> Udo, Gerald and I really like that!
> We not only need version, we also need a selection of our projects
> (that currently support archetypes).
>
> Or do you think is the current description in our wiki enough ?
>
> -M
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Quickstart + Archetypes...

[Matthias Wessendorf]

k

after ACon, I'll do that

-M

On Thu, Apr 10, 2008 at 3:03 PM, Martin Marinschek
<[EMAIL PROTECTED]> wrote:
> very good - we should do it.
>
>  regards,
>
>  Martin
>
>
>
>  On 4/10/08, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
>  > Hello,
>  >
>  > we now finally have release for our archetypes (thanks leonardo).
>  >
>  > During ACon, I noticed that:
>  > http://wicket.apache.org/quickstart.html
>  >
>  > I like that. So question is ... should we "borrow" that idea?
>  > Udo, Gerald and I really like that!
>  > We not only need version, we also need a selection of our projects
>  > (that currently support archetypes).
>  >
>  > Or do you think is the current description in our wiki enough ?
>  >
>  > -M
>  >
>  > --
>  > Matthias Wessendorf
>  >
>  > further stuff:
>  > blog: http://matthiaswessendorf.wordpress.com/
>  > sessions: http://www.slideshare.net/mwessendorf
>  > mail: matzew-at-apache-dot-org
>  >
>
>
>  --
>
>  http://www.irian.at
>
>  Your JSF powerhouse -
>  JSF Consulting, Development and
>  Courses in English and German
>
>  Professional Support for Apache MyFaces
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Trinidad] private / protected final methods in renderers

[Simon Lessard]

Hello all,

I'm a bit torn on that issue. On one side, I don't find it too hard to
override current renderers and actually think there's a quite formidable
amount of protected methods, but on the other side I do come across annoying
final methods every now and then and I have to use my commiter right to
remove it which is not an immediate option available to everyone. So,
basically, I'm +0...


Regards,

~ Simon

On Thu, Apr 10, 2008 at 2:57 AM, Martin Marinschek <
[EMAIL PROTECTED]> wrote:

> And here again, I can only support Cristi - Trinidad has clearly said
> that the renderers are part of the implementation (it is even in the
> package name!). People know implementation code might change its API
> in the next version, so there is no sense in enforcing this on the
> source level...
>
> regards,
>
> Martin
>
> On 4/10/08, Cristi Toth <[EMAIL PROTECTED]> wrote:
> > One more thing,
> >
> > Trinidad now being open-source means that it should be really open
> > for those advanced developers that dive into the code.
> >
> > On Thu, Apr 10, 2008 at 8:11 AM, Cristi Toth <[EMAIL PROTECTED]>
> wrote:
> >
> > > Well, between having developers not being able to override some simple
> > > behaviour
> > > and keeping backwards compatibility on subclassers,
> > > I'll choose the 2nd one.
> > >
> > > This is the reason that some components from tomahawk,
> > > that are less feature-enabled that thos in Trinidad,
> > > are considered more flexible and easier to customize than the ones in
> > > Trinidad.
> > >
> > > Quite some experienced MyFaces developers told me to
> > > "forget" overriding table and input renderers in Trinidad
> > > (some of the most frequently used renderers).
> > >
> > >
> > > So between not having a feature at all and being careful not to break
> > > backwards compatibility on some methods,
> > > the second one doesn't seem that bad, but the first one does.
> > >
> > > regards,
> > >
> > >
> > > On Thu, Apr 10, 2008 at 2:39 AM, Blake Sullivan
> > <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > >  The reason is that each time we make one of these methods
> protected, we
> > > > have to guarantee that we will maintain the semantics of that hook
> until
> > the
> > > > end-of-time or risk breaking users of that hook.  By slowly opening
> up
> > the
> > > > api we get the developers to tell us what they need and can weigh
> the
> > > > benefit against the support cost.  If the hooks don't require that
> super
> > be
> > > > called, in many ways, it is safer to completely override the
> function.
> > > >
> > > > This is the general issue of the competing desires to make it easy
> to
> > > > tweak a renderer by subclassing without needing to completely
> replace it
> > vs.
> > > > a desire to be able to change the Renderer implementation without
> > breaking
> > > > subclassers.  I actually think that we went too far in providing
> lots of
> > > > subclasser knobs in Trinidad, but that's just my opinion.
> > > >
> > > > -- Blake Sullivan
> > > >
> > > > Cristi Toth said the following On 4/9/2008 5:23 PM PT:
> > > >
> > > > Hi guys,
> > > >
> > > > A lot of Trinidad renderers have some "override useful" methods as
> > > > private or protected final.
> > > > This makes customizing renderers a nasty job.
> > > >
> > > > - first these methods obviously can't be overriden
> > > > - then when trying to override some public/protected methods,
> > > >   it's hard because they use other private methods that you can't
> use in
> > > > your overriden method
> > > >
> > > > I assume this come from the fact that Trinidad wasn't open-source in
> its
> > > > origins... or?
> > > > Do we still have reasons to keep it this way?
> > > >
> > > > IMO we could make those protected final "override useful" methods to
> > > > protected
> > > > and the private methods used in those methods, make them protected
> > > > final.
> > > >
> > > > What's you opinion on this?
> > > >
> > > > Regards,
> > > > --
> > > > Cristi Toth
> > > >
> > > > -
> > > > Codebeat
> > > > www.codebeat.ro
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Cristi Toth
> > >
> > > -
> > > Codebeat
> > > www.codebeat.ro
> > >
> >
> >
> >
> > --
> > Cristi Toth
> >
> > -
> > Codebeat
> > www.codebeat.ro
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

[jira] Created: (MYFACES-1853) ErrorPageWriter causes Facelets/MyFaces confusion

[JIRA]

ErrorPageWriter causes Facelets/MyFaces confusion
-

 Key: MYFACES-1853
 URL: https://issues.apache.org/jira/browse/MYFACES-1853
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions: 1.2.2
 Environment: MyFaces 1.2.2
Facelets 1.1.3
Tomcat 6.0.14
Reporter: Michael Heß


I just stumbled upon some weired problem. I have a rather basic myfaces
1.2.2 + facelets 1.1.3 setup. What I tried to achieve, is to NOT have
either Facelets nor MyFaces handle any of the error 500 scenarios.

Right now, in case of error 500 I have a facelets error page. "An Error
Occured", and collapsable trees for the components etc. You know the
drill.

So I decided to disable debugging in facelets, by switching
context-parameter facelets.DEVELOPMENT to false. This was the first moment
I got confused, because devmode was already disabled.

BUT: The error page definetly states "Generated by Facelets" in the lower
right corner.

I spent the last hour tracking this down. So far I have confirmed that the
FaceletsViewHandler does not trigger the generation of said errorpage. So
I searched some more, and found javax.faces.webapp._ErrorPageWriter to be
the culprit. The problem is, that it seems to be a copy of the Facelets
DevTools class. And furthermore the filename of the error-template has
been copied as well. It's

"META-INF/rsc/facelet-dev-error.xml"

on both myfaces as well as facelets. I have checked the template included
with myfaces and it is clearly different from the one included with
facelets. So my best guess right now (I have not confirmed this any
further) is, that MyFaces loads the template from facelets.jar due to some
unlucky webapp classloader situation.

Although the solution to my current problem is most likely to just disable
debugging in myfaces as well, I would like to strongly advise to change
the filename of the MyFaces error-template. This really confused me a lot.
:-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Quickstart + Archetypes...

[Grant Smith]

That's very nice. Good find.

On Thu, Apr 10, 2008 at 4:12 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:

> Hello,
>
> we now finally have release for our archetypes (thanks leonardo).
>
> During ACon, I noticed that:
> http://wicket.apache.org/quickstart.html
>
> I like that. So question is ... should we "borrow" that idea?
> Udo, Gerald and I really like that!
> We not only need version, we also need a selection of our projects
> (that currently support archetypes).
>
> Or do you think is the current description in our wiki enough ?
>
> -M
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 
Grant Smith

[OT] IP Clearance for Tiles-Kaolin: seeking a volunteer

[Antonio Petrelli]

Dear friends,
First of all, sorry for the cross posting.
I am Antonio Petrelli, PMC Member of Apache Tiles.
We would like to integrate Dimensions with the new name of "Kaolin"
inside the Tiles codebase:
http://mutidimensions.sourceforge.net/
The only developers of this projects are Aaron Roller and me. Aaron is
willing to give his software grant to donate it to ASF.

Currently I am in search of a volunteer for the IP clerance
processing. I already asked Tiles' PMC Chair (Greg Reddin) but he is
too busy to help. I already asked the Incubator mailing list, with no
answer. If anybody can help me, I will appreciate it much :-)

Thanks in advance
Antonio

[jira] Created: (MYFACES-1854) does not evaluates EL expressions

[Guy Bashan (JIRA)]

 does not evaluates EL expressions
-

 Key: MYFACES-1854
 URL: https://issues.apache.org/jira/browse/MYFACES-1854
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Guy Bashan


 does not evaluates EL expressions. This, for example, makes 
impossible to create multi-language dynamic drop down items.
Example:
-
SelectItem selectItem = new SelectItem("-1",  
"#{bundle['dropdown.advertiser.select']}")
This EL expression will not be evaluated.

In JSP value is evaluated:
  

  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] delegated sub-renderers

[Andrew Robinson]

++1

On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek
<[EMAIL PROTECTED]> wrote:
> If you want to here my opinion: we need Trinidad to be as customizable
>  as possible. People who do this customization will know what they are
>  doing - and will know how to handle an upgrade to a new version. It is
>  enough to say: this is part of the impl package - it might change from
>  version to version, your own fault, if you extend it and it breaks!
>
>  IMHO, Adam is wrong in this regard.
>
>  regards,
>
>  Martin
>
>
>
>  On 4/10/08, Cristi Toth <[EMAIL PROTECTED]> wrote:
>  > But what does the "open-source" mean then... ?
>  > All the renderers are in the impl packages,
>  > but that's the beauty of open-source...
>  > you can customize something you need.
>  > That's an advantage that we should not oversee.
>  >
>  > On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson <
>  > [EMAIL PROTECTED]> wrote:
>  >
>  > > I am not sure if you will get much support as Trinidad has all the
>  > > renderers in the impl package, and therefore should not be considered
>  > > part of its api and also should not be extended. Fighting this and
>  > > asking for more APIs in the past was fruitless for me, but then again
>  > > that was when Adam Winer was the constant one to veto all
>  > > improvements.
>  > >
>  > > On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth <[EMAIL PROTECTED]> wrote:
>  > > > Hi,
>  > > >
>  > > > As you probably know, there are a lot of "composed" renderers in
>  > > Trinidad
>  > > > which delegate to other "sub"renderers to render parts of the 
> component.
>  > > > i.e. Table renderer delegates to:
>  > > >   - NavBar(subclass of SelectRangeChoiceBarRenderer),
>  > > >  - AllDetails (subclass of ShowDetailRenderer)
>  > > >  - DetailColumnRenderer
>  > > >
>  > > > input fields renderers (subclasses of InputLabelAndMessageRenderer)
>  > > delegate
>  > > > to:
>  > > >   - one renderer that renders the input field (subclass of
>  > > > FormInputRenderer)
>  > > >  - Label (subclass of OutputLabelRenderer)
>  > > >  - Message (subclass of MessageRenderer)
>  > > >
>  > > > and many more...
>  > > >
>  > > > As this may look like "good practice", it makes life hell for the
>  > > developers
>  > > >  that want to customize/override these renderers.
>  > > >
>  > > > I have 2 possible solutions:
>  > > >
>  > > > 1. make some xml config file that maps a "sub-renderer" type to a
>  > > renderer
>  > > > class
>  > > > I know this might look like the old uix practice, but it's for a
>  > > differernt
>  > > > reason.
>  > > >  With a small xsd and some docs, this will be much more transparent.
>  > > >
>  > > > 2. at least have protected getters that return a renderer instance
>  > > > either for using the default defined sub-renderer in an overriden 
> method
>  > > >  or just for overriding that sub-renderer itself
>  > > >
>  > > > I personally like the 1st solution more, because it's easier to 
> override
>  > > > sub-renderers
>  > > > defined in a super class of more renderers (LabelAndMessageRenderer)
>  > > >
>  > > > Opinions, suggestions, other solutions?
>  > > >
>  > > > regards
>  > > >
>  > > > --
>  > > > Cristi Toth
>  > > >
>  > > > -
>  > > > Codebeat
>  > > > www.codebeat.ro
>  > >
>  >
>  >
>  >
>  > --
>  > Cristi Toth
>  >
>  > -
>  > Codebeat
>  > www.codebeat.ro
>  >
>
>
>  --
>
>  http://www.irian.at
>
>  Your JSF powerhouse -
>  JSF Consulting, Development and
>  Courses in English and German
>
>  Professional Support for Apache MyFaces
>

[Shale Clay]

[Zheng, Xiahong]

I couldn't seem to understand by looking at the clay usecase example.
Can somebody post an example of using clay to generate a dynamic table
element, the equivalent of the JSF h:dataTable tag? 
 
 

Re: [Trinidad] private / protected final methods in renderers

[Andrew Robinson]

+1 for:
- removing most final modifiers
- going from private to protected on most renderer methods
- and adding more customization hooks in the renderers

I also think that these should not be made backwards compatible.
Basically a use at your own risk deal. That way Trinidad developers
have the freedom to refactor and improve renderers and users have the
ability to customize them with an assumed amount of risk.

-Andrew

On Thu, Apr 10, 2008 at 12:57 AM, Martin Marinschek
<[EMAIL PROTECTED]> wrote:
> And here again, I can only support Cristi - Trinidad has clearly said
>  that the renderers are part of the implementation (it is even in the
>  package name!). People know implementation code might change its API
>  in the next version, so there is no sense in enforcing this on the
>  source level...
>
>  regards,
>
>  Martin
>
>
>
>  On 4/10/08, Cristi Toth <[EMAIL PROTECTED]> wrote:
>  > One more thing,
>  >
>  > Trinidad now being open-source means that it should be really open
>  > for those advanced developers that dive into the code.
>  >
>  > On Thu, Apr 10, 2008 at 8:11 AM, Cristi Toth <[EMAIL PROTECTED]> wrote:
>  >
>  > > Well, between having developers not being able to override some simple
>  > > behaviour
>  > > and keeping backwards compatibility on subclassers,
>  > > I'll choose the 2nd one.
>  > >
>  > > This is the reason that some components from tomahawk,
>  > > that are less feature-enabled that thos in Trinidad,
>  > > are considered more flexible and easier to customize than the ones in
>  > > Trinidad.
>  > >
>  > > Quite some experienced MyFaces developers told me to
>  > > "forget" overriding table and input renderers in Trinidad
>  > > (some of the most frequently used renderers).
>  > >
>  > >
>  > > So between not having a feature at all and being careful not to break
>  > > backwards compatibility on some methods,
>  > > the second one doesn't seem that bad, but the first one does.
>  > >
>  > > regards,
>  > >
>  > >
>  > > On Thu, Apr 10, 2008 at 2:39 AM, Blake Sullivan
>  > <[EMAIL PROTECTED]>
>  > > wrote:
>  > >
>  > > >  The reason is that each time we make one of these methods protected, 
> we
>  > > > have to guarantee that we will maintain the semantics of that hook 
> until
>  > the
>  > > > end-of-time or risk breaking users of that hook.  By slowly opening up
>  > the
>  > > > api we get the developers to tell us what they need and can weigh the
>  > > > benefit against the support cost.  If the hooks don't require that 
> super
>  > be
>  > > > called, in many ways, it is safer to completely override the function.
>  > > >
>  > > > This is the general issue of the competing desires to make it easy to
>  > > > tweak a renderer by subclassing without needing to completely replace 
> it
>  > vs.
>  > > > a desire to be able to change the Renderer implementation without
>  > breaking
>  > > > subclassers.  I actually think that we went too far in providing lots 
> of
>  > > > subclasser knobs in Trinidad, but that's just my opinion.
>  > > >
>  > > > -- Blake Sullivan
>  > > >
>  > > > Cristi Toth said the following On 4/9/2008 5:23 PM PT:
>  > > >
>  > > > Hi guys,
>  > > >
>  > > > A lot of Trinidad renderers have some "override useful" methods as
>  > > > private or protected final.
>  > > > This makes customizing renderers a nasty job.
>  > > >
>  > > > - first these methods obviously can't be overriden
>  > > > - then when trying to override some public/protected methods,
>  > > >   it's hard because they use other private methods that you can't use 
> in
>  > > > your overriden method
>  > > >
>  > > > I assume this come from the fact that Trinidad wasn't open-source in 
> its
>  > > > origins... or?
>  > > > Do we still have reasons to keep it this way?
>  > > >
>  > > > IMO we could make those protected final "override useful" methods to
>  > > > protected
>  > > > and the private methods used in those methods, make them protected
>  > > > final.
>  > > >
>  > > > What's you opinion on this?
>  > > >
>  > > > Regards,
>  > > > --
>  > > > Cristi Toth
>  > > >
>  > > > -
>  > > > Codebeat
>  > > > www.codebeat.ro
>  > > >
>  > > >
>  > > >
>  > >
>  > >
>  > > --
>  > > Cristi Toth
>  > >
>  > > -
>  > > Codebeat
>  > > www.codebeat.ro
>  > >
>  >
>  >
>  >
>  > --
>  > Cristi Toth
>  >
>  > -
>  > Codebeat
>  > www.codebeat.ro
>  >
>
>
>  --
>
>  http://www.irian.at
>
>  Your JSF powerhouse -
>  JSF Consulting, Development and
>  Courses in English and German
>
>  Professional Support for Apache MyFaces
>

Re: [Shale Clay]

[Andrew Robinson]

Wrong mailing list. This is for MyFaces committers only. Please send
your mail to the shale list.

On Thu, Apr 10, 2008 at 11:23 AM, Zheng, Xiahong <[EMAIL PROTECTED]> wrote:
>
>
> I couldn't seem to understand by looking at the clay usecase example. Can
> somebody post an example of using clay to generate a dynamic table element,
> the equivalent of the JSF h:dataTable tag?
>
>

[jira] Commented: (TOMAHAWK-922) JSF-1.2: JspTilesViewHandlerImpl

[Jean-Marc Seigneur (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587732#action_12587732
 ] 

Jean-Marc Seigneur commented on TOMAHAWK-922:
-

I've also voted for this issue to be fixed. I was surprised to see a blank page 
when upgrading from MyFaces 1.1.5 that works with Tiles to 1.2.2 that doesn't 
work with Tiles.

> JSF-1.2: JspTilesViewHandlerImpl
> 
>
> Key: TOMAHAWK-922
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-922
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: Tiles
>Affects Versions: 1.1.5-SNAPSHOT
> Environment: MyFaces Tomahawk SVN HEAD + JSF-1.2_03 (Reference 
> implementation) + JDK-1.5.0_11 + Tomcat-6.0.10
>Reporter: Jesper Pedersen
>
> The JspTilesViewHandlerImpl doesn't work under JSF-1.2 (RI) as it doesn't 
> deliver any output.
> Steps:
> 1) Get myfaces-example-tiles-1.1.5-SNAPSHOT.war
> 2) Replace MyFaces-Core with JSF-1.2 (RI) in WEB-INF/lib
> 3) Deploy on Tomcat-6.0.10
> 4) Go to http://localhost:8080/myfaces-example-tiles-1.1.5-SNAPSHOT/
> Generated HTML:
> 
> 
>   
>   Myfaces - Tiles
>   
> 
> 
> Basically I'm unable to use Tomahawk under JSF-1.2 currently, so any pointers 
> on how to fix this issue or to provide more information would be great.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Please remove org.apache.myfaces.tobago version 1.0.16 from repo1.maven.org

[Bernd Bohmann]

Hello,

I have prepared the next release of apache-myfaces-tobago during the
ApacheCon Europe. Because of a network error I was not able to commit
the poms with the next development version. I rollback the release.
Unfortunatley the continuus integration server already deployed 1.0.16
to the rsync reposity
http://people.apache.org/repo/m1-ibiblio-rsync-repository/

I try to delete all the artifacts on the rsync repository, but the rsync
was to fast and has already copied some artifacts.

Can someone remove the artifacts for the 1.0.16 from repo1.maven.org.

Or what should I do?

Regards

Bernd

Re: [Trinidad] private / protected final methods in renderers

[Andy Schwartz]

On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
> +1 for:
>  - removing most final modifiers
>  - going from private to protected on most renderer methods

Not sure how much my opinion counts, since I am a new face around
here, but I am -1 on blindly removing most final modifiers, or
promoting most private methods to protected.  Methods may have been
intentionally marked as final by the Renderer author, eg. to enforce
the fact that the method is itself a convenience for some other method
which provides the actual implementation.  And many if not most of the
private methods are not necessarily good additions to the protected
API, since they were not designed with extensibility in mind.

I understand the desire for more flexibility, so if the community
feels this is important, then let's solve the problem.  However, I
don't think that the way to achieve this goal is by sacrificing basic
design principles.  If we want better protected APIs, then let's work
on adding them - arbitrarily removing most final/private modifiers
isn't the way to get there.

BTW, (referring back to early comments on this thread) I don't see how
this is an open vs. closed source issue.  The same API design
principles apply to both cases.

>  - and adding more customization hooks in the renderers

Now this sounds like a better idea.  In some cases this may mean
making existing final/private  methods non-final/protected, but we
should put some thought into which cases require this rather than
doing this in an arbitrary manner.

Andy

Re: [Trinidad] private / protected final methods in renderers

[Max Starets]

I completely agree with Andy, so I am -1 for removing protected
on most renderer methods as well.

Max

Andy Schwartz wrote:

  On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
  
  
+1 for:
 - removing most final modifiers
 - going from private to protected on most renderer methods

  
  
Not sure how much my opinion counts, since I am a new face around
here, but I am -1 on blindly removing most final modifiers, or
promoting most private methods to protected.  Methods may have been
intentionally marked as final by the Renderer author, eg. to enforce
the fact that the method is itself a convenience for some other method
which provides the actual implementation.  And many if not most of the
private methods are not necessarily good additions to the protected
API, since they were not designed with extensibility in mind.

I understand the desire for more flexibility, so if the community
feels this is important, then let's solve the problem.  However, I
don't think that the way to achieve this goal is by sacrificing basic
design principles.  If we want better protected APIs, then let's work
on adding them - arbitrarily removing most final/private modifiers
isn't the way to get there.

BTW, (referring back to early comments on this thread) I don't see how
this is an open vs. closed source issue.  The same API design
principles apply to both cases.

  
  
 - and adding more customization hooks in the renderers

  
  
Now this sounds like a better idea.  In some cases this may mean
making existing final/private  methods non-final/protected, but we
should put some thought into which cases require this rather than
doing this in an arbitrary manner.

Andy
  

Re: [Trinidad] private / protected final methods in renderers

[Andrew Robinson]

I wasn't suggesting blind removal. IMO final should rarely ever be
used, for open source it almost never does anyone any good. I would
suggest a renderer-by-renderer approach though, not method-by-method
as that would take too long to file that many bugs.

Right now Trinidad and facelets are by far the most inflexible open
source code I have worked with. Both over-use final and both assume
that out-of-the box behavior is enough fore everyone's needs. For
Trinidad renderers, many only expose encodeAll as protected then do
most of the work in private methods. As a result a person needing to
customize a renderer has to use copy & paste (generate an entirely new
renderer using the source of the core one) which really sucks for
maintenance.

-Andrew

On Thu, Apr 10, 2008 at 1:48 PM, Andy Schwartz
<[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
>  <[EMAIL PROTECTED]> wrote:
>  > +1 for:
>  >  - removing most final modifiers
>  >  - going from private to protected on most renderer methods
>
>  Not sure how much my opinion counts, since I am a new face around
>  here, but I am -1 on blindly removing most final modifiers, or
>  promoting most private methods to protected.  Methods may have been
>  intentionally marked as final by the Renderer author, eg. to enforce
>  the fact that the method is itself a convenience for some other method
>  which provides the actual implementation.  And many if not most of the
>  private methods are not necessarily good additions to the protected
>  API, since they were not designed with extensibility in mind.
>
>  I understand the desire for more flexibility, so if the community
>  feels this is important, then let's solve the problem.  However, I
>  don't think that the way to achieve this goal is by sacrificing basic
>  design principles.  If we want better protected APIs, then let's work
>  on adding them - arbitrarily removing most final/private modifiers
>  isn't the way to get there.
>
>  BTW, (referring back to early comments on this thread) I don't see how
>  this is an open vs. closed source issue.  The same API design
>  principles apply to both cases.
>
>
>  >  - and adding more customization hooks in the renderers
>
>  Now this sounds like a better idea.  In some cases this may mean
>  making existing final/private  methods non-final/protected, but we
>  should put some thought into which cases require this rather than
>  doing this in an arbitrary manner.
>
>  Andy
>

[jira] Commented: (TOMAHAWK-1226) PPRPanelGroup support for multiple forms in a page is broken

[Ernst Fastl (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587779#action_12587779
 ] 

Ernst Fastl commented on TOMAHAWK-1226:
---

In order to resolve this issue, I suggest that we introduce a PPRWindowCtrl 
which stores the triggers, patterns and so on.
PPRCtrl are at the moment connected to the form. That should only  be used for 
eventHandler connections. The rest should be
window bound IMO.

> PPRPanelGroup support for multiple forms in a page is broken
> 
>
> Key: TOMAHAWK-1226
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1226
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: PPRPanelGroup
>Affects Versions: 1.1.7-SNAPSHOT
>Reporter: Catalin Kormos
>Assignee: Ernst Fastl
> Fix For: 1.1.7-SNAPSHOT
>
>
> When a triggering element is part of another form than a triggered element, 
> PPRPanelGroup doesn't behave well. The cause is related to where the 
> triggered element is kept, and a possible solution is to keep it in the 
> "window" object.
> Please look in ppr.js at 
> "org.apache.myfaces.PPRCtrl.prototype.elementOnEventHandler" and at 
> "org.apache.myfaces.PPRCtrl.prototype.formSubmitReplacement"; replacing 
> this.triggeredElement with window.triggeredElement fixes the problem, but it 
> might not be the best solution. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] private / protected final methods in renderers

[Scott O'Bryan]

-1 - I agree with Andy and Max for the reasons Matthias stated.  Classes 
in the Trinidad impl are not to be used outside of trinidad itself.  
Only items in the API need to worry about extension outside of the 
renderkit.  As such, I think leaving things status quo is probably 
prudent.  Because this *IS* an OpenSource project, I suppose the 
community (or interested parties) could propose adding some of these 
components to the API, but I wholeheartedly disagree that we need to 
change the impl because someone wants to extend it.


Andrew Robinson wrote:

I wasn't suggesting blind removal. IMO final should rarely ever be
used, for open source it almost never does anyone any good. I would
suggest a renderer-by-renderer approach though, not method-by-method
as that would take too long to file that many bugs.

Right now Trinidad and facelets are by far the most inflexible open
source code I have worked with. Both over-use final and both assume
that out-of-the box behavior is enough fore everyone's needs. For
Trinidad renderers, many only expose encodeAll as protected then do
most of the work in private methods. As a result a person needing to
customize a renderer has to use copy & paste (generate an entirely new
renderer using the source of the core one) which really sucks for
maintenance.

-Andrew

On Thu, Apr 10, 2008 at 1:48 PM, Andy Schwartz
<[EMAIL PROTECTED]> wrote:
  

On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
 <[EMAIL PROTECTED]> wrote:
 > +1 for:
 >  - removing most final modifiers
 >  - going from private to protected on most renderer methods

 Not sure how much my opinion counts, since I am a new face around
 here, but I am -1 on blindly removing most final modifiers, or
 promoting most private methods to protected.  Methods may have been
 intentionally marked as final by the Renderer author, eg. to enforce
 the fact that the method is itself a convenience for some other method
 which provides the actual implementation.  And many if not most of the
 private methods are not necessarily good additions to the protected
 API, since they were not designed with extensibility in mind.

 I understand the desire for more flexibility, so if the community
 feels this is important, then let's solve the problem.  However, I
 don't think that the way to achieve this goal is by sacrificing basic
 design principles.  If we want better protected APIs, then let's work
 on adding them - arbitrarily removing most final/private modifiers
 isn't the way to get there.

 BTW, (referring back to early comments on this thread) I don't see how
 this is an open vs. closed source issue.  The same API design
 principles apply to both cases.


 >  - and adding more customization hooks in the renderers

 Now this sounds like a better idea.  In some cases this may mean
 making existing final/private  methods non-final/protected, but we
 should put some thought into which cases require this rather than
 doing this in an arbitrary manner.

 Andy

Re: [Trinidad] private / protected final methods in renderers

[Andy Schwartz]

Hi Andrew -

On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
> I wasn't suggesting blind removal.

Okay.  The use of the word "most" gave me that impression. :-)

> IMO final should rarely ever be used, for open source it almost never does
> anyone any good.

Final should be used for its intended purpose.  Sure, in some cases
final may be abused, but then those cases should be corrected.  That
doesn't mean that final should rarely be used - it should be used when
appropriate.

Again, I don't see how open vs. closed source comes into play here.
Good API design is good API design, whether open or closed source.

> I would suggest a renderer-by-renderer approach though, not method-by-method
>  as that would take too long to file that many bugs.

I am not sure I understand the difference between these approaches.
At some point somebody will need to evaluate specific methods to
determine whether changes are required.

Personally I prefer the approach that Blake alluded to, which is to
open things up as the need arises.  (I may have missed it, but I don't
remember seeing the particular offending cases which triggered this
discussion.)

>  Right now Trinidad and facelets are by far the most inflexible open
>  source code I have worked with. Both over-use final and both assume
>  that out-of-the box behavior is enough fore everyone's needs. For
>  Trinidad renderers, many only expose encodeAll as protected then do
>  most of the work in private methods. As a result a person needing to
>  customize a renderer has to use copy & paste (generate an entirely new
>  renderer using the source of the core one) which really sucks for
>  maintenance.

I don't understand this at all.  Why would anyone do that, vs. log an
issue, submit a patch, fix the problem, revel in the magic of open
source?

Is the issue here really that the renderers as a whole are considered
off-limits to subclassing, due to the fact that they are located in
trinidadinternal (not trinidadapi)?

Andy

Re: [Trinidad] private / protected final methods in renderers

[Scott O'Bryan]

The overuse of final is largely irrelevant in impl packages.  The reason 
is that removing a final allows the class to remain binary compatible 
and only items inside of the impl package should be extending the class.


In some cases, final helps ensure an implied contract.  In other words, 
if something is final, you know it's implemented nowhere else.  In API's 
I agree with Andy, final should be used only to enforce a contract that 
should not (can not) change.  Most commonly this is used on immutable 
classes/api but it has some other uses.


Scott

Andy Schwartz wrote:

Hi Andrew -

On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
  

I wasn't suggesting blind removal.



Okay.  The use of the word "most" gave me that impression. :-)

  

IMO final should rarely ever be used, for open source it almost never does
anyone any good.



Final should be used for its intended purpose.  Sure, in some cases
final may be abused, but then those cases should be corrected.  That
doesn't mean that final should rarely be used - it should be used when
appropriate.

Again, I don't see how open vs. closed source comes into play here.
Good API design is good API design, whether open or closed source.

  

I would suggest a renderer-by-renderer approach though, not method-by-method
 as that would take too long to file that many bugs.



I am not sure I understand the difference between these approaches.
At some point somebody will need to evaluate specific methods to
determine whether changes are required.

Personally I prefer the approach that Blake alluded to, which is to
open things up as the need arises.  (I may have missed it, but I don't
remember seeing the particular offending cases which triggered this
discussion.)

  

 Right now Trinidad and facelets are by far the most inflexible open
 source code I have worked with. Both over-use final and both assume
 that out-of-the box behavior is enough fore everyone's needs. For
 Trinidad renderers, many only expose encodeAll as protected then do
 most of the work in private methods. As a result a person needing to
 customize a renderer has to use copy & paste (generate an entirely new
 renderer using the source of the core one) which really sucks for
 maintenance.



I don't understand this at all.  Why would anyone do that, vs. log an
issue, submit a patch, fix the problem, revel in the magic of open
source?

Is the issue here really that the renderers as a whole are considered
off-limits to subclassing, due to the fact that they are located in
trinidadinternal (not trinidadapi)?

Andy
  

Re: [Trinidad] private / protected final methods in renderers

[Andrew Robinson]

final should only be used if extending a function would cause it to
break. Forcing someone to call the super method is something that
should be in JavaDoc, not as a final keyword. Final's true purpose is
to create unchangeable member vars and also protect code. For example,
if I have commercial software that checks a license, it should be
final. Basically, if you don't have a reason to use final, don't use
it.

Final is often used in closed source because there are support issues.
By making something final, it is easier to debug. In the open source
world customers can debug into the code themselves to see what
documentation may not be clear about.

Python goes further, it has no final, everything is mutable. The idea
is to give ppl. the power they need and let them shoot themselves in
the foot if they want to.

This isn't just a matter of principle. I challenge you to author a
real world application with Trinidad, and let me know if it is
possible while letting it look professional. I found that it is not,
it is very rigid, to the point of lack of usability. Many times I
would create my own components and my own renderers because the core
ones just didn't do what I needed them to do and the renderers were
all private & final.

Take for example the table which always renders the select all and
unselect all at the top of the table and has no way to customize it.
An argument could easily be made to enhance the component API to add
these configurable points, but there is no way to anticipate them all.
If the renderer was more extendable this would be possible.

-Andrew

On Thu, Apr 10, 2008 at 3:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> The overuse of final is largely irrelevant in impl packages.  The reason is
> that removing a final allows the class to remain binary compatible and only
> items inside of the impl package should be extending the class.
>
>  In some cases, final helps ensure an implied contract.  In other words, if
> something is final, you know it's implemented nowhere else.  In API's I
> agree with Andy, final should be used only to enforce a contract that should
> not (can not) change.  Most commonly this is used on immutable classes/api
> but it has some other uses.
>
>  Scott
>
>
>
>  Andy Schwartz wrote:
>
> > Hi Andrew -
> >
> > On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
> > <[EMAIL PROTECTED]> wrote:
> >
> >
> > > I wasn't suggesting blind removal.
> > >
> > >
> >
> > Okay.  The use of the word "most" gave me that impression. :-)
> >
> >
> >
> > > IMO final should rarely ever be used, for open source it almost never
> does
> > > anyone any good.
> > >
> > >
> >
> > Final should be used for its intended purpose.  Sure, in some cases
> > final may be abused, but then those cases should be corrected.  That
> > doesn't mean that final should rarely be used - it should be used when
> > appropriate.
> >
> > Again, I don't see how open vs. closed source comes into play here.
> > Good API design is good API design, whether open or closed source.
> >
> >
> >
> > > I would suggest a renderer-by-renderer approach though, not
> method-by-method
> > >  as that would take too long to file that many bugs.
> > >
> > >
> >
> > I am not sure I understand the difference between these approaches.
> > At some point somebody will need to evaluate specific methods to
> > determine whether changes are required.
> >
> > Personally I prefer the approach that Blake alluded to, which is to
> > open things up as the need arises.  (I may have missed it, but I don't
> > remember seeing the particular offending cases which triggered this
> > discussion.)
> >
> >
> >
> > >  Right now Trinidad and facelets are by far the most inflexible open
> > >  source code I have worked with. Both over-use final and both assume
> > >  that out-of-the box behavior is enough fore everyone's needs. For
> > >  Trinidad renderers, many only expose encodeAll as protected then do
> > >  most of the work in private methods. As a result a person needing to
> > >  customize a renderer has to use copy & paste (generate an entirely new
> > >  renderer using the source of the core one) which really sucks for
> > >  maintenance.
> > >
> > >
> >
> > I don't understand this at all.  Why would anyone do that, vs. log an
> > issue, submit a patch, fix the problem, revel in the magic of open
> > source?
> >
> > Is the issue here really that the renderers as a whole are considered
> > off-limits to subclassing, due to the fact that they are located in
> > trinidadinternal (not trinidadapi)?
> >
> > Andy
> >
> >
>
>

Re: [Trinidad] private / protected final methods in renderers

[Cristi Toth]

Well I think we don't see the problem in the same way.

What does good design mean in this case ...!?
Making some methods protected and remove the final for others doesn't hurt
Trinidad itself at all.
So you can't say this is bad design.

If the bad design refers to what we offer the clients, than this is
definitely wrong.
Because a quite a lot of clients that me or some of my collaborators have
interacted with,
have complained a lot about Trinidad code that's so CLOSED !!!
Many said that instead of trying a small feature to the trinidad table,
you better take the Tomahawk one, and add all the feature you need on it.
It's easier and cleaner.

The faces-config allows you to override any renderer for any component,
right !?
So renderers are meant to be overriden. (by the JSF spec)
This is the beauty of JSF, because it's so flexible and customizable.
How do you expect to override Trinidad renderers?
Copying all the code and make some small changes?
Imagine that overriding some behaviour of some larger renderers,
you have to override the whole renderer hierarchy (i.w.
LabelAndMessageRenderer).

Between duplicating the whole renderer code
and just having some protected renderer methods,
which sounds better in design?

If we talk about backwards compatibilty,
then imagine a whole duplicated renderer which isn't aware of any other
updated renderers...
And if a custom renderer developer gets a compile error after an update,
I assume it won't take him to much time to fix it...

If a renderer is not in the API, this means that it shouldn't be overriden
!?
Let's think a bit out of the box and try to figure what's best for the
client.
Because that's what matters most...

regards,

On Thu, Apr 10, 2008 at 11:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:

> The overuse of final is largely irrelevant in impl packages.  The reason
> is that removing a final allows the class to remain binary compatible and
> only items inside of the impl package should be extending the class.
>
> In some cases, final helps ensure an implied contract.  In other words, if
> something is final, you know it's implemented nowhere else.  In API's I
> agree with Andy, final should be used only to enforce a contract that should
> not (can not) change.  Most commonly this is used on immutable classes/api
> but it has some other uses.
>
> Scott
>
>
> Andy Schwartz wrote:
>
> > Hi Andrew -
> >
> > On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
> > <[EMAIL PROTECTED]> wrote:
> >
> >
> > > I wasn't suggesting blind removal.
> > >
> > >
> >
> > Okay.  The use of the word "most" gave me that impression. :-)
> >
> >
> >
> > > IMO final should rarely ever be used, for open source it almost never
> > > does
> > > anyone any good.
> > >
> > >
> >
> > Final should be used for its intended purpose.  Sure, in some cases
> > final may be abused, but then those cases should be corrected.  That
> > doesn't mean that final should rarely be used - it should be used when
> > appropriate.
> >
> > Again, I don't see how open vs. closed source comes into play here.
> > Good API design is good API design, whether open or closed source.
> >
> >
> >
> > > I would suggest a renderer-by-renderer approach though, not
> > > method-by-method
> > >  as that would take too long to file that many bugs.
> > >
> > >
> >
> > I am not sure I understand the difference between these approaches.
> > At some point somebody will need to evaluate specific methods to
> > determine whether changes are required.
> >
> > Personally I prefer the approach that Blake alluded to, which is to
> > open things up as the need arises.  (I may have missed it, but I don't
> > remember seeing the particular offending cases which triggered this
> > discussion.)
> >
> >
> >
> > >  Right now Trinidad and facelets are by far the most inflexible open
> > >  source code I have worked with. Both over-use final and both assume
> > >  that out-of-the box behavior is enough fore everyone's needs. For
> > >  Trinidad renderers, many only expose encodeAll as protected then do
> > >  most of the work in private methods. As a result a person needing to
> > >  customize a renderer has to use copy & paste (generate an entirely
> > > new
> > >  renderer using the source of the core one) which really sucks for
> > >  maintenance.
> > >
> > >
> >
> > I don't understand this at all.  Why would anyone do that, vs. log an
> > issue, submit a patch, fix the problem, revel in the magic of open
> > source?
> >
> > Is the issue here really that the renderers as a whole are considered
> > off-limits to subclassing, due to the fact that they are located in
> > trinidadinternal (not trinidadapi)?
> >
> > Andy
> >
> >
>
>


-- 
Cristi Toth

-
Codebeat
www.codebeat.ro

Re: [Trinidad] delegated sub-renderers

[Cristi Toth]

Ok, so if you are pro, which solution do you prefer?
And if the configurable one (1st) than what kind of implementation do you
think of?

On Thu, Apr 10, 2008 at 7:17 PM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:

> ++1
>
> On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek
> <[EMAIL PROTECTED]> wrote:
> > If you want to here my opinion: we need Trinidad to be as customizable
> >  as possible. People who do this customization will know what they are
> >  doing - and will know how to handle an upgrade to a new version. It is
> >  enough to say: this is part of the impl package - it might change from
> >  version to version, your own fault, if you extend it and it breaks!
> >
> >  IMHO, Adam is wrong in this regard.
> >
> >  regards,
> >
> >  Martin
> >
> >
> >
> >  On 4/10/08, Cristi Toth <[EMAIL PROTECTED]> wrote:
> >  > But what does the "open-source" mean then... ?
> >  > All the renderers are in the impl packages,
> >  > but that's the beauty of open-source...
> >  > you can customize something you need.
> >  > That's an advantage that we should not oversee.
> >  >
> >  > On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson <
> >  > [EMAIL PROTECTED]> wrote:
> >  >
> >  > > I am not sure if you will get much support as Trinidad has all the
> >  > > renderers in the impl package, and therefore should not be
> considered
> >  > > part of its api and also should not be extended. Fighting this and
> >  > > asking for more APIs in the past was fruitless for me, but then
> again
> >  > > that was when Adam Winer was the constant one to veto all
> >  > > improvements.
> >  > >
> >  > > On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth <[EMAIL PROTECTED]>
> wrote:
> >  > > > Hi,
> >  > > >
> >  > > > As you probably know, there are a lot of "composed" renderers in
> >  > > Trinidad
> >  > > > which delegate to other "sub"renderers to render parts of the
> component.
> >  > > > i.e. Table renderer delegates to:
> >  > > >   - NavBar(subclass of SelectRangeChoiceBarRenderer),
> >  > > >  - AllDetails (subclass of ShowDetailRenderer)
> >  > > >  - DetailColumnRenderer
> >  > > >
> >  > > > input fields renderers (subclasses of
> InputLabelAndMessageRenderer)
> >  > > delegate
> >  > > > to:
> >  > > >   - one renderer that renders the input field (subclass of
> >  > > > FormInputRenderer)
> >  > > >  - Label (subclass of OutputLabelRenderer)
> >  > > >  - Message (subclass of MessageRenderer)
> >  > > >
> >  > > > and many more...
> >  > > >
> >  > > > As this may look like "good practice", it makes life hell for the
> >  > > developers
> >  > > >  that want to customize/override these renderers.
> >  > > >
> >  > > > I have 2 possible solutions:
> >  > > >
> >  > > > 1. make some xml config file that maps a "sub-renderer" type to a
> >  > > renderer
> >  > > > class
> >  > > > I know this might look like the old uix practice, but it's for a
> >  > > differernt
> >  > > > reason.
> >  > > >  With a small xsd and some docs, this will be much more
> transparent.
> >  > > >
> >  > > > 2. at least have protected getters that return a renderer
> instance
> >  > > > either for using the default defined sub-renderer in an overriden
> method
> >  > > >  or just for overriding that sub-renderer itself
> >  > > >
> >  > > > I personally like the 1st solution more, because it's easier to
> override
> >  > > > sub-renderers
> >  > > > defined in a super class of more renderers
> (LabelAndMessageRenderer)
> >  > > >
> >  > > > Opinions, suggestions, other solutions?
> >  > > >
> >  > > > regards
> >  > > >
> >  > > > --
> >  > > > Cristi Toth
> >  > > >
> >  > > > -
> >  > > > Codebeat
> >  > > > www.codebeat.ro
> >  > >
> >  >
> >  >
> >  >
> >  > --
> >  > Cristi Toth
> >  >
> >  > -
> >  > Codebeat
> >  > www.codebeat.ro
> >  >
> >
> >
> >  --
> >
> >  http://www.irian.at
> >
> >  Your JSF powerhouse -
> >  JSF Consulting, Development and
> >  Courses in English and German
> >
> >  Professional Support for Apache MyFaces
> >
>



-- 
Cristi Toth

-
Codebeat
www.codebeat.ro

Re: [Trinidad] private / protected final methods in renderers

[Blake Sullivan]

Andrew Robinson said the following On 4/10/2008 1:36 PM PT:

I wasn't suggesting blind removal. IMO final should rarely ever be
used, for open source it almost never does anyone any good.
Really. Why would good programming practice in the closed source world 
be bad programming practice in open source?  If anything, it is easier 
to change these restrictions in open source, if necessary.


What you are really saying is that you disagree with the decisions made 
by the class designers with respect to the trade-offs between 
intertwining the subclasses and superclasses and the convenience of 
tweaking implementation.


There is a real cost to the maintainability and evolution of the 
superclasses if they are burdened with huge numbers of protected hooks.  
Especially if those hooks became protected without the necessary work 
to  nail down their precise contract.

 I would
suggest a renderer-by-renderer approach though, not method-by-method
as that would take too long to file that many bugs.

Right now Trinidad and facelets are by far the most inflexible open
source code I have worked with.
Functions are private or final because the class designer because those 
aren't designed extension points.  I suspect that Trinidad and Facelets 
are being honest about this.  I would be suspicious of a class with huge 
numbers of protected methods--it is doubtful that all of the possible 
interactions have actually been considered.


One of the advantages of open source is that it is easy to test opening 
up particular pieces and ask for your change to be approved.

 Both over-use final and both assume
that out-of-the box behavior is enough fore everyone's needs. For
Trinidad renderers, many only expose encodeAll as protected then do
most of the work in private methods. As a result a person needing to
customize a renderer has to use copy & paste (generate an entirely new
renderer using the source of the core one) which really sucks for
maintenance.
  
On the other hand, the renderer author gains isolation and the 
superclasses don't need to add every single hook that any possible 
subclasser might want.


If there really are huge chunks of interesting code that should be 
shared in this case, they can be broken out into utilities and shared 
that way.


-- Blake Sullivan

-Andrew

On Thu, Apr 10, 2008 at 1:48 PM, Andy Schwartz
<[EMAIL PROTECTED]> wrote:
  

On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
 <[EMAIL PROTECTED]> wrote:
 > +1 for:
 >  - removing most final modifiers
 >  - going from private to protected on most renderer methods

 Not sure how much my opinion counts, since I am a new face around
 here, but I am -1 on blindly removing most final modifiers, or
 promoting most private methods to protected.  Methods may have been
 intentionally marked as final by the Renderer author, eg. to enforce
 the fact that the method is itself a convenience for some other method
 which provides the actual implementation.  And many if not most of the
 private methods are not necessarily good additions to the protected
 API, since they were not designed with extensibility in mind.

 I understand the desire for more flexibility, so if the community
 feels this is important, then let's solve the problem.  However, I
 don't think that the way to achieve this goal is by sacrificing basic
 design principles.  If we want better protected APIs, then let's work
 on adding them - arbitrarily removing most final/private modifiers
 isn't the way to get there.

 BTW, (referring back to early comments on this thread) I don't see how
 this is an open vs. closed source issue.  The same API design
 principles apply to both cases.


 >  - and adding more customization hooks in the renderers

 Now this sounds like a better idea.  In some cases this may mean
 making existing final/private  methods non-final/protected, but we
 should put some thought into which cases require this rather than
 doing this in an arbitrary manner.

 Andy

Re: [Trinidad] private / protected final methods in renderers

[Scott O'Bryan]

But that is my point precisely.  We don't "offer" the impl classes to 
clients to extend.  Only the classes in the API.


Scott

Scott

Cristi Toth wrote:

Well I think we don't see the problem in the same way.

What does good design mean in this case ...!?
Making some methods protected and remove the final for others doesn't 
hurt Trinidad itself at all.

So you can't say this is bad design.

If the bad design refers to what we offer the clients, than this is 
definitely wrong.
Because a quite a lot of clients that me or some of my collaborators 
have interacted with,

have complained a lot about Trinidad code that's so CLOSED !!!
Many said that instead of trying a small feature to the trinidad table,
you better take the Tomahawk one, and add all the feature you need on it.
It's easier and cleaner.

The faces-config allows you to override any renderer for any 
component, right !?

So renderers are meant to be overriden. (by the JSF spec)
This is the beauty of JSF, because it's so flexible and customizable.
How do you expect to override Trinidad renderers?
Copying all the code and make some small changes?
Imagine that overriding some behaviour of some larger renderers,
you have to override the whole renderer hierarchy (i.w. 
LabelAndMessageRenderer).


Between duplicating the whole renderer code
and just having some protected renderer methods,
which sounds better in design?

If we talk about backwards compatibilty,
then imagine a whole duplicated renderer which isn't aware of any 
other updated renderers...

And if a custom renderer developer gets a compile error after an update,
I assume it won't take him to much time to fix it...

If a renderer is not in the API, this means that it shouldn't be 
overriden !?
Let's think a bit out of the box and try to figure what's best for the 
client.

Because that's what matters most...

regards,

On Thu, Apr 10, 2008 at 11:34 PM, Scott O'Bryan <[EMAIL PROTECTED] 
> wrote:


The overuse of final is largely irrelevant in impl packages.  The
reason is that removing a final allows the class to remain binary
compatible and only items inside of the impl package should be
extending the class.

In some cases, final helps ensure an implied contract.  In other
words, if something is final, you know it's implemented nowhere
else.  In API's I agree with Andy, final should be used only to
enforce a contract that should not (can not) change.  Most
commonly this is used on immutable classes/api but it has some
other uses.

Scott


Andy Schwartz wrote:

Hi Andrew -

On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
<[EMAIL PROTECTED]
> wrote:
 


I wasn't suggesting blind removal.
   



Okay.  The use of the word "most" gave me that impression. :-)

 


IMO final should rarely ever be used, for open source it
almost never does
anyone any good.
   



Final should be used for its intended purpose.  Sure, in some
cases
final may be abused, but then those cases should be corrected.
 That
doesn't mean that final should rarely be used - it should be
used when
appropriate.

Again, I don't see how open vs. closed source comes into play
here.
Good API design is good API design, whether open or closed source.

 


I would suggest a renderer-by-renderer approach though,
not method-by-method
 as that would take too long to file that many bugs.
   



I am not sure I understand the difference between these
approaches.
At some point somebody will need to evaluate specific methods to
determine whether changes are required.

Personally I prefer the approach that Blake alluded to, which
is to
open things up as the need arises.  (I may have missed it, but
I don't
remember seeing the particular offending cases which triggered
this
discussion.)

 


 Right now Trinidad and facelets are by far the most
inflexible open
 source code I have worked with. Both over-use final and
both assume
 that out-of-the box behavior is enough fore everyone's
needs. For
 Trinidad renderers, many only expose encodeAll as
protected then do
 most of the work in private methods. As a result a person
needing to
 customize a renderer has to use copy & paste (generate an
entirely new
 renderer using the source of the core one) which really
sucks for
 maintenance.
   



I don't understand this at all.  Why would anyone do that, vs.
log an
issue, submit a patch, fix

Re: [Trinidad] delegated sub-renderers

[Andrew Robinson]

#2, getter / factory-style methods for obtaining delegate renderers.

On Thu, Apr 10, 2008 at 4:02 PM, Cristi Toth <[EMAIL PROTECTED]> wrote:
> Ok, so if you are pro, which solution do you prefer?
> And if the configurable one (1st) than what kind of implementation do you
> think of?
>
>
>
> On Thu, Apr 10, 2008 at 7:17 PM, Andrew Robinson
> <[EMAIL PROTECTED]> wrote:
>
> > ++1
> >
> >
> >
> >
> > On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek
> > <[EMAIL PROTECTED]> wrote:
> > > If you want to here my opinion: we need Trinidad to be as customizable
> > >  as possible. People who do this customization will know what they are
> > >  doing - and will know how to handle an upgrade to a new version. It is
> > >  enough to say: this is part of the impl package - it might change from
> > >  version to version, your own fault, if you extend it and it breaks!
> > >
> > >  IMHO, Adam is wrong in this regard.
> > >
> > >  regards,
> > >
> > >  Martin
> > >
> > >
> > >
> > >  On 4/10/08, Cristi Toth <[EMAIL PROTECTED]> wrote:
> > >  > But what does the "open-source" mean then... ?
> > >  > All the renderers are in the impl packages,
> > >  > but that's the beauty of open-source...
> > >  > you can customize something you need.
> > >  > That's an advantage that we should not oversee.
> > >  >
> > >  > On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson <
> > >  > [EMAIL PROTECTED]> wrote:
> > >  >
> > >  > > I am not sure if you will get much support as Trinidad has all the
> > >  > > renderers in the impl package, and therefore should not be
> considered
> > >  > > part of its api and also should not be extended. Fighting this and
> > >  > > asking for more APIs in the past was fruitless for me, but then
> again
> > >  > > that was when Adam Winer was the constant one to veto all
> > >  > > improvements.
> > >  > >
> > >  > > On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth <[EMAIL PROTECTED]>
> wrote:
> > >  > > > Hi,
> > >  > > >
> > >  > > > As you probably know, there are a lot of "composed" renderers in
> > >  > > Trinidad
> > >  > > > which delegate to other "sub"renderers to render parts of the
> component.
> > >  > > > i.e. Table renderer delegates to:
> > >  > > >   - NavBar(subclass of SelectRangeChoiceBarRenderer),
> > >  > > >  - AllDetails (subclass of ShowDetailRenderer)
> > >  > > >  - DetailColumnRenderer
> > >  > > >
> > >  > > > input fields renderers (subclasses of
> InputLabelAndMessageRenderer)
> > >  > > delegate
> > >  > > > to:
> > >  > > >   - one renderer that renders the input field (subclass of
> > >  > > > FormInputRenderer)
> > >  > > >  - Label (subclass of OutputLabelRenderer)
> > >  > > >  - Message (subclass of MessageRenderer)
> > >  > > >
> > >  > > > and many more...
> > >  > > >
> > >  > > > As this may look like "good practice", it makes life hell for the
> > >  > > developers
> > >  > > >  that want to customize/override these renderers.
> > >  > > >
> > >  > > > I have 2 possible solutions:
> > >  > > >
> > >  > > > 1. make some xml config file that maps a "sub-renderer" type to a
> > >  > > renderer
> > >  > > > class
> > >  > > > I know this might look like the old uix practice, but it's for a
> > >  > > differernt
> > >  > > > reason.
> > >  > > >  With a small xsd and some docs, this will be much more
> transparent.
> > >  > > >
> > >  > > > 2. at least have protected getters that return a renderer
> instance
> > >  > > > either for using the default defined sub-renderer in an overriden
> method
> > >  > > >  or just for overriding that sub-renderer itself
> > >  > > >
> > >  > > > I personally like the 1st solution more, because it's easier to
> override
> > >  > > > sub-renderers
> > >  > > > defined in a super class of more renderers
> (LabelAndMessageRenderer)
> > >  > > >
> > >  > > > Opinions, suggestions, other solutions?
> > >  > > >
> > >  > > > regards
> > >  > > >
> > >  > > > --
> > >  > > > Cristi Toth
> > >  > > >
> > >  > > > -
> > >  > > > Codebeat
> > >  > > > www.codebeat.ro
> > >  > >
> > >  >
> > >  >
> > >  >
> > >  > --
> > >  > Cristi Toth
> > >  >
> > >  > -
> > >  > Codebeat
> > >  > www.codebeat.ro
> > >  >
> > >
> > >
> > >  --
> > >
> > >  http://www.irian.at
> > >
> > >  Your JSF powerhouse -
> > >  JSF Consulting, Development and
> > >  Courses in English and German
> > >
> > >  Professional Support for Apache MyFaces
> > >
> >
>
>
>
> --
>
> Cristi Toth
>
> -
> Codebeat
> www.codebeat.ro

Re: [Trinidad] private / protected final methods in renderers

[Scott O'Bryan]

The String package in Java is final.  It's like this because it's a 
fundimental non-mutable class and not having it final would cause headaches.


Below you mentioned not being able to create a good looking professional 
application with Trinidad.  If this is the case then perhaps we should 
fix the issue with Trinidad in order to MAKE this possible.  Extending 
impl classes is NOT the answer.


I guess my problem with this whole thread is that, as Blake pointed out, 
many of the API's in the Trinidad impl package are not well thought 
out.  Encouraging people to use them really limits the ability of the 
renderkit to evolve.  So what's the answer?  Rethink the API's that are 
needed, seek approval from the community, and move them to the API 
package.  I've done it with the ExternalContextUtils.  Don't make the 
mistake, however, of forcing Trinidad into supporting api's that are not 
well thought out.


Scott

Andrew Robinson wrote:

final should only be used if extending a function would cause it to
break. Forcing someone to call the super method is something that
should be in JavaDoc, not as a final keyword. Final's true purpose is
to create unchangeable member vars and also protect code. For example,
if I have commercial software that checks a license, it should be
final. Basically, if you don't have a reason to use final, don't use
it.

Final is often used in closed source because there are support issues.
By making something final, it is easier to debug. In the open source
world customers can debug into the code themselves to see what
documentation may not be clear about.

Python goes further, it has no final, everything is mutable. The idea
is to give ppl. the power they need and let them shoot themselves in
the foot if they want to.

This isn't just a matter of principle. I challenge you to author a
real world application with Trinidad, and let me know if it is
possible while letting it look professional. I found that it is not,
it is very rigid, to the point of lack of usability. Many times I
would create my own components and my own renderers because the core
ones just didn't do what I needed them to do and the renderers were
all private & final.

Take for example the table which always renders the select all and
unselect all at the top of the table and has no way to customize it.
An argument could easily be made to enhance the component API to add
these configurable points, but there is no way to anticipate them all.
If the renderer was more extendable this would be possible.

-Andrew

On Thu, Apr 10, 2008 at 3:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
  

The overuse of final is largely irrelevant in impl packages.  The reason is
that removing a final allows the class to remain binary compatible and only
items inside of the impl package should be extending the class.

 In some cases, final helps ensure an implied contract.  In other words, if
something is final, you know it's implemented nowhere else.  In API's I
agree with Andy, final should be used only to enforce a contract that should
not (can not) change.  Most commonly this is used on immutable classes/api
but it has some other uses.

 Scott



 Andy Schwartz wrote:



Hi Andrew -

On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:


  

I wasn't suggesting blind removal.




Okay.  The use of the word "most" gave me that impression. :-)



  

IMO final should rarely ever be used, for open source it almost never


does


anyone any good.




Final should be used for its intended purpose.  Sure, in some cases
final may be abused, but then those cases should be corrected.  That
doesn't mean that final should rarely be used - it should be used when
appropriate.

Again, I don't see how open vs. closed source comes into play here.
Good API design is good API design, whether open or closed source.



  

I would suggest a renderer-by-renderer approach though, not


method-by-method


 as that would take too long to file that many bugs.




I am not sure I understand the difference between these approaches.
At some point somebody will need to evaluate specific methods to
determine whether changes are required.

Personally I prefer the approach that Blake alluded to, which is to
open things up as the need arises.  (I may have missed it, but I don't
remember seeing the particular offending cases which triggered this
discussion.)



  

 Right now Trinidad and facelets are by far the most inflexible open
 source code I have worked with. Both over-use final and both assume
 that out-of-the box behavior is enough fore everyone's needs. For
 Trinidad renderers, many only expose encodeAll as protected then do
 most of the work in private methods. As a result a person needing to
 customize a renderer has to use copy & paste (generate an entirely new
 renderer using the source of the core one) which really sucks for
 maintenance.




I don't unde

Re: [Trinidad] delegated sub-renderers

[Scott O'Bryan]

So if this is the case (ie- people who extend impl expect things to 
break and know what they are doing), why is it so hard for these people 
to submit a patch to add a protected or remove a final?  Again, 
everything will remain binary compatible.


Scott

Cristi Toth wrote:

Ok, so if you are pro, which solution do you prefer?
And if the configurable one (1st) than what kind of implementation do 
you think of?


On Thu, Apr 10, 2008 at 7:17 PM, Andrew Robinson 
<[EMAIL PROTECTED] > 
wrote:


++1

On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek
<[EMAIL PROTECTED] >
wrote:
> If you want to here my opinion: we need Trinidad to be as
customizable
>  as possible. People who do this customization will know what
they are
>  doing - and will know how to handle an upgrade to a new
version. It is
>  enough to say: this is part of the impl package - it might
change from
>  version to version, your own fault, if you extend it and it breaks!
>
>  IMHO, Adam is wrong in this regard.
>
>  regards,
>
>  Martin
>
>
>
>  On 4/10/08, Cristi Toth <[EMAIL PROTECTED]
> wrote:
>  > But what does the "open-source" mean then... ?
>  > All the renderers are in the impl packages,
>  > but that's the beauty of open-source...
>  > you can customize something you need.
>  > That's an advantage that we should not oversee.
>  >
>  > On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson <
>  > [EMAIL PROTECTED]
> wrote:
>  >
>  > > I am not sure if you will get much support as Trinidad has
all the
>  > > renderers in the impl package, and therefore should not be
considered
>  > > part of its api and also should not be extended. Fighting
this and
>  > > asking for more APIs in the past was fruitless for me, but
then again
>  > > that was when Adam Winer was the constant one to veto all
>  > > improvements.
>  > >
>  > > On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth
<[EMAIL PROTECTED] > wrote:
>  > > > Hi,
>  > > >
>  > > > As you probably know, there are a lot of "composed"
renderers in
>  > > Trinidad
>  > > > which delegate to other "sub"renderers to render parts of
the component.
>  > > > i.e. Table renderer delegates to:
>  > > >   - NavBar(subclass of SelectRangeChoiceBarRenderer),
>  > > >  - AllDetails (subclass of ShowDetailRenderer)
>  > > >  - DetailColumnRenderer
>  > > >
>  > > > input fields renderers (subclasses of
InputLabelAndMessageRenderer)
>  > > delegate
>  > > > to:
>  > > >   - one renderer that renders the input field (subclass of
>  > > > FormInputRenderer)
>  > > >  - Label (subclass of OutputLabelRenderer)
>  > > >  - Message (subclass of MessageRenderer)
>  > > >
>  > > > and many more...
>  > > >
>  > > > As this may look like "good practice", it makes life hell
for the
>  > > developers
>  > > >  that want to customize/override these renderers.
>  > > >
>  > > > I have 2 possible solutions:
>  > > >
>  > > > 1. make some xml config file that maps a "sub-renderer"
type to a
>  > > renderer
>  > > > class
>  > > > I know this might look like the old uix practice, but
it's for a
>  > > differernt
>  > > > reason.
>  > > >  With a small xsd and some docs, this will be much more
transparent.
>  > > >
>  > > > 2. at least have protected getters that return a renderer
instance
>  > > > either for using the default defined sub-renderer in an
overriden method
>  > > >  or just for overriding that sub-renderer itself
>  > > >
>  > > > I personally like the 1st solution more, because it's
easier to override
>  > > > sub-renderers
>  > > > defined in a super class of more renderers
(LabelAndMessageRenderer)
>  > > >
>  > > > Opinions, suggestions, other solutions?
>  > > >
>  > > > regards
>  > > >
>  > > > --
>  > > > Cristi Toth
>  > > >
>  > > > -
>  > > > Codebeat
>  > > > www.codebeat.ro 
>  > >
>  >
>  >
>  >
>  > --
>  > Cristi Toth
>  >
>  > -
>  > Codebeat
>  > www.codebeat.ro 
>  >
>
>
>  --
>
>  http://www.irian.at
>
>  Your JSF powerhouse -
>  JSF Consulting, Development and
>  Courses in English and German
>
>  Professional Support for Apache MyFaces
>




--
Cristi Toth

-
Codebeat
www.codebeat.ro  

Re: [Trinidad] private / protected final methods in renderers

[Blake Sullivan]

Andrew Robinson said the following On 4/10/2008 2:55 PM PT:

final should only be used if extending a function would cause it to
break. Forcing someone to call the super method is something that
should be in JavaDoc, not as a final keyword.

Andy already listed other uses of final.

 Final's true purpose is
to create unchangeable member vars and also protect code. For example,
if I have commercial software that checks a license, it should be
final. Basically, if you don't have a reason to use final, don't use
it.
  
See Item 15 of Effective Java.  The rule is really the opposite.  If you 
haven't considered all of the ways in which overriding the function may 
break your class in the present and are willing to accept the 
limitations on evolving your class in the future, you should not allow 
the function to be overridden.


In cases like the impl package, where the class author has access to all 
of the potential subclasses, these rules can be relaxed somewhat, but 
the onus should still be on the potential subclasser to explain what 
they want to do and why.

Final is often used in closed source because there are support issues.
By making something final, it is easier to debug. In the open source
world customers can debug into the code themselves to see what
documentation may not be clear about.
  
This is just not true.  The final keyword is used to to prevent 
subclasses from establishing contracts that the superclass does not 
guarantee.  It is used to prevent semantic incompatibility from 
occurring between the super classes and the subclasses.  It doesn't 
matter if you are a subclasser extending open source or closed 
source--when you pick up a new patch of the superclass, you don't want 
your subclass to break.  Also, note that in many cases, closed source 
customers have full access to the source code for debugging.


Also note that is not simply a documentation issue--it is a class 
evolution issue.  The more that a superclass guarantees about its 
implementation (which is what protected methods do, the less that 
superclass is free to evolve its implementation.


-- Blake Sullivan

Python goes further, it has no final, everything is mutable. The idea
is to give ppl. the power they need and let them shoot themselves in
the foot if they want to.

This isn't just a matter of principle. I challenge you to author a
real world application with Trinidad, and let me know if it is
possible while letting it look professional. I found that it is not,
it is very rigid, to the point of lack of usability. Many times I
would create my own components and my own renderers because the core
ones just didn't do what I needed them to do and the renderers were
all private & final.

Take for example the table which always renders the select all and
unselect all at the top of the table and has no way to customize it.
An argument could easily be made to enhance the component API to add
these configurable points, but there is no way to anticipate them all.
If the renderer was more extendable this would be possible.

-Andrew

On Thu, Apr 10, 2008 at 3:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
  

The overuse of final is largely irrelevant in impl packages.  The reason is
that removing a final allows the class to remain binary compatible and only
items inside of the impl package should be extending the class.

 In some cases, final helps ensure an implied contract.  In other words, if
something is final, you know it's implemented nowhere else.  In API's I
agree with Andy, final should be used only to enforce a contract that should
not (can not) change.  Most commonly this is used on immutable classes/api
but it has some other uses.

 Scott



 Andy Schwartz wrote:



Hi Andrew -

On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:


  

I wasn't suggesting blind removal.




Okay.  The use of the word "most" gave me that impression. :-)



  

IMO final should rarely ever be used, for open source it almost never


does


anyone any good.




Final should be used for its intended purpose.  Sure, in some cases
final may be abused, but then those cases should be corrected.  That
doesn't mean that final should rarely be used - it should be used when
appropriate.

Again, I don't see how open vs. closed source comes into play here.
Good API design is good API design, whether open or closed source.



  

I would suggest a renderer-by-renderer approach though, not


method-by-method


 as that would take too long to file that many bugs.




I am not sure I understand the difference between these approaches.
At some point somebody will need to evaluate specific methods to
determine whether changes are required.

Personally I prefer the approach that Blake alluded to, which is to
open things up as the need arises.  (I may have missed it, but I don't
remember seeing the particular offending cases which triggered this
discussion.)



 

Re: [Trinidad] delegated sub-renderers

[Scott O'Bryan]

Sorry, this went to the wrong thread.  Please disregard.

Scott

Scott O'Bryan wrote:
So if this is the case (ie- people who extend impl expect things to 
break and know what they are doing), why is it so hard for these 
people to submit a patch to add a protected or remove a final?  Again, 
everything will remain binary compatible.


Scott

Cristi Toth wrote:

Ok, so if you are pro, which solution do you prefer?
And if the configurable one (1st) than what kind of implementation do 
you think of?


On Thu, Apr 10, 2008 at 7:17 PM, Andrew Robinson 
<[EMAIL PROTECTED] > 
wrote:


++1

On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek
<[EMAIL PROTECTED] >
wrote:
> If you want to here my opinion: we need Trinidad to be as
customizable
>  as possible. People who do this customization will know what
they are
>  doing - and will know how to handle an upgrade to a new
version. It is
>  enough to say: this is part of the impl package - it might
change from
>  version to version, your own fault, if you extend it and it 
breaks!

>
>  IMHO, Adam is wrong in this regard.
>
>  regards,
>
>  Martin
>
>
>
>  On 4/10/08, Cristi Toth <[EMAIL PROTECTED]
> wrote:
>  > But what does the "open-source" mean then... ?
>  > All the renderers are in the impl packages,
>  > but that's the beauty of open-source...
>  > you can customize something you need.
>  > That's an advantage that we should not oversee.
>  >
>  > On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson <
>  > [EMAIL PROTECTED]
> wrote:
>  >
>  > > I am not sure if you will get much support as Trinidad has
all the
>  > > renderers in the impl package, and therefore should not be
considered
>  > > part of its api and also should not be extended. Fighting
this and
>  > > asking for more APIs in the past was fruitless for me, but
then again
>  > > that was when Adam Winer was the constant one to veto all
>  > > improvements.
>  > >
>  > > On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth
<[EMAIL PROTECTED] > wrote:
>  > > > Hi,
>  > > >
>  > > > As you probably know, there are a lot of "composed"
renderers in
>  > > Trinidad
>  > > > which delegate to other "sub"renderers to render parts of
the component.
>  > > > i.e. Table renderer delegates to:
>  > > >   - NavBar(subclass of SelectRangeChoiceBarRenderer),
>  > > >  - AllDetails (subclass of ShowDetailRenderer)
>  > > >  - DetailColumnRenderer
>  > > >
>  > > > input fields renderers (subclasses of
InputLabelAndMessageRenderer)
>  > > delegate
>  > > > to:
>  > > >   - one renderer that renders the input field (subclass of
>  > > > FormInputRenderer)
>  > > >  - Label (subclass of OutputLabelRenderer)
>  > > >  - Message (subclass of MessageRenderer)
>  > > >
>  > > > and many more...
>  > > >
>  > > > As this may look like "good practice", it makes life hell
for the
>  > > developers
>  > > >  that want to customize/override these renderers.
>  > > >
>  > > > I have 2 possible solutions:
>  > > >
>  > > > 1. make some xml config file that maps a "sub-renderer"
type to a
>  > > renderer
>  > > > class
>  > > > I know this might look like the old uix practice, but
it's for a
>  > > differernt
>  > > > reason.
>  > > >  With a small xsd and some docs, this will be much more
transparent.
>  > > >
>  > > > 2. at least have protected getters that return a renderer
instance
>  > > > either for using the default defined sub-renderer in an
overriden method
>  > > >  or just for overriding that sub-renderer itself
>  > > >
>  > > > I personally like the 1st solution more, because it's
easier to override
>  > > > sub-renderers
>  > > > defined in a super class of more renderers
(LabelAndMessageRenderer)
>  > > >
>  > > > Opinions, suggestions, other solutions?
>  > > >
>  > > > regards
>  > > >
>  > > > --
>  > > > Cristi Toth
>  > > >
>  > > > -
>  > > > Codebeat
>  > > > www.codebeat.ro 
>  > >
>  >
>  >
>  >
>  > --
>  > Cristi Toth
>  >
>  > -
>  > Codebeat
>  > www.codebeat.ro 
>  >
>
>
>  --
>
>  http://www.irian.at
>
>  Your JSF powerhouse -
>  JSF Consulting, Development and
>  Courses in English and German
>
>  Professional Support for Apache MyFaces
>




--
Cristi Toth

-
Codebeat
www.codebeat.ro  

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello,

as mentioned: sev-en started as feasibility study. so there are some topics
i haven't cared about so far.
to keep it short: i would like to finish some tasks before we discuss
details. it's much more efficient to discuss the intermediate result after
this process.

(at the moment the concepts of the core are pretty stable.)

in the mean time i would suggest to open a vote concerning the myfaces
sub-project topic.

furthermore, some of you don't like the original/internal code-name.
is it enough to omit the hyphen?
(sev-en -> seven)
or do you have some fancy names in mind?

regards,
gerhard



2008/4/10, Matthias Wessendorf <[EMAIL PROTECTED]>:
>
> true!
>
>
> On Wed, Apr 9, 2008 at 8:28 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> > I think so too.  Having a sub-project of a sub-project might be a little
> > infrastructure heavy, there is nothing to say that Sev-en couldn't
> become
> > it's own MyFaces subproject that's intended to be used in a
> > MyFaces/Orchestra type environment.
> >
> >  I also agree it should my a MyFaces wide decision because it impacts
> > expectations on the renderkits.
> >
> >  Scott
> >
> >
> >
> >  Kito D. Mann wrote:
> >
> > > I think Mario has made some very good points...
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
> > > > Sent: Wednesday, April 09, 2008 5:14 AM
> > > > To: MyFaces Development
> > > > Subject: Re: [proposal] jsf validation with annotations
> > > >
> > > > Hi!
> > > >
> > > >
> > > > > my position on this is we could make sev-en part of orchestra, if
> the
> > > > > orchestra crew really, really wants it. If not, this should just
> be a
> > > > > separate sub-module in MyFaces. It is interesting enough to stand
> on
> > > > > its own.
> > > > >
> > > > >
> > > > >
> > > > First, Orchestra is part of the MyFaces community, so it really,
> really
> > > > should be a decision the MyFaces community felt, and not a
> "Orchestra
> > > > Team" only one.
> > > >
> > > > Anyway, I think this is a question on how we position Orchestra.
> > > > If it is a strong position against JBoss Seam, then it probably
> might
> > > > make sense to include everything which makes life easier for the
> > > > developer into Orchestra - just as Seam tries to do.
> > > > However, then we loose one of the strongest arguments pro Orchestra:
> > > > Being a lightweight Conversation-Centric Library.
> > > >
> > > > If, we could add it as sub-module to Orchestra, but I think the best
> > > > place for sev-en (would like to see a new name anyway) is to be a
> > > > submodule of MyFaces. But first I'd like to see the technical
> details
> > > > of
> > > > how the sev-en core works. e.g. in the examples I've seen a lot of
> > > > converter wrapper stuff ...
> > > >
> > > > Building an official MyFaces Maven Artifact which bootup a
> development
> > > > environment (MyFaces Fullstack) with what we think on need for
> > > > development of any-range-sized applications would be more approriate
> > > > then. Such a project could include sev-en too.
> > > >
> > > > Ciao,
> > > > Mario
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>
>
>
> --
>
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>



-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[jira] Commented: (MYFACES-1854) does not evaluates EL expressions

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587812#action_12587812
 ] 

Leonardo Uribe commented on MYFACES-1854:
-

Maybe if you try to load the bundle using:


>  does not evaluates EL expressions
> -
>
> Key: MYFACES-1854
> URL: https://issues.apache.org/jira/browse/MYFACES-1854
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 1.2.2
>Reporter: Guy Bashan
>
>  does not evaluates EL expressions. This, for example, makes 
> impossible to create multi-language dynamic drop down items.
> Example:
> -
> SelectItem selectItem = new SelectItem("-1",  
> "#{bundle['dropdown.advertiser.select']}")
> This EL expression will not be evaluated.
> In JSP value is evaluated:
>   
>  itemLabel="#{bundle['dropdown.advertiser.select'']}" />
>   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-1854) does not evaluates EL expressions

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587813#action_12587813
 ] 

Leonardo Uribe commented on MYFACES-1854:
-

Maybe if you try to load the bundle using:





org.apache.myfaces.examples.resource.example_messages

bundle



on your faces-config.xml, the bundle can be evaluated. If you are using 
f:loadBundle, this error could happen, because f:loadBundle add the reference 
on render response time.

Could you test if this workaround works?


>  does not evaluates EL expressions
> -
>
> Key: MYFACES-1854
> URL: https://issues.apache.org/jira/browse/MYFACES-1854
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 1.2.2
>Reporter: Guy Bashan
>
>  does not evaluates EL expressions. This, for example, makes 
> impossible to create multi-language dynamic drop down items.
> Example:
> -
> SelectItem selectItem = new SelectItem("-1",  
> "#{bundle['dropdown.advertiser.select']}")
> This EL expression will not be evaluated.
> In JSP value is evaluated:
>   
>  itemLabel="#{bundle['dropdown.advertiser.select'']}" />
>   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] xss files?

[Jeanne Waldman]

Andy is right in that we haven't nixed the XSS files yet because they 
have features in it that the base skins are using that the CSS

format does not yet support.

Andy's list looks good.
Another one is @imports. XSS does that. There's already an open JIRA 
issue on this.


Andy Schwartz wrote, On 4/6/2008 6:11 AM PT:

Hey Matthias, Andrew -

On Sun, Apr 6, 2008 at 7:07 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
  

On Sun, Apr 6, 2008 at 12:05 AM, Andrew Robinson
 <[EMAIL PROTECTED]> wrote:
 > When doing the panelBorderLayout enhancement, I had my first real
 >  opportunity to work on those xss files. I can't say as I enjoyed it
 >  that much. Is there any reason they exist, or is it simply that no one

 +1
 I hate them.




Ouch.  Well, it seemed like a good idea at the time, but that was a
long, long time ago (8 years ago). :-)

At the time I was concerned that modifying/enhancing the CSS language
in order to introduce the feature set that I needed would be
confusing/inappropriate, so decided to define the new features that I
needed via an XML wrapper.  However, looking back I am certainly glad
that we decided to change course and go down the CSS route.  On a
positive note, the underlying style handling code that I built for XSS
needed very little changing in order to support the new CSS-based
style definitions, so at least it wasn't a total waste of time. :-)

In any case, I am totally in favor of converting the remaining XSS over to CSS.

  

 Jeanne, is that "legacy"?

 >  has bothered converting them over to CSS?

 I'd not mind... but let's wait for others.



There are a small number of features of XSS that we never had time to
port to the CSS-based style definitions.  A couple that come to mind
are:

1. Language/locale-specific styles.
2. (Browser) version-specific styles.

Both of these should be fairly easy to support.  I would be happy to
add support for these if I can find the bandwidth (though bit
stretched thin at the moment).

It also looks like at some point since I was last actively working on
this we added a "mode" (standards vs quirks) feature to XSS.  Not sure
whether this is already present in our CSS implementation.  Currently
the "mode" feature only seems to be used for some IE/PPC styles
defined in base-desktop.xss.  It is possible these are no longer
needed (I can check with our mobile guys over here to see for sure.)

Oh, and looking at base-desktop.xss, one other feature of XSS that we
might not yet support in CSS is the  mechanism, which
allows one style to pull in a single property value from another
style, and optionally modify the style property name locally.  This
was used for one purpose only... It allowed us to define our color
ramps in a single location, and use those colors both as background
(ie. "background-color") as well as foreground (ie. "color") color
properties.

Jeanne would know if there are other features beyond these that also
need to be ported to our CSS implementation before we can kill off
XSS.

Andy

  

Re: [Trinidad] private / protected final methods in renderers

[Andrew Robinson]

The thing is, is not what is the strive for the perfect architecture,
but what is the best way make Trinidad the easiest to use to develop
business applications with (not saying the architecture should not be
solid, just that trying to make an architecture that provides
everyones needs for every use case is not feasible). Adding APIs to
components is not the full solution, and neither is substituting out
core renderers with custom ones.

There will always be use cases where it is necessary for users to want
or need to change specific parts of how core renderers while wanting
the majority of the core renderer's functionality. However this is
done, the user should be able to have access to alter certain things
without hacking dangerously deep into the Trinidad code to do so and
risk backwards compatibility.

Adding API code at the component levels does help, but it will not
address the ability to alter how one component renders for an entire
application. Skinning allows this, to be able to completely re-skin
all of the core components. So there is an extremely good argument to
be able to allow users to extend core renderers.

What about a compromise?

Have renderer wrapper classes or interfaces in trinidad-api and then
have their implementation in the trinidad-impl. Every major area of
the rendered component should have hooks as well as all child renderer
delegation passed into the wrapper (with a default implementation in
impl). For example, take the popup component. I could see hooks for
delegation of the trigger rendering, of the popup itself (title bar,
frame, close button, etc.) and of the popup children.

This way (1) there is a declared standard API for trinidad renderers,
(2) the amount exposed to the API is clearly exposed, (3) making
factory methods for delegating child renderers greatly enhances
extensibility and (4) exposing core areas of rendering components.

One use case would be to change the toolbar of the table. Instead of
having to customize each table used in an application and have
component attributes for changing the select all behavior, a person
could simply override a renderToolbar function.

Maybe something like this for popups:

public abstract class PopupRendererWrapper
{
  private PopupRendererWrapper _base;
  public PopupRendererWrapper(PopupRendererWrapper base) { _base = base; }

  public void renderTitleBar(FacesContext context, RenderingContext
rc, UIComponent component, FacesBean bean)
  {
_base.renderTitleBar(context, rc, component, bean);
  }
  ...
}

I didn't put a whole lot of thought into this yet, but maybe this will
start some thinking that is a compromise to making the renderers part
of the API with everything public/protected and non-final vs. having
no way to extend the renderers. But the idea is that the renderer just
calls the wrapper functions to do most of the work (basically uses a
delegate renderer to do all the work), but creates its own out-of-the
box version that can be wrapped by a user.

Any of this sound like something to pursue?

-Andrew

Re: [Trinidad] private / protected final methods in renderers

[Andrew Robinson]

Okay, I have yet another approach that I thought of while walking my
dogs that is much more JSF-ish and goes along with Christi's email on
sub-renderers.

Instead creating a whole bloody wrapper API framework that would make
the API hard to change, what about breaking the renderers down even
more into subclasses.

Take the tr:panelPopup for example again. It has:
Outer container
Trigger
Popup
  Title bar
  Close button
  Body

So lets say this is how the renderer could be built:
First, create a bunch of renderer types:
org.apache.myfaces.trinidad.Popup
org.apache.myfaces.trinidad.Popup.Trigger
org.apache.myfaces.trinidad.Popup.PopupShell
org.apache.myfaces.trinidad.Popup.TitleBar
org.apache.myfaces.trinidad.Popup.ButtonArea
org.apache.myfaces.trinidad.Popup.Body

Then register a default renderer for each of these types.

Then the PanelPopupRenderer would in encodeAll:

render outer DIV (ppr stuff)
call a render utils method to get the renderer for the trigger and encode it
call a render utils method to get the renderer for the popup shell and encode it

in the popup shell renderer:
encode the outer HTML
call a render utils method to get the renderer for the title bar and encode it
call a render utils method to get the renderer for the popup body and encode it

in the title bar renderer:
encode the outer HTML
encode the title
call a render utils method to get the renderer for the button area and encode it

in the body renderer:
encode the outer HTML
encode the children components

This way there are many renderers to one component. The renderers
would be registered in the faces-config.xml just like any ordinary
renderers. Since the FacesBean allows renderers to encode any
component that has certain property keys, this is ideal.

Take for example the close button on the popup, we could have a faces
bean alias wrapper. What I mean by this is something like this:

public class PopupTitleBarRenderer extends XhtmlRenderer {
  protected void encodeAll(FacesContext context, RenderingContext rc,
UIComponent component, FacesBean bean) throws IOException {
FacesBean wrapped = new AliasedFacesBean(bean);
wrapped.map("text", "title");
...

This way a command button renderer could be used to render the close
button using the title from the dialog as the text of the button.

Using this way, the only exposed API are the sub-renderer types that
can be defined in the faces config. New types can be added and old
ones removed without breaking Java interfaces or abstract class APIs
(although it would have to be controlled to not break custom code too
badly).

-Andrew

[jira] Commented: (MYFACES-1842) commandLink with parameters behaves differently in Firefox and IE

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587828#action_12587828
 ] 

Leonardo Uribe commented on MYFACES-1842:
-


I have modified the helloworld example created using myfaces archetypes to see 
the problem, and made some test about this.

After checking this issues on IE 7.0.5730.11 and firefox 2.0.0.13 I have the 
following behavior when I do a double click.

1. On IE submits the expected query string on the first click. The page goes to 
a second page, so nothing wrong shown here.

2. On Firefox, submits the expected query string on both clicks, so on the 
helloworld example the page is first shown well and the second all submitted 
values are null, so the name is null too.

 Myfaces render the hidden fields before the end of the form, which cause 
compatibility problems when someone does not use h:form to encapsulate a form. 
Mojarra or jsf ri does not, instead create the hidden fields before submit 
(including the hidden fields for params), submit the form an then remove the 
hidden fields to avoid unwanted effects. Myfaces set the hidden fields (if it 
is not rendered on the form creates it), submit the form and then set the 
values of the hidden fields to null. 

 I have noted that autoscroll feature available when using tomahawk + myfaces 
uses oamSetHiddenInput instead render the hidden autoscroll part.

After thinking a lot (A LOT!!) about this problem, the best for solve this 
problem is do not render hidden fields for this case, but let the code for 
hidden fields (compatibility with tomahawk, since jscookmenu use this feature, 
this should change in a future release). Instead, for h:commandLink, set and 
remove the hidden fields using javascript.

Maybe we can do some workaround to avoid this effect on firefox. I will look 
this and see what happens



> commandLink with parameters behaves differently in Firefox and IE
> -
>
> Key: MYFACES-1842
> URL: https://issues.apache.org/jira/browse/MYFACES-1842
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions:  1.2.0
> Environment: Windows XP, MyFaces 1.2.0, Jetty, Firefox 2.0.0.12, IE 
> 7.0.570.11
>Reporter: Neil Curzon
>Assignee: Leonardo Uribe
>
> When I have a commandLink element with a parameter, and double click on the 
> link, I get different behavior in IE and Firefox.
> IE submits the expected query string on the first click, but on the second 
> click generates a query string with the parameter listed twice, both times 
> with the correct value, in its name value pairs.
> Firefox submits the expected query string on both clicks.
> The culprit may be the oamSubmitForm javascript.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-1842) commandLink with parameters behaves differently in Firefox and IE

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587846#action_12587846
 ] 

Leonardo Uribe commented on MYFACES-1842:
-

I will move the problem of hidden fields to another issue and then fix bug with 
firefox in this issue

> commandLink with parameters behaves differently in Firefox and IE
> -
>
> Key: MYFACES-1842
> URL: https://issues.apache.org/jira/browse/MYFACES-1842
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions:  1.2.0
> Environment: Windows XP, MyFaces 1.2.0, Jetty, Firefox 2.0.0.12, IE 
> 7.0.570.11
>Reporter: Neil Curzon
>Assignee: Leonardo Uribe
>
> When I have a commandLink element with a parameter, and double click on the 
> link, I get different behavior in IE and Firefox.
> IE submits the expected query string on the first click, but on the second 
> click generates a query string with the parameter listed twice, both times 
> with the correct value, in its name value pairs.
> Firefox submits the expected query string on both clicks.
> The culprit may be the oamSubmitForm javascript.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (MYFACES-1855) hidden fields created when using h:commandLink and f:param should be created and removed using javascript

[Leonardo Uribe (JIRA)]

hidden fields created when using h:commandLink and f:param should be created 
and removed using javascript
-

 Key: MYFACES-1855
 URL: https://issues.apache.org/jira/browse/MYFACES-1855
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Myfaces render the hidden fields before the end of the form, which cause 
compatibility problems when someone does not use h:form to encapsulate a form. 
Mojarra or jsf ri does not, instead create the hidden fields before submit 
(including the hidden fields for params), submit the form an then remove the 
hidden fields to avoid unwanted effects. Myfaces set the hidden fields (if it 
is not rendered on the form creates it), submit the form and then set the 
values of the hidden fields to null.

 I have noted that autoscroll feature available when using tomahawk + myfaces 
uses oamSetHiddenInput instead render the hidden autoscroll part.

After thinking a lot (A LOT!!) about this problem, the best for solve this 
problem is do not render hidden fields for this case, but let the code for 
hidden fields (compatibility with tomahawk, since jscookmenu use this feature, 
this should change in a future release). Instead, for h:commandLink, set and 
remove the hidden fields using javascript.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (MYFACES-1856) h:commandLink with target="_blank" does not work

[Leonardo Uribe (JIRA)]

h:commandLink with target="_blank" does not work


 Key: MYFACES-1856
 URL: https://issues.apache.org/jira/browse/MYFACES-1856
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Leonardo Uribe


The problem is here:

function oamSubmitForm(formName, linkId, target, params)
{   
   /*..*/
if((typeof target=='function') && target != null)
{
oldTarget=document.forms[formName].target;
document.forms[formName].target=target;
}

maybe we should do this instead

if( target != null)

or maybe
 
if(typeof target!='undefined')

I will take a look to see what is better

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (MYFACES-1857) h:commandLink with onclick="customFunction" does not do what taglib javadoc of jsf ri suggest to do

[Leonardo Uribe (JIRA)]

h:commandLink with onclick="customFunction" does not do what taglib javadoc of 
jsf ri suggest to do
---

 Key: MYFACES-1857
 URL: https://issues.apache.org/jira/browse/MYFACES-1857
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


The page 
http://java.sun.com/javaee/javaserverfaces/1.2/docs/tlddocs/h/commandLink.html 
says this:

If an "onclick" attribute was specified by the user, render this JavaScript in 
a function, and render the user's JavaScript in a function. Render both 
functions in a choice function as follows:

var a=function(){#USER_FUNCTION#}; var b=function(){#JSF_FUNCTION#}; return 
(a()==false) ? false : b();

where #USER_FUNCTION# is the user's JavaScript and #JSF_FUNCTION# is the 
JavaScript rendered by JSF. The choice function should operate such that if the 
user's JavaScript returns true, then the rendered JavaScript will also execute.

Myfaces should do this as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (MYFACES-1855) hidden fields created when using h:commandLink and f:param should be created and removed using javascript

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587862#action_12587862
 ] 

Mario Ivankovits commented on MYFACES-1855:
---

It would be really great if you could externalize the javascript too. Currently 
it is simply inlined into the source, which looks not very professional I think.

> hidden fields created when using h:commandLink and f:param should be created 
> and removed using javascript
> -
>
> Key: MYFACES-1855
> URL: https://issues.apache.org/jira/browse/MYFACES-1855
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 1.2.2
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> Myfaces render the hidden fields before the end of the form, which cause 
> compatibility problems when someone does not use h:form to encapsulate a 
> form. Mojarra or jsf ri does not, instead create the hidden fields before 
> submit (including the hidden fields for params), submit the form an then 
> remove the hidden fields to avoid unwanted effects. Myfaces set the hidden 
> fields (if it is not rendered on the form creates it), submit the form and 
> then set the values of the hidden fields to null.
>  I have noted that autoscroll feature available when using tomahawk + myfaces 
> uses oamSetHiddenInput instead render the hidden autoscroll part.
> After thinking a lot (A LOT!!) about this problem, the best for solve this 
> problem is do not render hidden fields for this case, but let the code for 
> hidden fields (compatibility with tomahawk, since jscookmenu use this 
> feature, this should change in a future release). Instead, for h:commandLink, 
> set and remove the hidden fields using javascript.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] private / protected final methods in renderers

[Martin Marinschek]

Hi Scott,

your statement is really irrelevant - in JSF, renderers are designed
to be extended/exchanged. JSF has been built this way. Trinidad (or
where Trinidad comes from) tries to make this impossible, out of
support reasons inside Oracle. If you go into a wider space, and want
Trinidad to be accepted by more people than just Oracle clients, you
will need to allow them (if they find out the behaviour of the
existing renderers does not fit their use-case well enough) to extend
and override the existing behaviour. You can certainly tell them that
they are not in a safe land if they do this, but you should not
prohibit it.

It is much like the time of the "Prohibition" in the US - what is
better - telling people it is not safe to override renderers (=drink
alcohol), but allowing them to do so still, and most people will do it
appropriately (=drink in moderation) and just fix a problem in the
upgrade when it arises, or prohibit it by making everything final and
private (=prohibition of drinking alcohol completely), which overly
restricts what people may want to do and will lead to something close
to a revolution.

I can certainly accept Andy's and Blake's statements - let us not open
everything, but decide on a case-by-case base what to open up (in
reality, we did the same in Tomahawk, in the beginning, most of our
methods where private as well, now a lot of hooks have been changed to
be protected - where clients actually felt the need to override
something), but I cannot accept your statement - this is dangerous for
Trinidad and its community. You should change your opinion in this
case! Once again: I can accept that renderers are not _meant_ to be
overriden, but I cannot accept that it is completely _prohibited_ to
do so.

Now I know that Cristi is actually working with Trinidad, and that he
has a problem, namely he would need to be able to override/replace
sub-renderers for a clients design-issue. This is a concrete problem,
and if he wants to address it, we should allow him so - and I
definitely feel it should be addressed, if you take the general spirit
of JSF, which allows a lot of flexibility.

regards,

Martin

On 4/11/08, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> But that is my point precisely.  We don't "offer" the impl classes to
> clients to extend.  Only the classes in the API.
>
> Scott
>
> Scott
>
> Cristi Toth wrote:
> > Well I think we don't see the problem in the same way.
> >
> > What does good design mean in this case ...!?
> > Making some methods protected and remove the final for others doesn't
> > hurt Trinidad itself at all.
> > So you can't say this is bad design.
> >
> > If the bad design refers to what we offer the clients, than this is
> > definitely wrong.
> > Because a quite a lot of clients that me or some of my collaborators
> > have interacted with,
> > have complained a lot about Trinidad code that's so CLOSED !!!
> > Many said that instead of trying a small feature to the trinidad table,
> > you better take the Tomahawk one, and add all the feature you need on it.
> > It's easier and cleaner.
> >
> > The faces-config allows you to override any renderer for any
> > component, right !?
> > So renderers are meant to be overriden. (by the JSF spec)
> > This is the beauty of JSF, because it's so flexible and customizable.
> > How do you expect to override Trinidad renderers?
> > Copying all the code and make some small changes?
> > Imagine that overriding some behaviour of some larger renderers,
> > you have to override the whole renderer hierarchy (i.w.
> > LabelAndMessageRenderer).
> >
> > Between duplicating the whole renderer code
> > and just having some protected renderer methods,
> > which sounds better in design?
> >
> > If we talk about backwards compatibilty,
> > then imagine a whole duplicated renderer which isn't aware of any
> > other updated renderers...
> > And if a custom renderer developer gets a compile error after an update,
> > I assume it won't take him to much time to fix it...
> >
> > If a renderer is not in the API, this means that it shouldn't be
> > overriden !?
> > Let's think a bit out of the box and try to figure what's best for the
> > client.
> > Because that's what matters most...
> >
> > regards,
> >
> > On Thu, Apr 10, 2008 at 11:34 PM, Scott O'Bryan <[EMAIL PROTECTED]
> > > wrote:
> >
> > The overuse of final is largely irrelevant in impl packages.  The
> > reason is that removing a final allows the class to remain binary
> > compatible and only items inside of the impl package should be
> > extending the class.
> >
> > In some cases, final helps ensure an implied contract.  In other
> > words, if something is final, you know it's implemented nowhere
> > else.  In API's I agree with Andy, final should be used only to
> > enforce a contract that should not (can not) change.  Most
> > commonly this is used on immutable classes/api but it has some
> > other uses.
> >
> > Scot

Re: [Trinidad] private / protected final methods in renderers

[Martin Marinschek]

Sounds like a reasonable suggestion - I would love to be able to
replace/extend small chunks of code, not having to rewrite/copy the
renderer-code fully, so this suggestion might go into this direction.

regards,

Martin

On 4/11/08, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> Okay, I have yet another approach that I thought of while walking my
> dogs that is much more JSF-ish and goes along with Christi's email on
> sub-renderers.
>
> Instead creating a whole bloody wrapper API framework that would make
> the API hard to change, what about breaking the renderers down even
> more into subclasses.
>
> Take the tr:panelPopup for example again. It has:
> Outer container
> Trigger
> Popup
>   Title bar
>   Close button
>   Body
>
> So lets say this is how the renderer could be built:
> First, create a bunch of renderer types:
> org.apache.myfaces.trinidad.Popup
> org.apache.myfaces.trinidad.Popup.Trigger
> org.apache.myfaces.trinidad.Popup.PopupShell
> org.apache.myfaces.trinidad.Popup.TitleBar
> org.apache.myfaces.trinidad.Popup.ButtonArea
> org.apache.myfaces.trinidad.Popup.Body
>
> Then register a default renderer for each of these types.
>
> Then the PanelPopupRenderer would in encodeAll:
>
> render outer DIV (ppr stuff)
> call a render utils method to get the renderer for the trigger and encode it
> call a render utils method to get the renderer for the popup shell and
> encode it
>
> in the popup shell renderer:
> encode the outer HTML
> call a render utils method to get the renderer for the title bar and encode
> it
> call a render utils method to get the renderer for the popup body and encode
> it
>
> in the title bar renderer:
> encode the outer HTML
> encode the title
> call a render utils method to get the renderer for the button area and
> encode it
>
> in the body renderer:
> encode the outer HTML
> encode the children components
>
> This way there are many renderers to one component. The renderers
> would be registered in the faces-config.xml just like any ordinary
> renderers. Since the FacesBean allows renderers to encode any
> component that has certain property keys, this is ideal.
>
> Take for example the close button on the popup, we could have a faces
> bean alias wrapper. What I mean by this is something like this:
>
> public class PopupTitleBarRenderer extends XhtmlRenderer {
>   protected void encodeAll(FacesContext context, RenderingContext rc,
> UIComponent component, FacesBean bean) throws IOException {
> FacesBean wrapped = new AliasedFacesBean(bean);
> wrapped.map("text", "title");
> ...
>
> This way a command button renderer could be used to render the close
> button using the title from the dialog as the text of the button.
>
> Using this way, the only exposed API are the sub-renderer types that
> can be defined in the faces config. New types can be added and old
> ones removed without breaking Java interfaces or abstract class APIs
> (although it would have to be controlled to not break custom code too
> badly).
>
> -Andrew
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [proposal] jsf validation with annotations

[Martin Marinschek]

Hi Gerhard,

let's start a vote _after_ we have discussed the code - just give us a
link to a zip-file with the code in it somewhere.

regards,

Martin

On 4/11/08, Gerhard Petracek <[EMAIL PROTECTED]> wrote:
> hello,
>
> as mentioned: sev-en started as feasibility study. so there are some topics
> i haven't cared about so far.
> to keep it short: i would like to finish some tasks before we discuss
> details. it's much more efficient to discuss the intermediate result after
> this process.
>
> (at the moment the concepts of the core are pretty stable.)
>
> in the mean time i would suggest to open a vote concerning the myfaces
> sub-project topic.
>
> furthermore, some of you don't like the original/internal code-name.
> is it enough to omit the hyphen?
> (sev-en -> seven)
> or do you have some fancy names in mind?
>
> regards,
> gerhard
>
>
>
> 2008/4/10, Matthias Wessendorf <[EMAIL PROTECTED]>:
> >
> > true!
> >
> >
> > On Wed, Apr 9, 2008 at 8:28 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> > > I think so too.  Having a sub-project of a sub-project might be a little
> > > infrastructure heavy, there is nothing to say that Sev-en couldn't
> > become
> > > it's own MyFaces subproject that's intended to be used in a
> > > MyFaces/Orchestra type environment.
> > >
> > >  I also agree it should my a MyFaces wide decision because it impacts
> > > expectations on the renderkits.
> > >
> > >  Scott
> > >
> > >
> > >
> > >  Kito D. Mann wrote:
> > >
> > > > I think Mario has made some very good points...
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
> > > > > Sent: Wednesday, April 09, 2008 5:14 AM
> > > > > To: MyFaces Development
> > > > > Subject: Re: [proposal] jsf validation with annotations
> > > > >
> > > > > Hi!
> > > > >
> > > > >
> > > > > > my position on this is we could make sev-en part of orchestra, if
> > the
> > > > > > orchestra crew really, really wants it. If not, this should just
> > be a
> > > > > > separate sub-module in MyFaces. It is interesting enough to stand
> > on
> > > > > > its own.
> > > > > >
> > > > > >
> > > > > >
> > > > > First, Orchestra is part of the MyFaces community, so it really,
> > really
> > > > > should be a decision the MyFaces community felt, and not a
> > "Orchestra
> > > > > Team" only one.
> > > > >
> > > > > Anyway, I think this is a question on how we position Orchestra.
> > > > > If it is a strong position against JBoss Seam, then it probably
> > might
> > > > > make sense to include everything which makes life easier for the
> > > > > developer into Orchestra - just as Seam tries to do.
> > > > > However, then we loose one of the strongest arguments pro Orchestra:
> > > > > Being a lightweight Conversation-Centric Library.
> > > > >
> > > > > If, we could add it as sub-module to Orchestra, but I think the best
> > > > > place for sev-en (would like to see a new name anyway) is to be a
> > > > > submodule of MyFaces. But first I'd like to see the technical
> > details
> > > > > of
> > > > > how the sev-en core works. e.g. in the examples I've seen a lot of
> > > > > converter wrapper stuff ...
> > > > >
> > > > > Building an official MyFaces Maven Artifact which bootup a
> > development
> > > > > environment (MyFaces Fullstack) with what we think on need for
> > > > > development of any-range-sized applications would be more approriate
> > > > > then. Such a project could include sev-en too.
> > > > >
> > > > > Ciao,
> > > > > Mario
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> > --
> >
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces