FormatNumberTag

[Stuart Thiel <st...@gmail.com>]

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

Re: FormatNumberTag

[Stuart Thiel <st...@gmail.com>]

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 Thiel<st...@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 Thiel<st...@gmail.com>
>>>> wrote:
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org

Re: FormatNumberTag

[Rusty Wright <ru...@gmail.com>]

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 Thiel<st...@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 Thiel<st...@gmail.com>
>>> wrote:
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org

Re: FormatNumberTag

[Henri Yandell <fl...@gmail.com>]

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 Thiel<st...@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 Thiel<st...@gmail.com>
>> wrote:
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org

Re: FormatNumberTag

[Stuart Thiel <st...@gmail.com>]

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 Thiel<st...@gmail.com> wrote:
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org

Re: FormatNumberTag

[Henri Yandell <fl...@gmail.com>]

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 Thiel<st...@gmail.com> wrote:
> 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 <fl...@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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org

Re: FormatNumberTag

[Stuart Thiel <st...@gmail.com>]

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 <fl...@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

Re: FormatNumberTag

[Henri Yandell <fl...@gmail.com>]

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 Thiel<st...@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-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org