Re: FormatNumberTag
Hello Henri, Yes, that would solve my immediate problem. It is a bit of a one-off hack, though. The follow-through would be to take a look at all the classes and identify areas where hooks like that would be desirable. It is perhaps a difference in philosophies of programming, but my preference is generally to use protected methods instead of private methods (and avoid final methods at all costs), and that would be my preferred approach here (I don't know your direct involvement thusfar into how things are). However, consistency is also good to see in a project, and it's not my show, so I'm less inclined to prosthelytize on how to do it right. I'd be glad to go on at length as to why I think the protected methods approach would be best, but will only do so upon request. Stuart Henri Yandell wrote: I didn't explain myself well. Basically I would insert reconfigureFormatter(NumberFormat/DateFormat) inside doEndTag. By default it would nothing. On Fri, Jul 10, 2009 at 5:03 AM, Stuart Thielstuart.th...@gmail.com wrote: - To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
Re: FormatNumberTag
Generally agreed. With public APIs I've learnt to be stronger on making things private as it tends to only come back to bite you if you try to over think it; and when it's public you have no ability to identify all the use cases so you end up in legacy hell. I just fix the bugs though - I wasn't an original developer :) I suspect their focus was strongly on implementing the spec and less on the implementation classes themselves. Hen On Sat, Jul 11, 2009 at 1:32 AM, Stuart Thielstuart.th...@gmail.com wrote: Hello Henri, Yes, that would solve my immediate problem. It is a bit of a one-off hack, though. The follow-through would be to take a look at all the classes and identify areas where hooks like that would be desirable. It is perhaps a difference in philosophies of programming, but my preference is generally to use protected methods instead of private methods (and avoid final methods at all costs), and that would be my preferred approach here (I don't know your direct involvement thusfar into how things are). However, consistency is also good to see in a project, and it's not my show, so I'm less inclined to prosthelytize on how to do it right. I'd be glad to go on at length as to why I think the protected methods approach would be best, but will only do so upon request. Stuart Henri Yandell wrote: I didn't explain myself well. Basically I would insert reconfigureFormatter(NumberFormat/DateFormat) inside doEndTag. By default it would nothing. On Fri, Jul 10, 2009 at 5:03 AM, Stuart Thielstuart.th...@gmail.com wrote: - To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
Re: FormatNumberTag
Here's a quote from the Spring docs about the open/closed principal that I think Henri is alluding to: “Open for extension...” One of the overarching design principles in Spring Web MVC (and in Spring in general) is the “Open for extension, closed for modification” principle. The reason that this principle is being mentioned here is because a number of methods in the core classes in Spring Web MVC are marked final. This means of course that you as a developer cannot override these methods to supply your own behavior... this is by design and has not been done arbitrarily to annoy. The book 'Expert Spring Web MVC and Web Flow' by Seth Ladd and others explains this principle and the reasons for adhering to it in some depth on page 117 (first edition) in the section entitled 'A Look At Design'. If you don't have access to the aforementioned book, then the following article may be of interest the next time you find yourself going “Gah! Why can't I override this method?” (if indeed you ever do). 1. Bob Martin, The Open-Closed Principle (PDF) Note that you cannot add advice to final methods using Spring MVC. This means it won't be possible to add advice to for example the AbstractController.handleRequest() method. Refer to Section 6.6.1, “Understanding AOP proxies” for more information on AOP proxies and why you cannot add advice to final methods. (The link to the pdf no longer works; it was going to www.objectmentor.com; I think you can still find it if you hunt around on that site. The name of the file is ocp.pdf.) Henri Yandell wrote: Generally agreed. With public APIs I've learnt to be stronger on making things private as it tends to only come back to bite you if you try to over think it; and when it's public you have no ability to identify all the use cases so you end up in legacy hell. I just fix the bugs though - I wasn't an original developer :) I suspect their focus was strongly on implementing the spec and less on the implementation classes themselves. Hen On Sat, Jul 11, 2009 at 1:32 AM, Stuart Thielstuart.th...@gmail.com wrote: Hello Henri, Yes, that would solve my immediate problem. It is a bit of a one-off hack, though. The follow-through would be to take a look at all the classes and identify areas where hooks like that would be desirable. It is perhaps a difference in philosophies of programming, but my preference is generally to use protected methods instead of private methods (and avoid final methods at all costs), and that would be my preferred approach here (I don't know your direct involvement thusfar into how things are). However, consistency is also good to see in a project, and it's not my show, so I'm less inclined to prosthelytize on how to do it right. I'd be glad to go on at length as to why I think the protected methods approach would be best, but will only do so upon request. Stuart Henri Yandell wrote: I didn't explain myself well. Basically I would insert reconfigureFormatter(NumberFormat/DateFormat) inside doEndTag. By default it would nothing. On Fri, Jul 10, 2009 at 5:03 AM, Stuart Thielstuart.th...@gmail.com wrote: - To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
Re: FormatNumberTag
Hello Rusty, I don't have the mentioned book, but I quickly found the article: http://www.objectmentor.com/resources/articles/ocp.pdf I'm afraid that such is not my interpretation of that article at all. It seems to clearly suggest that an inviolate superclass, that can be subclassed (what I propose would be facilitated by marking many of the now private methods protected) to modify behavior as needed, is the desired route for following the open-closed principle. What it does talk about is strategic closing, which has nothing to do with marking a method final, but is essentially an admission that nothing can be set in stone. Again, though, the changes I suggest would conform to the open-closed principle, and in fact would better support it than the current approach. That is, I'm suggesting to close the taglib classes against changes to interaction with their underlying java components (that's a vague target, and it may be more accurate to say that I want to make it so people can do whatever they want without having to change the parent classes, while getting the most out of the existing closed code). It also reminds that making member variables anything but private is a bad idea, and that explicit casting can make things brittle, but I am definitely not suggesting either. Actually, could you confirm that I'm reading the same article this is mentioned, although it seems to have been written by an R. Martin? Is the body of your quote the entire message? Have you read that article? Stuart Rusty Wright wrote: Here's a quote from the Spring docs about the open/closed principal that I think Henri is alluding to: “Open for extension...” One of the overarching design principles in Spring Web MVC (and in Spring in general) is the “Open for extension, closed for modification” principle. The reason that this principle is being mentioned here is because a number of methods in the core classes in Spring Web MVC are marked final. This means of course that you as a developer cannot override these methods to supply your own behavior... this is by design and has not been done arbitrarily to annoy. The book 'Expert Spring Web MVC and Web Flow' by Seth Ladd and others explains this principle and the reasons for adhering to it in some depth on page 117 (first edition) in the section entitled 'A Look At Design'. If you don't have access to the aforementioned book, then the following article may be of interest the next time you find yourself going “Gah! Why can't I override this method?” (if indeed you ever do). 1. Bob Martin, The Open-Closed Principle (PDF) Note that you cannot add advice to final methods using Spring MVC. This means it won't be possible to add advice to for example the AbstractController.handleRequest() method. Refer to Section 6.6.1, “Understanding AOP proxies” for more information on AOP proxies and why you cannot add advice to final methods. (The link to the pdf no longer works; it was going to www.objectmentor.com; I think you can still find it if you hunt around on that site. The name of the file is ocp.pdf.) Henri Yandell wrote: Generally agreed. With public APIs I've learnt to be stronger on making things private as it tends to only come back to bite you if you try to over think it; and when it's public you have no ability to identify all the use cases so you end up in legacy hell. I just fix the bugs though - I wasn't an original developer :) I suspect their focus was strongly on implementing the spec and less on the implementation classes themselves. Hen On Sat, Jul 11, 2009 at 1:32 AM, Stuart Thielstuart.th...@gmail.com wrote: Hello Henri, Yes, that would solve my immediate problem. It is a bit of a one-off hack, though. The follow-through would be to take a look at all the classes and identify areas where hooks like that would be desirable. It is perhaps a difference in philosophies of programming, but my preference is generally to use protected methods instead of private methods (and avoid final methods at all costs), and that would be my preferred approach here (I don't know your direct involvement thusfar into how things are). However, consistency is also good to see in a project, and it's not my show, so I'm less inclined to prosthelytize on how to do it right. I'd be glad to go on at length as to why I think the protected methods approach would be best, but will only do so upon request. Stuart Henri Yandell wrote: I didn't explain myself well. Basically I would insert reconfigureFormatter(NumberFormat/DateFormat) inside doEndTag. By default it would nothing. On Fri, Jul 10, 2009 at 5:03 AM, Stuart Thielstuart.th...@gmail.com wrote: - To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
Re: FormatNumberTag
I'm wondering if protected configureFormatter(NumberFormat) is best, or if the better option is to have a protected void reconfigureFormatter(NumberFormat) method that is invokved at the end of that method. So by default the configureFormatter is always run, and then the user can hook in to do whatever they want to the NumberFormat. A similar reconfigureFormatter(DateFormat) could be added to the FormatDateSupport class. What do you think? On Wed, Jul 8, 2009 at 1:55 PM, Stuart Thielstuart.th...@gmail.com wrote: Hello, A number of useful methods seem to be private. It makes sub-classing the taglibs inconvenient. For example, I would like to extend FormatNumberTag so that I can change the grouping separator. If configureFormatter in org.apache.taglibs.standard.tag.common.fmt.FormatNumberSupport were protected, instead of private, I could simply wrap it up and extend it in a few lines of code and let polymorphism do its thing. As it stands, I'll need to duplicate most of the code from FormatNumberSupport. -- Stuart Thiel - To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
Re: FormatNumberTag
Hello Henri, Having a protected configureFormatter (and similar things for other methods elsewhere) is my preferred approach. The issue with the second approach is that doEndTag() calls createFormatter(), then configureFormatter, then formats the text. There's no facility to step in between and make changes. If the other methods stayed private, we'd have to re-implement them if we re-implemented doEndTag() anyway. So there is nothing gained by having a reconfigureFormatter(DateFormat). On Fri, Jul 10, 2009 at 3:25 AM, Henri Yandell flame...@gmail.com wrote: I'm wondering if protected configureFormatter(NumberFormat) is best, or if the better option is to have a protected void reconfigureFormatter(NumberFormat) method that is invokved at the end of that method. So by default the configureFormatter is always run, and then the user can hook in to do whatever they want to the NumberFormat. A similar reconfigureFormatter(DateFormat) could be added to the FormatDateSupport class. What do you think? -- Stuart Thiel