Re: [Trinidad] private / protected final methods in renderers
Blake Sullivan wrote: Stephen Friedrich said the following On 4/13/2008 11:26 PM PT: Blake, in general you point of view is a very theoretical one from a high ebony tower. Do you say so in english? ;-) In English, it is usually ivory tower, but, if you think that I'm evil, ebony tower might be more approriate. Oops, somehow it looked strange when written - guess I was confused by that Stevie Wonder classic ;-) I think our opinions aren't that different after all. It would be great to have well designed hooks for everything - but we just won't see that any time soon. For this to be easy, the developer would have needed to have already added a protected hook to control where the required field indicator is located. Yet, if he had that much foresight, why didn't he make the Well the point is that when methods are protected there need not be a explicit hook. An extreme example is JBoss Seam, where almost all of the internals are implemented using their own component framework. I can always replace default behaviour by replacing components. Of course when upgrading from version 1.1 to 2.0 I had to modify my changed components, too, but that was expected and not so much work after all.
Re: [Trinidad] private / protected final methods in renderers
Hi An extreme example is JBoss Seam, where almost all of the internals are implemented using their own component framework. I can always replace default behaviour by replacing components. Of course when upgrading from version 1.1 to 2.0 I had to modify my changed components, too, but that was expected and not so much work after all. so, they clearly say (in their doc or so) that replacing can (or does) break things ? -Matthias -- 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
Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. In UIXTable, createCollectionModel is final method, due to this we can not associate our own model with table except from backing bean. Is there any specific reson in making this method final. If u look into treetable, createCollectionModel method is protected, we can overide this method in custom component. Thanks Ravindra On Thu, Apr 10, 2008 at 5:53 AM, Cristi Toth [EMAIL PROTECTED] wrote: 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 -- Thanks and Regards Ravindra Adireddy
Re: [Trinidad] private / protected final methods in renderers
On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
The new thread has the subject: [Trinidad] Idea to register sub-renderers in the faces configuration. On Tue, Apr 15, 2008 at 12:39 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
Hi guys, Dividing this thread is the best thing. But I think we either reached a conclusion or we should start a vote about final/private methods * We can change current final/private renderer methods to not final / protected ones, only when needed, on specific use cases !!!* If somebody still disagrees with the previous conclusion, the we should start a vote. If not, we should take this as a fact from now on. After we reach a conclusion on the other thread (sub-renderers), we should have a wiki page or a documentation page on extending Trinidad renderers. Thanks for the extensive feedback (positive and negative)! Best regards, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 9:38 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
I am agreement with the others that would like to see case by case JIRA issues to choose to open up renderers since it is considered taboo (spelling it right this time). On Tue, Apr 15, 2008 at 2:40 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, Dividing this thread is the best thing. But I think we either reached a conclusion or we should start a vote about final/private methods We can change current final/private renderer methods to not final / protected ones, only when needed, on specific use cases !!! If somebody still disagrees with the previous conclusion, the we should start a vote. If not, we should take this as a fact from now on. After we reach a conclusion on the other thread (sub-renderers), we should have a wiki page or a documentation page on extending Trinidad renderers. Thanks for the extensive feedback (positive and negative)! Best regards, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 9:38 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
What I meant with on specific use cases was case by case So I agree with this approach. But I don't want to get the same negative feedback with the same arguments on cases where it's really useful to have protected methods. Oh! One more thing: we also agree that renderers are not 100% guaranteed to be backwards compatible on each new release. Right? cheers, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 10:42 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I am agreement with the others that would like to see case by case JIRA issues to choose to open up renderers since it is considered taboo (spelling it right this time). On Tue, Apr 15, 2008 at 2:40 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, Dividing this thread is the best thing. But I think we either reached a conclusion or we should start a vote about final/private methods We can change current final/private renderer methods to not final / protected ones, only when needed, on specific use cases !!! If somebody still disagrees with the previous conclusion, the we should start a vote. If not, we should take this as a fact from now on. After we reach a conclusion on the other thread (sub-renderers), we should have a wiki page or a documentation page on extending Trinidad renderers. Thanks for the extensive feedback (positive and negative)! Best regards, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 9:38 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] private / protected final methods in renderers
I like your suggestion on a WIKI to state Trinidad's official stance on sub-classing renderers. In there something about it not at all supported / use at your own risk and if ppl. have a good desire to make something non-final or protected on what the process is to get that discussed and maybe done. With a WIKI, then each bug can state that it followed the official method of breaching the subject and are therefore knowledgeable of the risks. -A On Tue, Apr 15, 2008 at 2:53 PM, Cristi Toth [EMAIL PROTECTED] wrote: What I meant with on specific use cases was case by case So I agree with this approach. But I don't want to get the same negative feedback with the same arguments on cases where it's really useful to have protected methods. Oh! One more thing: we also agree that renderers are not 100% guaranteed to be backwards compatible on each new release. Right? cheers, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 10:42 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I am agreement with the others that would like to see case by case JIRA issues to choose to open up renderers since it is considered taboo (spelling it right this time). On Tue, Apr 15, 2008 at 2:40 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, Dividing this thread is the best thing. But I think we either reached a conclusion or we should start a vote about final/private methods We can change current final/private renderer methods to not final / protected ones, only when needed, on specific use cases !!! If somebody still disagrees with the previous conclusion, the we should start a vote. If not, we should take this as a fact from now on. After we reach a conclusion on the other thread (sub-renderers), we should have a wiki page or a documentation page on extending Trinidad renderers. Thanks for the extensive feedback (positive and negative)! Best regards, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 9:38 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to
Re: [Trinidad] private / protected final methods in renderers
Andrew Robinson said the following On 4/15/2008 1:42 PM PT: I am agreement with the others that would like to see case by case JIRA issues to choose to open up renderers since it is considered taboo (spelling it right this time). Or, more specifically, that subclassing the current Renderers is unsupported (Trinidad consumers are free to do anything that they want with any of the code as per Apache license) and the reason why it is currently unsupported is that the current implementation's Renderer inheritance hierarchy, delegation model, and protected hooks aren't really designed for anything other than the convenience of the implementors and thus, largely currently exist at the whim of the implementors. As a practical matter, most of these aspects of the Renderer implementation haven't changed in a long time and so subclassing, though unsafe can work but is very much at your own risk and even then can be painful. In cases where we aren't essentially adding new public api (like public skinning hooks) and are requesting that an Renderer be opened up with more protected hooks, the removal of finals, or a mroe fundamental redesign. I would like to see what the guaranteed lifetime for these changes is. -- Blake Sullivan On Tue, Apr 15, 2008 at 2:40 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, Dividing this thread is the best thing. But I think we either reached a conclusion or we should start a vote about final/private methods We can change current final/private renderer methods to not final / protected ones, only when needed, on specific use cases !!! If somebody still disagrees with the previous conclusion, the we should start a vote. If not, we should take this as a fact from now on. After we reach a conclusion on the other thread (sub-renderers), we should have a wiki page or a documentation page on extending Trinidad renderers. Thanks for the extensive feedback (positive and negative)! Best regards, -- Cristi Toth - Codebeat www.codebeat.ro On Tue, Apr 15, 2008 at 9:38 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on how to customize the value of properties that a renderer uses from the FacesBean without using inheritance. Tthat part of the thread has not reached a resolution, and although it may be viewed as a sub-thread, it still warrants further discussion and other view points. -Andrew On Tue, Apr 15, 2008 at 12:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. I am thinking that it is perhaps time to put this thread to rest. (It's been fun, but, hey, all good things come to an end, right?) seriously, I agree on that -M Perhaps we should follow Stephen's lead and start opening up new threads to discuss particular cases where improved extensibility is required. Ravi - would you mind starting a new thread to address the table extensibility question? Andy -- 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
Blake, in general you point of view is a very theoretical one from a high ebony tower. Do you say so in english? ;-) In real life those private methods do make using Trinidad more cumbersome that it needs to be. For example it is currently not possible to make a simple change like moving * _behind_ field labels. I agree that there should be a well defined contract how to adjust behaviour - in theory. Practically speaking to fix that little issue, I had to understand trinidad sources, create a patch and recompile that whole damn thing. Not really a better solution, isn't it? If you don't personally agree to go through each and every source file in Trinidad and fix those issues with hardcoded, unchangeable behaviour, then please have some understanding for the purpose of the request. It goes without saying that overriding protected methods in trinidad interal sources can break if you blindly update to the next trinidad version. Yet, I better like to have that documented in my app, than having to document well, and then you have to download trinidad sources, make these and that patches, check if they are still compatible with the new trinidad version, recompile the lib and ship with that modified copy of trinidad. Blake Sullivan wrote: 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
Re: [Trinidad] private / protected final methods in renderers
not sure if the thread is already over... since I was gone for some days... On Fri, Apr 11, 2008 at 8:45 AM, Martin Marinschek [EMAIL PROTECTED] wrote: 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. nice example :) 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 I agree, that having hooks may be the better option for the Trinidad community (and the adoption of Trinidad) 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] mailto:[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
Re: [Trinidad] private / protected final methods in renderers
yes, sounds reasonable.
On Fri, Apr 11, 2008 at 8:47 AM, Martin Marinschek
[EMAIL PROTECTED] wrote:
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
--
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
On Fri, Apr 11, 2008 at 3:59 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Hey Martin (and all) - It seems to me that what this comes down to is how we view classes in trinidadinternal. There are a range of possible views here: 1. These classes are entirely private/off-limits, and if you want to extend one of these tough luck. No love for you. Go away. 2. These classes are entirely private/off-limits, however, if there is functionality here that our users legitimately need to extend, then we should try to facilitate that by promoting the functionality in question over to the public API (trinidadapi package), accepting the burden that this is, now, from here on out, part of our public API. 3. Hey, well, we all know that these classes are off-limits in spirit, but guess what, people are going to extend them, not for malicious purposes but because they are trying to solve a real problem. While moving functionality to the public API is the correct solution, we also recognize that this requires significantly more effort, and requires us to sacrifice future flexibility. Instead of paying this price, we prefer live with the fact that, yes, some small set of users might extend these, and that we might even need to make some tweaks in order to facilitate that, though we aren't willing to claim that these APIs are officially supported, and we make no guarantee that we won't break things in a future release. 4. The APIs in trinidadinternal should be part of our public API, officially supported, guaranteed not to change. I don't think that anyone is lobbying for #1 or #4. I think that Scott is in favor of #2. Note that this doesn't mean no love for Christi and the problems that he is trying to solve. Just that Scott's preferred way to solve these problems is by defining public APIs rather than have people depend on unofficial/unsupported/internal APIs. It sounds like several people are in favor of #3. I think, that I am in that boat too. -M I am somewhere on the fence between #2 and #3. I think that #2 is the correct thing to do, but I also believe that this is a significant burden, so I am tempted by #3 as a way to ease some of the frustration. Before we discuss questions like whether we should be breaking out renderers into smaller sub-renderers, or whether particular methods should be final/private/protected/whatever, I think we need to agree as a community what our stance is on on the question of how we view trinidadinternal. Andy -- 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
1) Company decides to adopt Trinidad for a project 2) They are either (a) crunched for time or (b) need to get a release out 3) From mgmt, they are told they have to implement a feature 4) Trinidad has no way to support this feature, but the current renderer has a method that would allow me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build so... we can fix that, to be more agile, right? 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, some afraid of maintenance). I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go. -- 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
On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson [EMAIL PROTECTED] wrote: If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. as an asf member I really don't like statements like that... a strong community builds a strong product so, why not listening to contributors? -M Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: 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 -- 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
On Mon, Apr 14, 2008 at 2:15 AM, Cristi Toth [EMAIL PROTECTED] wrote: Hi, Let me add some things to what I already stated here. There are 2 important reason for overriding renderers, that nobody mentioned here. 1) Not all users needs are general enough to be comitted into Trinidad. I myself encountered some very custom features required by some customers, that I simply said, there's no way I'll commit this in Trinidad. true. and it is important to not add everything to Trin :-) 2) Custom components When developers build some custom components, they usually extend the existing ones and most of the cases extend also the renderers. That's code reusability and flexibility, right? So for these types of cases, you have to support in some way the renderer overriding. yes. I personally think that allowing hooks is OK. And the folks that depend on these hooks need to understand! that there overridden thing *can* fail in a next release... Another reason for not complaining to much about renderer backward compatibility is that companies tend not to upgrade dependencies any more, when they have a relatively stable product. Not to mention that if the user duplicates the whole renderer, he'll have even more problems when upgrading. Thanks Andrew for trying to organize this thread. I totally support : 3) introduce some configurable way to override default behavior for rendering certain areas of components. The best way is having some smaller renderers that are delegated to render parts of components. As Andrew suggested, faces-config seems the perfect way to support overriding those 'sub-renderers'. I like the composed renderers approach as well -Matthias 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu For these 2 points, I really want to make myself clear. I have NOT even thought of promoting ALL private members to protected. Of course only if really helpful for overriding. And as Gabrielle stated, we never made promises of renderer backwards compatibility. Regards, -- Cristi Toth - Codebeat www.codebeat.ro On Fri, Apr 11, 2008 at 11:02 PM, Gabrielle Crawford [EMAIL PROTECTED] wrote: Generally I really do agree with Simon that a simple, serious redesign of every component would probably do better than hooks. Also, I really think once you put restrictions on your renderers you run into issues, like you have a bug or a new feature which makes you need to reorganize in an unexpected way. I'm fine with making it easier to subclass renderers for those that want to take the risk, but I'm -1 on any scheme that restricts our ability to make changes when the need arises. Other comments inline: Andrew Robinson wrote: Could we move this discussion away from a debate? Could MyFaces Committers or PMC members _only_ please share their thoughts on this to keep the discussion to the stake holders only? Please share other solutions as you have them. Here some view points to discuss: 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible -1, the renderers have to be able to change without worrying about backwards compatibility. 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api Maybe I've misunderstood, but this sounds like it's basically the same as 1 but for pieces of a renderer, -1. 3) introduce some configurable way to override default behavior for rendering certain areas of components. That would be fine, as long as there's not a perf issue, and there's an understanding that things may break at the next release - hopefully rare, but possible. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu I think removing final modifiers AFTER discussion is fine, and I think if people want to risk extending renderers then fine, but we make no promises they will not break at the next release. Same for 5 below. Thanks, Gab 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final.
Re: [Trinidad] private / protected final methods in renderers
Yes, I understand, but when one mailing list member is holding up progress by providing only negative, non-constructive feedback and even admits that his own branch of the thread has ceased to be useful, it is important to be able to let the other members of the community have a say. This was the only way to stop unnecessary bickering from going on without end. As long as people are contributing helpful feedback and are attempting to further the discussion and help make proposals on how to fix problems, instead of just making negative comments on how people work, then that feedback is welcome. On 4/14/08, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson [EMAIL PROTECTED] wrote: If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. as an asf member I really don't like statements like that... a strong community builds a strong product so, why not listening to contributors? -M Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: 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 -- 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
I thought a little bit more about the renderer composition idea and there
are some things to address.
Currently, when we create a renderer using a delegation model, it often look
like the following:
public class MyMainRenderer extends XhtmlRenderer
{
private Renderer partRenderer;
protected void findTypeContants(FacesBean.Type type)
{
partRenderer = new TheSpecificDelegateRenderer(type);
}
private class TheSpecificDelegateRenderer extends TheBaseDelegateRenderer
{
public TheSpecificDelegateRenderer(FacesBean.Type type)
{
super(type);
}
}
}
public class TheBaseDelegateRenderer extends XhtmlRenderer
{
protected TheBaseDelegateRenderer(FacesBean.Type type)
{
super(type);
}
}
Given we now want to define the composition renderers within faces-config,
it makes the previous way quite hard to deal with. We're most likely have to
locate the renderer using
context.getRenderKit().getRenderer(componentFamily, rendererType);
I see two problems with this:
1. What naming convention should we use for the component families and
renderer types? That one is more a point to address than a problem;
2. How do we privately extends those renderer like
TheSpecificDelegateRenderer does? I see no way and it's quite critic as some
renderers use that pattern in order to inhibit a given property or to infer
it from a different attribute of the original component. Well, saying that I
see no way is not exactly true. It could be possible to have those renderers
implement an interface defining a clone method (a bit like TypedRenderer)
receiving a kind of Accessors object to get its attribute values from.
However, I'm a bit wary of the performance impact of such structure and it
wouldn't necessarily fix all issues either. Anyone has any idea how to deal
with that?
Regards,
~ Simon
On Mon, Apr 14, 2008 at 10:22 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On Mon, Apr 14, 2008 at 3:54 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Yes, I understand, but when one mailing list member is holding up
progress by providing only negative, non-constructive feedback and
even admits that his own branch of the thread has ceased to be useful,
perhaps due to my lack of English these comments didn't sound that
non-constructive I understood them as a valid concerns, which IMO
legitimate to share them. BTW. here is an interesting FAQ ([1])
it is important to be able to let the other members of the community
have a say. This was the only way to stop unnecessary bickering from
I still don't like stopping contribtions that way...
...and we should keep the discussion open
going on without end. As long as people are contributing helpful
feedback and are attempting to further the discussion and help make
proposals on how to fix problems, instead of just making negative
comments on how people work, then that feedback is welcome.
-Matthias
[1] http://wicket.sourceforge.net/faqs.html#why-final
On 4/14/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
If you are not a member of MyFaces, Committer or PMC member please
refrain from further reply to this thread as your feedback has
already
been noted.
as an asf member I really don't like statements like that...
a strong community builds a strong product so, why not
listening to contributors?
-M
Thank you,
Andrew
On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED]
wrote:
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
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
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
Hi,
On Mon, Apr 14, 2008 at 6:11 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Have you looked at my code in the branch? I think it would be good te
not yet. I plan to get to it tomorrow.
I was out last week... and fighting through all my mails and stuff.
-M
critique that so that there is a solid example for people to look at.
I did not attempt to make it pretty, so hopefully if such a thing is
done, we would give it a better API.
SVN Path:
http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/
Component:
http://tinyurl.com/5sej5p
Main Renderer that delegates:
http://tinyurl.com/4hzk8t
The two sub-renderers:
http://tinyurl.com/4qrwgn
http://tinyurl.com/5dvqxl
The code works like current sub-renderers:
1) They are required to be an instance of CoreRenderer
2) They use the FacesBean that is passed in to their encodeAll method
3) They should not use the root component ID on any HTML element
The only difference is that I looked the value up in the render kit
instead of directly instantiating the renderer
-Andrew
On Mon, Apr 14, 2008 at 8:53 AM, Simon Lessard
[EMAIL PROTECTED] wrote:
I thought a little bit more about the renderer composition idea and there
are some things to address.
Currently, when we create a renderer using a delegation model, it often
look
like the following:
public class MyMainRenderer extends XhtmlRenderer
{
private Renderer partRenderer;
protected void findTypeContants(FacesBean.Type type)
{
partRenderer = new TheSpecificDelegateRenderer(type);
}
private class TheSpecificDelegateRenderer extends TheBaseDelegateRenderer
{
public TheSpecificDelegateRenderer(FacesBean.Type type)
{
super(type);
}
}
}
public class TheBaseDelegateRenderer extends XhtmlRenderer
{
protected TheBaseDelegateRenderer(FacesBean.Type type)
{
super(type);
}
}
Given we now want to define the composition renderers within faces-config,
it makes the previous way quite hard to deal with. We're most likely have
to
locate the renderer using
context.getRenderKit().getRenderer(componentFamily, rendererType);
I see two problems with this:
1. What naming convention should we use for the component families and
renderer types? That one is more a point to address than a problem;
2. How do we privately extends those renderer like
TheSpecificDelegateRenderer does? I see no way and it's quite critic as
some
renderers use that pattern in order to inhibit a given property or to infer
it from a different attribute of the original component. Well, saying that
I
see no way is not exactly true. It could be possible to have those
renderers
implement an interface defining a clone method (a bit like TypedRenderer)
receiving a kind of Accessors object to get its attribute values from.
However, I'm a bit wary of the performance impact of such structure and it
wouldn't necessarily fix all issues either. Anyone has any idea how to deal
with that?
Regards,
~ Simon
On Mon, Apr 14, 2008 at 10:22 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On Mon, Apr 14, 2008 at 3:54 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Yes, I understand, but when one mailing list member is holding up
progress by providing only negative, non-constructive feedback and
even admits that his own branch of the thread has ceased to be useful,
perhaps due to my lack of English these comments didn't sound that
non-constructive I understood them as a valid concerns, which IMO
legitimate to share them. BTW. here is an interesting FAQ ([1])
it is important to be able to let the other members of the community
have a say. This was the only way to stop unnecessary bickering from
I still don't like stopping contribtions that way...
...and we should keep the discussion open
going on without end. As long as people are contributing helpful
feedback and are attempting to further the discussion and help make
proposals on how to fix problems, instead of just making negative
comments on how people work, then that feedback is welcome.
-Matthias
[1] http://wicket.sourceforge.net/faqs.html#why-final
On 4/14/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
If you are not a member of MyFaces, Committer or PMC member
please
refrain from further reply to this thread as your feedback has
already
been noted.
as an asf member I really don't like statements like that...
a strong
Re: [Trinidad] private / protected final methods in renderers
Ignore the component link, I messed that one up. The renderers are the
ones to have a look at.
On Mon, Apr 14, 2008 at 10:11 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Have you looked at my code in the branch? I think it would be good te
critique that so that there is a solid example for people to look at.
I did not attempt to make it pretty, so hopefully if such a thing is
done, we would give it a better API.
SVN Path:
http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/
Component:
http://tinyurl.com/5sej5p
Main Renderer that delegates:
http://tinyurl.com/4hzk8t
The two sub-renderers:
http://tinyurl.com/4qrwgn
http://tinyurl.com/5dvqxl
The code works like current sub-renderers:
1) They are required to be an instance of CoreRenderer
2) They use the FacesBean that is passed in to their encodeAll method
3) They should not use the root component ID on any HTML element
The only difference is that I looked the value up in the render kit
instead of directly instantiating the renderer
-Andrew
On Mon, Apr 14, 2008 at 8:53 AM, Simon Lessard
[EMAIL PROTECTED] wrote:
I thought a little bit more about the renderer composition idea and there
are some things to address.
Currently, when we create a renderer using a delegation model, it often
look
like the following:
public class MyMainRenderer extends XhtmlRenderer
{
private Renderer partRenderer;
protected void findTypeContants(FacesBean.Type type)
{
partRenderer = new TheSpecificDelegateRenderer(type);
}
private class TheSpecificDelegateRenderer extends TheBaseDelegateRenderer
{
public TheSpecificDelegateRenderer(FacesBean.Type type)
{
super(type);
}
}
}
public class TheBaseDelegateRenderer extends XhtmlRenderer
{
protected TheBaseDelegateRenderer(FacesBean.Type type)
{
super(type);
}
}
Given we now want to define the composition renderers within faces-config,
it makes the previous way quite hard to deal with. We're most likely have
to
locate the renderer using
context.getRenderKit().getRenderer(componentFamily, rendererType);
I see two problems with this:
1. What naming convention should we use for the component families and
renderer types? That one is more a point to address than a problem;
2. How do we privately extends those renderer like
TheSpecificDelegateRenderer does? I see no way and it's quite critic as
some
renderers use that pattern in order to inhibit a given property or to infer
it from a different attribute of the original component. Well, saying that
I
see no way is not exactly true. It could be possible to have those
renderers
implement an interface defining a clone method (a bit like TypedRenderer)
receiving a kind of Accessors object to get its attribute values from.
However, I'm a bit wary of the performance impact of such structure and it
wouldn't necessarily fix all issues either. Anyone has any idea how to deal
with that?
Regards,
~ Simon
On Mon, Apr 14, 2008 at 10:22 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On Mon, Apr 14, 2008 at 3:54 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Yes, I understand, but when one mailing list member is holding up
progress by providing only negative, non-constructive feedback and
even admits that his own branch of the thread has ceased to be useful,
perhaps due to my lack of English these comments didn't sound that
non-constructive I understood them as a valid concerns, which IMO
legitimate to share them. BTW. here is an interesting FAQ ([1])
it is important to be able to let the other members of the community
have a say. This was the only way to stop unnecessary bickering from
I still don't like stopping contribtions that way...
...and we should keep the discussion open
going on without end. As long as people are contributing helpful
feedback and are attempting to further the discussion and help make
proposals on how to fix problems, instead of just making negative
comments on how people work, then that feedback is welcome.
-Matthias
[1] http://wicket.sourceforge.net/faqs.html#why-final
On 4/14/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
If you are not a member of MyFaces, Committer or PMC member
please
refrain from further reply to this thread as your feedback has
already
been noted.
as an asf member I really don't like statements like that...
a strong community builds a strong
Re: [Trinidad] private / protected final methods in renderers
Have you looked at my code in the branch? I think it would be good te
critique that so that there is a solid example for people to look at.
I did not attempt to make it pretty, so hopefully if such a thing is
done, we would give it a better API.
SVN Path:
http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/
Component:
http://tinyurl.com/5sej5p
Main Renderer that delegates:
http://tinyurl.com/4hzk8t
The two sub-renderers:
http://tinyurl.com/4qrwgn
http://tinyurl.com/5dvqxl
The code works like current sub-renderers:
1) They are required to be an instance of CoreRenderer
2) They use the FacesBean that is passed in to their encodeAll method
3) They should not use the root component ID on any HTML element
The only difference is that I looked the value up in the render kit
instead of directly instantiating the renderer
-Andrew
On Mon, Apr 14, 2008 at 8:53 AM, Simon Lessard
[EMAIL PROTECTED] wrote:
I thought a little bit more about the renderer composition idea and there
are some things to address.
Currently, when we create a renderer using a delegation model, it often look
like the following:
public class MyMainRenderer extends XhtmlRenderer
{
private Renderer partRenderer;
protected void findTypeContants(FacesBean.Type type)
{
partRenderer = new TheSpecificDelegateRenderer(type);
}
private class TheSpecificDelegateRenderer extends TheBaseDelegateRenderer
{
public TheSpecificDelegateRenderer(FacesBean.Type type)
{
super(type);
}
}
}
public class TheBaseDelegateRenderer extends XhtmlRenderer
{
protected TheBaseDelegateRenderer(FacesBean.Type type)
{
super(type);
}
}
Given we now want to define the composition renderers within faces-config,
it makes the previous way quite hard to deal with. We're most likely have to
locate the renderer using
context.getRenderKit().getRenderer(componentFamily, rendererType);
I see two problems with this:
1. What naming convention should we use for the component families and
renderer types? That one is more a point to address than a problem;
2. How do we privately extends those renderer like
TheSpecificDelegateRenderer does? I see no way and it's quite critic as some
renderers use that pattern in order to inhibit a given property or to infer
it from a different attribute of the original component. Well, saying that I
see no way is not exactly true. It could be possible to have those renderers
implement an interface defining a clone method (a bit like TypedRenderer)
receiving a kind of Accessors object to get its attribute values from.
However, I'm a bit wary of the performance impact of such structure and it
wouldn't necessarily fix all issues either. Anyone has any idea how to deal
with that?
Regards,
~ Simon
On Mon, Apr 14, 2008 at 10:22 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On Mon, Apr 14, 2008 at 3:54 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Yes, I understand, but when one mailing list member is holding up
progress by providing only negative, non-constructive feedback and
even admits that his own branch of the thread has ceased to be useful,
perhaps due to my lack of English these comments didn't sound that
non-constructive I understood them as a valid concerns, which IMO
legitimate to share them. BTW. here is an interesting FAQ ([1])
it is important to be able to let the other members of the community
have a say. This was the only way to stop unnecessary bickering from
I still don't like stopping contribtions that way...
...and we should keep the discussion open
going on without end. As long as people are contributing helpful
feedback and are attempting to further the discussion and help make
proposals on how to fix problems, instead of just making negative
comments on how people work, then that feedback is welcome.
-Matthias
[1] http://wicket.sourceforge.net/faqs.html#why-final
On 4/14/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
If you are not a member of MyFaces, Committer or PMC member please
refrain from further reply to this thread as your feedback has
already
been noted.
as an asf member I really don't like statements like that...
a strong community builds a strong product so, why not
listening to contributors?
-M
Thank you,
Andrew
On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth
[EMAIL PROTECTED]
wrote:
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
Re: [Trinidad] private / protected final methods in renderers
Yes, I understand, but when one mailing list member is holding up progress by providing only negative, non-constructive feedback and even admits that his own branch of the thread has ceased to be useful, perhaps due to my lack of English these comments didn't sound that non-constructive I understood them as a valid concerns, which IMO legitimate to share them. BTW. here is an interesting FAQ ([1]) The problem was that the conversation stopped being one and was stopping others from providing feedback. The problem was that no solutions were being offered by Blake on how to address the issue that Christi brought up. When I gave supporting evidence to support why there are existing problems with usage of Trinidad and gave real world examples, Blake decided to try to prove that my past company was stupid and that the way that they have to do business is by having to maintain and develop their own custom version of Trinidad. Not once was there offered a way to improve the Trinidad code to address Christi's question or even to validate that Christi has a valid concern. To continuously show disregard for peoples opinions and to say that entire companies have incorrect view points is not constructive. I have not been exposed to this type of heckling in the open source community before to the point where open source contributers instead of trying to assist a user in finding a solution, instead tell them that their problem is invalid. The comments on concerns on if exposing renderer methods as part of the API is very valid, as is making any of trinidad-impl public API. On the other hand, to say that no one has valid a need for extending a renderer and arguing that point is not a constructive practice in helping our user base. I would not have reacted this way if Blake was willing to provide solutions to the problem that went beyond maintaining their own source code. Telling someone their use cases are not valid, especially ones that that were not theoretical shows a complete lack of respect for one's peers. In order to help Christi out, I asked what was starting to be a flame war to stop. I then logged all the ideas that had been presented thus far an solicited opinions from others. I also have apologized for my behavior, which I see that has not been reciprocated. Sorry for closing the discussion, and please, if anyone else has any news ideas or view points to present, please share them. In respect to Christi, I just ask that we do not attempt to beat the dead horse by continuing to discuss validity of his, mine and others' points of view. Thank you, -Andrew
Re: [Trinidad] private / protected final methods in renderers
Simon, Frankly I do not understand #2, sorry. Could you explain what the problem is in a different way? Perhaps I just have not seen something in the current code that does something that you are referring to. I was hoping that someone besides myself would understand what you said better and provide an answer. The code I presented works AFAIK like the current sub-renderer Trinidad architecture where a sub-renderer gets the property values, and the knowledge of existence of properties by querying the FacesBean instance, not the component. Therefore, to mask, rename or change the value of a property passed to a sub-renderer, would the developer not wrap, extend or present the FacesBean in some way to the sub-renderer to make those abstractions? Or am I really not understanding your concern correctly? -Andrew On Mon, Apr 14, 2008 at 10:37 AM, Simon Lessard [EMAIL PROTECTED] wrote: Hello Andrew, Your examples don't handle concern #2 of my reply. Regards, ~ Simon 2. How do we privately extends those renderer like TheSpecificDelegateRenderer does? I see no way and it's quite critic as some renderers use that pattern in order to inhibit a given property or to infer it from a different attribute of the original component. Well, saying that I see no way is not exactly true. It could be possible to have those renderers implement an interface defining a clone method (a bit like TypedRenderer) receiving a kind of Accessors object to get its attribute values from. However, I'm a bit wary of the performance impact of such structure and it wouldn't necessarily fix all issues either. Anyone has any idea how to deal with that?
Re: [Trinidad] private / protected final methods in renderers
Forgot to say that in my example, I have TestSubRendererHeader as a renderer type. So the registered renderer for this type should have knowledge on how to appropriately render a header for this component type. So in this case, the contract is the FacesBean having a header property set or having a top faces present. Or am I still off base in your concern? On Mon, Apr 14, 2008 at 10:45 AM, Andrew Robinson [EMAIL PROTECTED] wrote: Simon, Frankly I do not understand #2, sorry. Could you explain what the problem is in a different way? Perhaps I just have not seen something in the current code that does something that you are referring to. I was hoping that someone besides myself would understand what you said better and provide an answer. The code I presented works AFAIK like the current sub-renderer Trinidad architecture where a sub-renderer gets the property values, and the knowledge of existence of properties by querying the FacesBean instance, not the component. Therefore, to mask, rename or change the value of a property passed to a sub-renderer, would the developer not wrap, extend or present the FacesBean in some way to the sub-renderer to make those abstractions? Or am I really not understanding your concern correctly? -Andrew On Mon, Apr 14, 2008 at 10:37 AM, Simon Lessard [EMAIL PROTECTED] wrote: Hello Andrew, Your examples don't handle concern #2 of my reply. Regards, ~ Simon 2. How do we privately extends those renderer like TheSpecificDelegateRenderer does? I see no way and it's quite critic as some renderers use that pattern in order to inhibit a given property or to infer it from a different attribute of the original component. Well, saying that I see no way is not exactly true. It could be possible to have those renderers implement an interface defining a clone method (a bit like TypedRenderer) receiving a kind of Accessors object to get its attribute values from. However, I'm a bit wary of the performance impact of such structure and it wouldn't necessarily fix all issues either. Anyone has any idea how to deal with that?
Re: [Trinidad] private / protected final methods in renderers
Hello Andrew, Ok, let say we have a renderer that renders a custom layout with an inputText showing the component's value and allowing to alter it. Since we don't want to reinvent the wheel, we need to reuse the inputText renderer. So, somewhere in the code we'll see something like : delegateRenderer(context, rc, component, bean, _simpleInputTextRenderer); This is where it gets fishy and why findTypeConstants exists (and I assume while cloneWithType / TypedRenderer were created in the first place). If you get the renderer instance from the render kit, or from a direct new using the default constructor for that matter, the renderer will be initialized with CoreInputText.TYPE property keys, but my custom component does not use that type, it rather use MyComponent.TYPE. So, the FacesBean instance passed to delegateRenderer will be using that latter type and there's absolutely no guarantee (actually it's pure luck if it is) that the PropertyKey instance found by the renderer in its findTypeConstants for the value property is going to be the same than the one from my custom type. So, normally in the current delegate model, we instanciate the delegate renderer using the protected constructor receiving a FacesBean.Type instance so that it initialize itself with the right PropertyKey for our use. We can probably workaround that issue using the cloneWithType(newFacesBean.Type) functionality of TypedRenderer, bu that's not the only use case we have. Sometimes, the custom component does not support or do not want to expose one of the attribute (for example onclick) on the renderer sub-part. When such circumstances show up, we create a private inner renderer class extending the one we need to delegate to and override the getter method (getOnclick(FacesBean)) of the property we don't want to render on the sub-part. I currently see no way to achieve that using renderers found from the render kit. Clearer ? ~ Simon On Mon, Apr 14, 2008 at 12:49 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Forgot to say that in my example, I have TestSubRendererHeader as a renderer type. So the registered renderer for this type should have knowledge on how to appropriately render a header for this component type. So in this case, the contract is the FacesBean having a header property set or having a top faces present. Or am I still off base in your concern? On Mon, Apr 14, 2008 at 10:45 AM, Andrew Robinson [EMAIL PROTECTED] wrote: Simon, Frankly I do not understand #2, sorry. Could you explain what the problem is in a different way? Perhaps I just have not seen something in the current code that does something that you are referring to. I was hoping that someone besides myself would understand what you said better and provide an answer. The code I presented works AFAIK like the current sub-renderer Trinidad architecture where a sub-renderer gets the property values, and the knowledge of existence of properties by querying the FacesBean instance, not the component. Therefore, to mask, rename or change the value of a property passed to a sub-renderer, would the developer not wrap, extend or present the FacesBean in some way to the sub-renderer to make those abstractions? Or am I really not understanding your concern correctly? -Andrew On Mon, Apr 14, 2008 at 10:37 AM, Simon Lessard [EMAIL PROTECTED] wrote: Hello Andrew, Your examples don't handle concern #2 of my reply. Regards, ~ Simon 2. How do we privately extends those renderer like TheSpecificDelegateRenderer does? I see no way and it's quite critic as some renderers use that pattern in order to inhibit a given property or to infer it from a different attribute of the original component. Well, saying that I see no way is not exactly true. It could be possible to have those renderers implement an interface defining a clone method (a bit like TypedRenderer) receiving a kind of Accessors object to get its attribute values from. However, I'm a bit wary of the performance impact of such structure and it wouldn't necessarily fix all issues either. Anyone has any idea how to deal with that?
Re: [Trinidad] private / protected final methods in renderers
Yes, much clearer. In a previous email on this thread, I had an idea on creating an alias wrapper for faces beans. The idea being that I could essentially rename the title property of the faces bean to value so I could use the output text renderer to print the title as it would a normal tr:outputText. I am all for different approaches to this, as I am not sure my proposal is that wonderful. Yes, I could see and interface being used as you mention with the requirement that a renderer for type X implement interface Y, but that would be more restrictive, wouldn't it? The aliasing of the faces bean, and the ability to only expose certain properties with such an object is just one proposal. Frankly, I dislike writing protected SomeObject getSomeProperty(FacesBean bean) methods in renderers, as it seems to be quite unnecessary when the FacesBean has the information that is needed to perform this logic without making all these methods (it has the property type, the default value and access to get the current value). I do see their use, but I think that a better solution could be found. Perhaps in some abstraction of the FacesBean in the renderer? -Andrew On Mon, Apr 14, 2008 at 11:03 AM, Simon Lessard [EMAIL PROTECTED] wrote: Hello Andrew, Ok, let say we have a renderer that renders a custom layout with an inputText showing the component's value and allowing to alter it. Since we don't want to reinvent the wheel, we need to reuse the inputText renderer. So, somewhere in the code we'll see something like : delegateRenderer(context, rc, component, bean, _simpleInputTextRenderer); This is where it gets fishy and why findTypeConstants exists (and I assume while cloneWithType / TypedRenderer were created in the first place). If you get the renderer instance from the render kit, or from a direct new using the default constructor for that matter, the renderer will be initialized with CoreInputText.TYPE property keys, but my custom component does not use that type, it rather use MyComponent.TYPE. So, the FacesBean instance passed to delegateRenderer will be using that latter type and there's absolutely no guarantee (actually it's pure luck if it is) that the PropertyKey instance found by the renderer in its findTypeConstants for the value property is going to be the same than the one from my custom type. So, normally in the current delegate model, we instanciate the delegate renderer using the protected constructor receiving a FacesBean.Type instance so that it initialize itself with the right PropertyKey for our use. We can probably workaround that issue using the cloneWithType(newFacesBean.Type) functionality of TypedRenderer, bu that's not the only use case we have. Sometimes, the custom component does not support or do not want to expose one of the attribute (for example onclick) on the renderer sub-part. When such circumstances show up, we create a private inner renderer class extending the one we need to delegate to and override the getter method (getOnclick(FacesBean)) of the property we don't want to render on the sub-part. I currently see no way to achieve that using renderers found from the render kit. Clearer ? ~ Simon On Mon, Apr 14, 2008 at 12:49 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Forgot to say that in my example, I have TestSubRendererHeader as a renderer type. So the registered renderer for this type should have knowledge on how to appropriately render a header for this component type. So in this case, the contract is the FacesBean having a header property set or having a top faces present. Or am I still off base in your concern? On Mon, Apr 14, 2008 at 10:45 AM, Andrew Robinson [EMAIL PROTECTED] wrote: Simon, Frankly I do not understand #2, sorry. Could you explain what the problem is in a different way? Perhaps I just have not seen something in the current code that does something that you are referring to. I was hoping that someone besides myself would understand what you said better and provide an answer. The code I presented works AFAIK like the current sub-renderer Trinidad architecture where a sub-renderer gets the property values, and the knowledge of existence of properties by querying the FacesBean instance, not the component. Therefore, to mask, rename or change the value of a property passed to a sub-renderer, would the developer not wrap, extend or present the FacesBean in some way to the sub-renderer to make those abstractions? Or am I really not understanding your concern correctly? -Andrew On Mon, Apr 14, 2008 at 10:37 AM, Simon Lessard [EMAIL PROTECTED] wrote: Hello Andrew, Your examples don't handle concern #2 of my reply. Regards, ~ Simon 2. How do we privately extends those renderer like TheSpecificDelegateRenderer does? I see no way and it's quite
Re: [Trinidad] private / protected final methods in renderers
Stephan,
This would have been a good skinning feature to add, so that anyone else
that
wants to do this could use skinning to change the position of the field
label.
With a skinning property, a person that wants his * behind field
labels would
simply have to add to their skin something like:
.AFLabelPosition:alias { -tr-before-label: false }
And then the renderers of labels would check this skin property when
they are rendering the label,
and render it either in front or behind.
- Jeanne
Stephen Friedrich wrote, On 4/13/2008 11:26 PM PT:
Blake, in general you point of view is a very theoretical one from a high
ebony tower. Do you say so in english? ;-)
In real life those private methods do make using Trinidad more cumbersome
that it needs to be.
For example it is currently not possible to make a simple change like
moving
* _behind_ field labels.
I agree that there should be a well defined contract how to adjust
behaviour
- in theory. Practically speaking to fix that little issue, I had to
understand trinidad sources, create a patch and recompile that whole damn
thing.
Not really a better solution, isn't it?
If you don't personally agree to go through each and every source file in
Trinidad and fix those issues with hardcoded, unchangeable behaviour,
then
please have some understanding for the purpose of the request.
It goes without saying that overriding protected methods in trinidad
interal
sources can break if you blindly update to the next trinidad version.
Yet, I better like to have that documented in my app, than having to
document
well, and then you have to download trinidad sources, make these and
that
patches, check if they are still compatible with the new trinidad
version,
recompile the lib and ship with that modified copy of trinidad.
Blake Sullivan wrote:
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
Re: [Trinidad] private / protected final methods in renderers
Now flip-flopping to the other side.. :) I disagree that well thought out extension points decrease flexibility in the renderer. It's all about granularity. Some larger components (such as the table) have some clearly defined pieces. I don't think anybody is arguing about the need to extend inputText, people want to extend the most complex components. For example, in table there are header cells and content cells. Certain protected API's encodeHeaderCells and encodeContentCells could be exposed without too much trouble and the encodeAll methods could very quickly turn into a call to the various encodes. Therefore, if someone wanted to put the header row at the bottom, it would be simple to override the encodeAll method to call the encodeContentCells first and the encodeHeaderCells second. Making things general like this wouldn't hurt the renderers IMO, and although it wouldn't allow the granularity that some would hope for, it could strike a good balance between ease of extendability and flexibility for the renderers. As for the delegate or wrapper ideas, I'm intrigued by this, I'm just not sure, again, of the feasibility without these API's. Truthfully, it would have been nice if Faces defined some generic pieces for various types of renderers. Indeed if the interfaces were flexible enough the needs of all the renderkits could be supported with varying degrees of effort. But alas they don't. Scott Andrew Robinson wrote: Yes, much clearer. In a previous email on this thread, I had an idea on creating an alias wrapper for faces beans. The idea being that I could essentially rename the title property of the faces bean to value so I could use the output text renderer to print the title as it would a normal tr:outputText. I am all for different approaches to this, as I am not sure my proposal is that wonderful. Yes, I could see and interface being used as you mention with the requirement that a renderer for type X implement interface Y, but that would be more restrictive, wouldn't it? The aliasing of the faces bean, and the ability to only expose certain properties with such an object is just one proposal. Frankly, I dislike writing protected SomeObject getSomeProperty(FacesBean bean) methods in renderers, as it seems to be quite unnecessary when the FacesBean has the information that is needed to perform this logic without making all these methods (it has the property type, the default value and access to get the current value). I do see their use, but I think that a better solution could be found. Perhaps in some abstraction of the FacesBean in the renderer? -Andrew On Mon, Apr 14, 2008 at 11:03 AM, Simon Lessard [EMAIL PROTECTED] wrote: Hello Andrew, Ok, let say we have a renderer that renders a custom layout with an inputText showing the component's value and allowing to alter it. Since we don't want to reinvent the wheel, we need to reuse the inputText renderer. So, somewhere in the code we'll see something like : delegateRenderer(context, rc, component, bean, _simpleInputTextRenderer); This is where it gets fishy and why findTypeConstants exists (and I assume while cloneWithType / TypedRenderer were created in the first place). If you get the renderer instance from the render kit, or from a direct new using the default constructor for that matter, the renderer will be initialized with CoreInputText.TYPE property keys, but my custom component does not use that type, it rather use MyComponent.TYPE. So, the FacesBean instance passed to delegateRenderer will be using that latter type and there's absolutely no guarantee (actually it's pure luck if it is) that the PropertyKey instance found by the renderer in its findTypeConstants for the value property is going to be the same than the one from my custom type. So, normally in the current delegate model, we instanciate the delegate renderer using the protected constructor receiving a FacesBean.Type instance so that it initialize itself with the right PropertyKey for our use. We can probably workaround that issue using the cloneWithType(newFacesBean.Type) functionality of TypedRenderer, bu that's not the only use case we have. Sometimes, the custom component does not support or do not want to expose one of the attribute (for example onclick) on the renderer sub-part. When such circumstances show up, we create a private inner renderer class extending the one we need to delegate to and override the getter method (getOnclick(FacesBean)) of the property we don't want to render on the sub-part. I currently see no way to achieve that using renderers found from the render kit. Clearer ? ~ Simon On Mon, Apr 14, 2008 at 12:49 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Forgot to say that in my example, I have TestSubRendererHeader as a renderer type. So the registered renderer for this type should have knowledge on how to appropriately render a header for this component type. So in this case, the contract is
Re: [Trinidad] private / protected final methods in renderers
Stephen Friedrich said the following On 4/13/2008 11:26 PM PT: Blake, in general you point of view is a very theoretical one from a high ebony tower. Do you say so in english? ;-) In English, it is usually ivory tower, but, if you think that I'm evil, ebony tower might be more approriate. In real life those private methods do make using Trinidad more cumbersome that it needs to be. For example it is currently not possible to make a simple change like moving * _behind_ field labels. I agree that there should be a well defined contract how to adjust behaviour - in theory. Practically speaking to fix that little issue, I had to understand trinidad sources, create a patch and recompile that whole damn thing. Not really a better solution, isn't it? This is a fine example: For this to be easy, the developer would have needed to have already added a protected hook to control where the required field indicator is located. Yet, if he had that much foresight, why didn't he make the property skinnable? Let's say that he did have the foresight, you overrode his hook and now he realizes that the property should be skinnable. Your renderer subclass doesn't honor the skinning key. Not the end of the world for your Renderer in this case. Note that in order to find the protected hook to use in the first place and verify that its use would not cause some other unexpected result, you would almost certainly need to understand the source. I agree that making a one-off patch to the sources is a pain, but while some of the proposals will decrease the likelihood that any particular change requires hacking on the base code, in many cases, the hook you want simply won't exist in the base code, because we only put the hooks in that we needed to solve the particular problems we were experiencing at that point in time. Therefore, if you want to extend a Trinidad Renderer class, even in an unsupported fashion, you need to accept that you might need to hack. -- Blake Sullivan If you don't personally agree to go through each and every source file in Trinidad and fix those issues with hardcoded, unchangeable behaviour, then please have some understanding for the purpose of the request. It goes without saying that overriding protected methods in trinidad interal sources can break if you blindly update to the next trinidad version. Yet, I better like to have that documented in my app, than having to document well, and then you have to download trinidad sources, make these and that patches, check if they are still compatible with the new trinidad version, recompile the lib and ship with that modified copy of trinidad. Blake Sullivan wrote: 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
Re: [Trinidad] private / protected final methods in renderers
On Mon, Apr 14, 2008 at 5:56 PM, Blake Sullivan [EMAIL PROTECTED] wrote: In English, it is usually ivory tower, but, if you think that I'm evil, ebony tower might be more approriate. Blake == Saruman? ;-) Andy
Re: [Trinidad] private / protected final methods in renderers
Hi, Let me add some things to what I already stated here. There are 2 important reason for overriding renderers, that nobody mentioned here. 1) Not all users needs are general enough to be comitted into Trinidad. I myself encountered some very custom features required by some customers, that I simply said, there's no way I'll commit this in Trinidad. 2) Custom components When developers build some custom components, they usually extend the existing ones and most of the cases extend also the renderers. That's code reusability and flexibility, right? So for these types of cases, you have to support in some way the renderer overriding. Another reason for not complaining to much about renderer backward compatibility is that companies tend not to upgrade dependencies any more, when they have a relatively stable product. Not to mention that if the user duplicates the whole renderer, he'll have even more problems when upgrading. Thanks Andrew for trying to organize this thread. I totally support : 3) introduce some configurable way to override default behavior for rendering certain areas of components. The best way is having some smaller renderers that are delegated to render parts of components. As Andrew suggested, faces-config seems the perfect way to support overriding those 'sub-renderers'. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu For these 2 points, I really want to make myself clear. I have NOT even thought of promoting ALL private members to protected. Of course only if really helpful for overriding. And as Gabrielle stated, we never made promises of renderer backwards compatibility. Regards, -- Cristi Toth - Codebeat www.codebeat.ro On Fri, Apr 11, 2008 at 11:02 PM, Gabrielle Crawford [EMAIL PROTECTED] wrote: Generally I really do agree with Simon that a simple, serious redesign of every component would probably do better than hooks. Also, I really think once you put restrictions on your renderers you run into issues, like you have a bug or a new feature which makes you need to reorganize in an unexpected way. I'm fine with making it easier to subclass renderers for those that want to take the risk, but I'm -1 on any scheme that restricts our ability to make changes when the need arises. Other comments inline: Andrew Robinson wrote: Could we move this discussion away from a debate? Could MyFaces Committers or PMC members _only_ please share their thoughts on this to keep the discussion to the stake holders only? Please share other solutions as you have them. Here some view points to discuss: 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible -1, the renderers have to be able to change without worrying about backwards compatibility. 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api Maybe I've misunderstood, but this sounds like it's basically the same as 1 but for pieces of a renderer, -1. 3) introduce some configurable way to override default behavior for rendering certain areas of components. That would be fine, as long as there's not a perf issue, and there's an understanding that things may break at the next release - hopefully rare, but possible. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu I think removing final modifiers AFTER discussion is fine, and I think if people want to risk extending renderers then fine, but we make no promises they will not break at the next release. Same for 5 below. Thanks, Gab 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: 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
Re: [Trinidad] private / protected final methods in renderers
See below 3) introduce some configurable way to override default behavior for rendering certain areas of components. That would be fine, as long as there's not a perf issue, and there's an understanding that things may break at the next release - hopefully rare, but possible. Gab, I completely understand your concerns for performance issues, so I created a really simple component that renders a header, body and footer (3 DIVs in an outer DIV). In my tests, I had one facet for the header and one attribute for the footer, to try to capture a small portion of a real world situation. I created 3 renderers. Each rendered the content exactly the same: div id=comp divheader/div divbody/div divfooter/div /div Renderer 1: No sub-renderers and no delegating renderers either. It simple does all the encoding in the encodeAll method. Renderer 2: Looks up sub-renderers one time (in the findTypeConstants method) for the header and footer areas. The main renderer renders the outer div and the body div and delegates the rendering of the header and footer to the sub-renderers. Renderer 3: Looks up sub-renderers during the encodeAll for the header and footer areas. The main renderer renders the outer div and the body div and delegates the rendering of the header and footer to the sub-renderers. I don't think the third renderer style would be necessary, as it would be very rare to want to change a sub-renderer to a new class without changing the main renderer (the only time it would make a difference). I used the CoreRenderKitPerf.java JUnit code to run the test. I just ran the test from inside Eclipse. Each test had the renderer render itself 25,000 times and over 12 loops, threw out the best and the worst and took the average of the 10 remaining. I shifted which was run first to not give any preference to one test. Here are the results for the average time for each encode (25,000 times) (average of the 10 runs): Renderer 1: 145.8 ms Renderer 2: 138.5 ms Renderer 3: 149.4 ms Here is the time for one encodeAll invocation: Renderer 1: 0.00583 ms Renderer 2: 0.00554 ms Renderer 3: 0.00598 ms So as you can see, there is no measurable difference between the 3 with statistical error. The renderer 3 is slightly slower. The fact that renderer 2 is faster is probably a test anomaly, but you can see that it really doesn't make any difference. The only overhead is 2 more method invocations (calling delegateRenderer and encodeAll in that method). So method 2 (look up the sub-renderers in findTypeConstants) is just as fast and method 3, if deemed desirable is a small hit. I would recommend method 2, as I doubt method 3 would be desired. If you want to see the code, do a log with stop on copy on: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/ar_subRendererPerfTesting -Andrew
Re: [Trinidad] private / protected final methods in renderers
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] mailto:[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
Re: [Trinidad] private / protected final methods in renderers
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: [Trinidad] private / protected final methods in renderers
I like very much Andrew's idea of having more smaller renderers
and being able to override them the standard way (via faces-config.xml)
Also maybe some of you understood me wrong.
I didn't mean that all/most of the renderer methods should be protected.
But there are cases where it's needed.
Lets take for example some not so trivial scripts that are generated
in a private method,
which is called from a larger protected method.
If somebody wants to override the protected method,
it has to duplicate the script rendering method because he can't call it.
IMO it's not so hard to think of a stable method signature for that
kind of cases.
On 4/11/08, Martin Marinschek [EMAIL PROTECTED] wrote:
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
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: [Trinidad] private / protected final methods in renderers
Hey Martin (and all) - It seems to me that what this comes down to is how we view classes in trinidadinternal. There are a range of possible views here: 1. These classes are entirely private/off-limits, and if you want to extend one of these tough luck. No love for you. Go away. 2. These classes are entirely private/off-limits, however, if there is functionality here that our users legitimately need to extend, then we should try to facilitate that by promoting the functionality in question over to the public API (trinidadapi package), accepting the burden that this is, now, from here on out, part of our public API. 3. Hey, well, we all know that these classes are off-limits in spirit, but guess what, people are going to extend them, not for malicious purposes but because they are trying to solve a real problem. While moving functionality to the public API is the correct solution, we also recognize that this requires significantly more effort, and requires us to sacrifice future flexibility. Instead of paying this price, we prefer live with the fact that, yes, some small set of users might extend these, and that we might even need to make some tweaks in order to facilitate that, though we aren't willing to claim that these APIs are officially supported, and we make no guarantee that we won't break things in a future release. 4. The APIs in trinidadinternal should be part of our public API, officially supported, guaranteed not to change. I don't think that anyone is lobbying for #1 or #4. I think that Scott is in favor of #2. Note that this doesn't mean no love for Christi and the problems that he is trying to solve. Just that Scott's preferred way to solve these problems is by defining public APIs rather than have people depend on unofficial/unsupported/internal APIs. It sounds like several people are in favor of #3. I am somewhere on the fence between #2 and #3. I think that #2 is the correct thing to do, but I also believe that this is a significant burden, so I am tempted by #3 as a way to ease some of the frustration. Before we discuss questions like whether we should be breaking out renderers into smaller sub-renderers, or whether particular methods should be final/private/protected/whatever, I think we need to agree as a community what our stance is on on the question of how we view trinidadinternal. Andy
Re: [Trinidad] private / protected final methods in renderers
As someone who has experience in attempting to use Trinidad, I think #3 is a requirement for short term usage and #2 as the goal. What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through so that ppl can get work done, and then have users ask for the equivalent functionality to be promoted to the API in a later release. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Saying #2 only is a sure way to stop the myfaces community from using Trinidad. On 4/11/08, Andy Schwartz [EMAIL PROTECTED] wrote: Hey Martin (and all) - It seems to me that what this comes down to is how we view classes in trinidadinternal. There are a range of possible views here: 1. These classes are entirely private/off-limits, and if you want to extend one of these tough luck. No love for you. Go away. 2. These classes are entirely private/off-limits, however, if there is functionality here that our users legitimately need to extend, then we should try to facilitate that by promoting the functionality in question over to the public API (trinidadapi package), accepting the burden that this is, now, from here on out, part of our public API. 3. Hey, well, we all know that these classes are off-limits in spirit, but guess what, people are going to extend them, not for malicious purposes but because they are trying to solve a real problem. While moving functionality to the public API is the correct solution, we also recognize that this requires significantly more effort, and requires us to sacrifice future flexibility. Instead of paying this price, we prefer live with the fact that, yes, some small set of users might extend these, and that we might even need to make some tweaks in order to facilitate that, though we aren't willing to claim that these APIs are officially supported, and we make no guarantee that we won't break things in a future release. 4. The APIs in trinidadinternal should be part of our public API, officially supported, guaranteed not to change. I don't think that anyone is lobbying for #1 or #4. I think that Scott is in favor of #2. Note that this doesn't mean no love for Christi and the problems that he is trying to solve. Just that Scott's preferred way to solve these problems is by defining public APIs rather than have people depend on unofficial/unsupported/internal APIs. It sounds like several people are in favor of #3. I am somewhere on the fence between #2 and #3. I think that #2 is the correct thing to do, but I also believe that this is a significant burden, so I am tempted by #3 as a way to ease some of the frustration. Before we discuss questions like whether we should be breaking out renderers into smaller sub-renderers, or whether particular methods should be final/private/protected/whatever, I think we need to agree as a community what our stance is on on the question of how we view trinidadinternal. Andy
Re: [Trinidad] private / protected final methods in renderers
Hey Andrew - I think we are getting closer together, but not exactly there yet. :-) On Fri, Apr 11, 2008 at 10:10 AM, Andrew Robinson [EMAIL PROTECTED] wrote: As someone who has experience in attempting to use Trinidad, I think #3 is a requirement for short term usage and #2 as the goal. I can live with this. What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through I am not a fan of this. If people want to put in the effort to think through APIs that they expose on their renderers, then +1. But big -1 from me for exposing APIs haphazardly. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Because: 1. No matter what is said here and now in this thread, nobody likes it when things unexpectedly break when they pick up a new release. 2. There is another solution available. The other solution is to open things up in response to need. Since there is already a clear path for dealing with missing functionality (open an issue, submit a patch), I think we should use that. Of course, this means that if people go to the trouble of logging issues/submitting patches for changes in the Renderer code base, we have to be willing to take the time to think through/accept the proposed changes. Oh, and, that's not to say that if people have time to go through the Renderers and clean up the existing contracts, we shouldn't do that too. Just that while doing this some level of critical thinking needs to be applied. Andy
Re: [Trinidad] private / protected final methods in renderers
What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through I am not a fan of this. If people want to put in the effort to think through APIs that they expose on their renderers, then +1. But big -1 from me for exposing APIs haphazardly. My point is that protected in the trinidad-impl.jar is not an API that is exposed. Since it is not an API, therefore it does not have to be designed as such. Let me give you a valid use case (valid as it has happened to me while working on a project, not Trinidad, but similar open source issue): 1) Company decides to adopt Trinidad for a project 2) They are either (a) crunched for time or (b) need to get a release out 3) From mgmt, they are told they have to implement a feature 4) Trinidad has no way to support this feature, but the current renderer has a method that would allow me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, some afraid of maintenance). I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go.
Re: [Trinidad] private / protected final methods in renderers
I pretty much agree with everything Andy said here.. Andy Schwartz wrote: Hey Andrew - I think we are getting closer together, but not exactly there yet. :-) On Fri, Apr 11, 2008 at 10:10 AM, Andrew Robinson [EMAIL PROTECTED] wrote: As someone who has experience in attempting to use Trinidad, I think #3 is a requirement for short term usage and #2 as the goal. I can live with this. What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through I am not a fan of this. If people want to put in the effort to think through APIs that they expose on their renderers, then +1. But big -1 from me for exposing APIs haphazardly. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Because: 1. No matter what is said here and now in this thread, nobody likes it when things unexpectedly break when they pick up a new release. 2. There is another solution available. The other solution is to open things up in response to need. Since there is already a clear path for dealing with missing functionality (open an issue, submit a patch), I think we should use that. Of course, this means that if people go to the trouble of logging issues/submitting patches for changes in the Renderer code base, we have to be willing to take the time to think through/accept the proposed changes. Oh, and, that's not to say that if people have time to go through the Renderers and clean up the existing contracts, we shouldn't do that too. Just that while doing this some level of critical thinking needs to be applied. Andy
Re: [Trinidad] private / protected final methods in renderers
Andrew, That's a fair assesment, but that same pressed for time company will be angry when their stuff no longer works and those will turn into JIRA tickets. I'm not saying we shouldn't make Trinidad more flexible. I'm just saying that it's unrealistic to expose logic hap-hazardly. If this is a really big issue, and I believe that you and others think it is, then take the time to make it right. Think through the api's, clean them up, and put them in the api package. The Trinidad framework does offer a lot of flexibility for custom component development, it's just not at the granularity that some people want them to be. We don't expose specific renderers, just the rendering infrastructure. If there are components that people need to enhance/override then we should look at making those public, but really, how hard is it to write a renderer or (better yet IMO) make the renderers do what you want them to do though the use of attributes and better skinning? Scott Andrew Robinson wrote: What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through I am not a fan of this. If people want to put in the effort to think through APIs that they expose on their renderers, then +1. But big -1 from me for exposing APIs haphazardly. My point is that protected in the trinidad-impl.jar is not an API that is exposed. Since it is not an API, therefore it does not have to be designed as such. Let me give you a valid use case (valid as it has happened to me while working on a project, not Trinidad, but similar open source issue): 1) Company decides to adopt Trinidad for a project 2) They are either (a) crunched for time or (b) need to get a release out 3) From mgmt, they are told they have to implement a feature 4) Trinidad has no way to support this feature, but the current renderer has a method that would allow me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, some afraid of maintenance). I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go.
Re: [Trinidad] private / protected final methods in renderers
1) the company will not be angry, as I mentioned that I would be making the hack as a temporary solution, fully expecting that it will need to be converted later 2) It is impossible to control renderers 100% through component attributes and Skinning. For example, sometimes their DOM may just be wrong for someone (using a TABLE instead of a DIV...). If you ever tried to write an application using Trinidad you may understand ;) . Having huge amounts of attributes to make all the little things customizable would make (1) a really bad and hard to use API and (2) would have performance that sucked. If I want all my table components to render in a certain way, it is much better for me to customize the renderer than to have the renderer do if or switch statements on attributes all the time to customize how it does the rendering. On Fri, Apr 11, 2008 at 10:25 AM, Scott O'Bryan [EMAIL PROTECTED] wrote: Andrew, That's a fair assesment, but that same pressed for time company will be angry when their stuff no longer works and those will turn into JIRA tickets. I'm not saying we shouldn't make Trinidad more flexible. I'm just saying that it's unrealistic to expose logic hap-hazardly. If this is a really big issue, and I believe that you and others think it is, then take the time to make it right. Think through the api's, clean them up, and put them in the api package. The Trinidad framework does offer a lot of flexibility for custom component development, it's just not at the granularity that some people want them to be. We don't expose specific renderers, just the rendering infrastructure. If there are components that people need to enhance/override then we should look at making those public, but really, how hard is it to write a renderer or (better yet IMO) make the renderers do what you want them to do though the use of attributes and better skinning? Scott Andrew Robinson wrote: What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through I am not a fan of this. If people want to put in the effort to think through APIs that they expose on their renderers, then +1. But big -1 from me for exposing APIs haphazardly. My point is that protected in the trinidad-impl.jar is not an API that is exposed. Since it is not an API, therefore it does not have to be designed as such. Let me give you a valid use case (valid as it has happened to me while working on a project, not Trinidad, but similar open source issue): 1) Company decides to adopt Trinidad for a project 2) They are either (a) crunched for time or (b) need to get a release out 3) From mgmt, they are told they have to implement a feature 4) Trinidad has no way to support this feature, but the current renderer has a method that would allow me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, some afraid of maintenance). I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go.
Re: [Trinidad] private / protected final methods in renderers
Andrew Robinson said the following On 4/11/2008 8:53 AM PT: What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through I am not a fan of this. If people want to put in the effort to think through APIs that they expose on their renderers, then +1. But big -1 from me for exposing APIs haphazardly. My point is that protected in the trinidad-impl.jar is not an API that is exposed. Since it is not an API, therefore it does not have to be designed as such. Let me give you a valid use case (valid as it has happened to me while working on a project, not Trinidad, but similar open source issue): 1) Company decides to adopt Trinidad for a project 2) They are either (a) crunched for time or (b) need to get a release out 3) From mgmt, they are told they have to implement a feature 4) Trinidad has no way to support this feature, but the current renderer has a method that would allow me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) Rhetorical question--why would a company have such a policy? Because they want some guarantee that new Trinidad releases have gone through some set of testing and won't break their code. A pragmatic company would say sure, ship the hacked version. A less pragmatic company would say--just copy the code in the Renderer and then hack that. A few more comments. What happens if the code doesn't already have exactly the hook point you need? What are you going to do--hack in the hook point so that you can override it? One of the points that I believe that Cristi touched on is that deep inheritance hierarchies with large numbers of hooks and lots of delegation to other private code make it difficult to both figure out what is going on and difficult to actually copy the code for modification. One of the solutions is to make sure that we have enough public rendering utilities and that possibly some of the important aspects of delegating renderers and that it is possible to use the labeling renderer support without needing direct access to that Renderer. 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. As noted above, this is by the company's choice. They could have shipped the hacked version. The could have copied the code and then modified it. They did neither. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, There is no problem with the Apache license here, so the companies are being silly with Regards to Trinidad some afraid of maintenance). Your proposal that we make everything protected and tell the consumers to hope for the best on upgrades does not decrease their maintenance burden. -- Blake Sullivan I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go.
Re: [Trinidad] private / protected final methods in renderers
Andy Schwartz said the following On 4/11/2008 7:45 AM PT: Hey Andrew - I think we are getting closer together, but not exactly there yet. :-) On Fri, Apr 11, 2008 at 10:10 AM, Andrew Robinson [EMAIL PROTECTED] wrote: As someone who has experience in attempting to use Trinidad, I think #3 is a requirement for short term usage and #2 as the goal. I can live with this. What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through I am not a fan of this. If people want to put in the effort to think through APIs that they expose on their renderers, then +1. But big -1 from me for exposing APIs haphazardly. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Because: 1. No matter what is said here and now in this thread, nobody likes it when things unexpectedly break when they pick up a new release. 2. There is another solution available. An important point is that there is no practical difference between a customer of Trinidad hacking a private method to be protected and our taking a private method and making it protected with no thought or guarantee that it will be supported in the future. OK, they is a difference. In the case where the customer hacked the function, he had to do more work and knows that he will have to rehack the function in order to pick up a new version and knows that he might be hosed if the superclass code changed (which he should recheck when he reapplies his hack). -- Blake Sullivan The other solution is to open things up in response to need. Since there is already a clear path for dealing with missing functionality (open an issue, submit a patch), I think we should use that. Of course, this means that if people go to the trouble of logging issues/submitting patches for changes in the Renderer code base, we have to be willing to take the time to think through/accept the proposed changes. Oh, and, that's not to say that if people have time to go through the Renderers and clean up the existing contracts, we shouldn't do that too. Just that while doing this some level of critical thinking needs to be applied. Andy
Re: [Trinidad] private / protected final methods in renderers
Rhetorical question--why would a company have such a policy? Companies don't usually make sense, you must be one of those people that think Dilbert is fiction :) I have worked for more than one company that enforces this policy. They hate using open source for liability reasons, and hate you touching the code even more. What happens if the code doesn't already have exactly the hook point you need? Well if nothing was private or final this would never be the case would it? Unless the code was written badly and each function was too long. As noted above, this is by the company's choice. They could have shipped the hacked version. The could have copied the code and then modified it. They did neither. As I mention, this is a real world solution and your workaround is not viable. ...and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, There is no problem with the Apache license here, so the companies are being silly with Regards to Trinidad Not silly, it is actually a problem with liability. I don't agree with it really, but trust me, there are extremely good arguments for not modifying open source in a commercial product. Your proposal that we make everything protected and tell the consumers to hope for the best on upgrades does not decrease their maintenance burden. Why is it that this keeps coming back on hope and counting on the best? I keep saying that as a user, we *EXPECT* that it WILL break. The idea is a *temporary* solution until an API is available.
Re: [Trinidad] private / protected final methods in renderers
Andrew Robinson said the following On 4/11/2008 11:02 AM PT: Rhetorical question--why would a company have such a policy? Companies don't usually make sense, you must be one of those people that think Dilbert is fiction :) I have worked for more than one company that enforces this policy. They hate using open source for liability reasons, and hate you touching the code even more. And things would be better if they were told that any time they picked up a patch, it might blow up their code? What happens if the code doesn't already have exactly the hook point you need? Well if nothing was private or final this would never be the case would it? Unless the code was written badly and each function was too long. Unless there is a hook between every line in every function. There is no guarantee that the hooks are in the right place. As noted above, this is by the company's choice. They could have shipped the hacked version. The could have copied the code and then modified it. They did neither. As I mention, this is a real world solution and your workaround is not viable. It is viable. It may not be convenient. ...and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, There is no problem with the Apache license here, so the companies are being silly with Regards to Trinidad Not silly, it is actually a problem with liability. I don't agree with it really, but trust me, there are extremely good arguments for not modifying open source in a commercial product. Your proposal that we make everything protected and tell the consumers to hope for the best on upgrades does not decrease their maintenance burden. Why is it that this keeps coming back on hope and counting on the best? I keep saying that as a user, we *EXPECT* that it WILL break. The idea is a *temporary* solution until an API is available. Which we said is fine. They are free to modify the function to make it protected and ship the code. You have come up with an artificial reason for why they can not do this. This has definitely ceased being a productive discussion. -- Blake Sullivan
Re: [Trinidad] private / protected final methods in renderers
I don't necessarily agree with your last statement Blake. Some of us like to argue for argument's sake. :) Blake Sullivan wrote: Andrew Robinson said the following On 4/11/2008 11:02 AM PT: Rhetorical question--why would a company have such a policy? Companies don't usually make sense, you must be one of those people that think Dilbert is fiction :) I have worked for more than one company that enforces this policy. They hate using open source for liability reasons, and hate you touching the code even more. And things would be better if they were told that any time they picked up a patch, it might blow up their code? What happens if the code doesn't already have exactly the hook point you need? Well if nothing was private or final this would never be the case would it? Unless the code was written badly and each function was too long. Unless there is a hook between every line in every function. There is no guarantee that the hooks are in the right place. As noted above, this is by the company's choice. They could have shipped the hacked version. The could have copied the code and then modified it. They did neither. As I mention, this is a real world solution and your workaround is not viable. It is viable. It may not be convenient. ...and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, There is no problem with the Apache license here, so the companies are being silly with Regards to Trinidad Not silly, it is actually a problem with liability. I don't agree with it really, but trust me, there are extremely good arguments for not modifying open source in a commercial product. Your proposal that we make everything protected and tell the consumers to hope for the best on upgrades does not decrease their maintenance burden. Why is it that this keeps coming back on hope and counting on the best? I keep saying that as a user, we *EXPECT* that it WILL break. The idea is a *temporary* solution until an API is available. Which we said is fine. They are free to modify the function to make it protected and ship the code. You have come up with an artificial reason for why they can not do this. This has definitely ceased being a productive discussion. -- Blake Sullivan
Re: [Trinidad] private / protected final methods in renderers
Could we move this discussion away from a debate? Could MyFaces Committers or PMC members _only_ please share their thoughts on this to keep the discussion to the stake holders only? Please share other solutions as you have them. Here some view points to discuss: 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api 3) introduce some configurable way to override default behavior for rendering certain areas of components. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: 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
Re: [Trinidad] private / protected final methods in renderers
Hello, 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible No, it's way too messed up still to say that we're going to be backward compatible, ui and uinode for example and some renderer are messed up as well, they renderer what they need correctly bu are not necessarily as good as they should be (including some of mine) 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api I would be +1 to move resolveProperty and findTypeConstants to CoreRenderer; I would be +1 to move XhtmlRenderer to trinidad-api IF we were to clean it up first, it's the base renderer and there's some strangeness with it like some static methods that shouldn't really be static, has some redundant methods and/or parameters. There's also TypedRenderer interface that doesn't seem to be used anymore which is in the api that XhtmlRenderer implements. I don't think much more should be moved to api. Maybe we could create a enums or constant classes for XhtmlElement and XhtmlAttribute based on W3C, that would help save typos for renderer writer. Other than that, I don't see anything that semantically fit to be in api. When you want to redo a room decoration to make it more functional, it's often useful to start by cleaning it up. 3) introduce some configurable way to override default behavior for rendering certain areas of components. I don't think anyone would be against that as long as we don't have to ensure backward compatibility, but a simple, serious redesign of every component would probably do better than hooks. I kind of liked the reduced multiple renderers idea. It would complexify the delegation structure, but would also improve modularity and readability imho. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu Not taboo, but I think we should maintain the API may change without warning from a version to another notification in the doc. Again, rethinking (or simply thinking) the current renderer class structure and the method contract would probably do better than just ditching the final modifier. I think we need to create some rules and always follow them. One example is the main issue I get on when working with renderer extension, which is the parent renderer failing to call a non-final protected getter method to get an attribute value, either calling it directly from the bean and the property key, resulting in a NullPointerException if my component doesn't support that attribute or calling a protected method that I cannot override, under which case I do ditch the final modifier. 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu. Idem as 4. Regards, ~ Simon On Fri, Apr 11, 2008 at 3:04 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Could we move this discussion away from a debate? Could MyFaces Committers or PMC members _only_ please share their thoughts on this to keep the discussion to the stake holders only? Please share other solutions as you have them. Here some view points to discuss: 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api 3) introduce some configurable way to override default behavior for rendering certain areas of components. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: 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
Re: [Trinidad] private / protected final methods in renderers
BTW, I want to apologize to making this thread out to be such a mess and hope that I haven't damaged Christi's goal with improving the library. I tend to get too passionate about code and get quite bothered when only negative feedback is offered with no constructive comments to suggest forward movement. Just thought an apology was deserved. Thank you Simon for your constructive feedback. -Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: 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
Re: [Trinidad] private / protected final methods in renderers
Andrew Robinson wrote: Could we move this discussion away from a debate? Could MyFaces Committers or PMC members _only_ please share their thoughts on this to keep the discussion to the stake holders only? Please share other solutions as you have them. Here some view points to discuss: 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible I think the current code it to immature to allow this 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api +1, We should look at this on a library by library basis and scrutinize the code 3) introduce some configurable way to override default behavior for rendering certain areas of components. +1 +1, that's been my point all along 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu -0 for the reasons I stated. Trinidad is OpenSource, we've already given people enough rope to hang themselves with, no need to tie the noose for them as well. I would support this on an as-needed basis if that's what you mean by after discussion but these should be exceptions and SHOULD be hard to pass though in order to get people to think before they extend Impl classes. Not even in Regular Faces are the renderer's public which is why I think this discussion largely academic. 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu See comment to number 4 Christi, could you please share more of your needs and give further legitimate reasons why this is needed? Yeah, I mean we have in the past made things protected and non-final when it was needed for extensions, but it's always been by people who are not afraid to make commits. I would certainly be open to loosening API's for specific usecases, I was meerly against changing them carte-blanche. The *right* answer IMO though is #2 and #3. Scott If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: 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
Re: [Trinidad] private / protected final methods in renderers
Generally I really do agree with Simon that a simple, serious redesign of every component would probably do better than hooks. Also, I really think once you put restrictions on your renderers you run into issues, like you have a bug or a new feature which makes you need to reorganize in an unexpected way. I'm fine with making it easier to subclass renderers for those that want to take the risk, but I'm -1 on any scheme that restricts our ability to make changes when the need arises. Other comments inline: Andrew Robinson wrote: Could we move this discussion away from a debate? Could MyFaces Committers or PMC members _only_ please share their thoughts on this to keep the discussion to the stake holders only? Please share other solutions as you have them. Here some view points to discuss: 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible -1, the renderers have to be able to change without worrying about backwards compatibility. 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api Maybe I've misunderstood, but this sounds like it's basically the same as 1 but for pieces of a renderer, -1. 3) introduce some configurable way to override default behavior for rendering certain areas of components. That would be fine, as long as there's not a perf issue, and there's an understanding that things may break at the next release - hopefully rare, but possible. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu I think removing final modifiers AFTER discussion is fine, and I think if people want to risk extending renderers then fine, but we make no promises they will not break at the next release. Same for 5 below. Thanks, Gab 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? If you are not a member of MyFaces, Committer or PMC member please refrain from further reply to this thread as your feedback has already been noted. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: 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
Re: [Trinidad] private / protected final methods in renderers
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
Re: [Trinidad] private / protected final methods in renderers
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
Re: [Trinidad] private / protected final methods in renderers
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: [Trinidad] private / protected final methods in renderers
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
Re: [Trinidad] private / protected final methods in renderers
+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: [Trinidad] private / protected final methods in renderers
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
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
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
-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
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
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
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
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] private / protected final methods in renderers
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
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] mailto:[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] mailto:[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
Re: [Trinidad] private / protected final methods in renderers
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 understand
Re: [Trinidad] private / protected final methods in renderers
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] private / protected final methods in renderers
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
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
Re: [Trinidad] private / protected final methods in renderers
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 http://www.codebeat.ro
