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