Nathan Bubna wrote:
If i may be forgiven one last push... :)
Let's keep the story straight--you wouldn't have to edit the old apps
to make them work with 1.5. You just have to set the config property,
not really a great burden. We could even make the message with the
thrown exception point out the new config property, so that those who
don't read change logs or release notes will have no problem figuring
out what's going on.
That means you can't just upgrade and have things work. You have to
upgrade and reconfigure.
I'd make it work like 1.4 by default, turn on new behavior w/ a switch,
and fix it in 2.0
geir
On 3/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
I feel strongly about this.
I've personally got hundreds of templates in production and support users
with hundreds more. Say 5% of those templates have this error. (It's not
hard to make -- note that the Velocity test suite for Anakia contains this
error). All of a sudden I have tens of templates, scattered all over the
place that suddenly cause errors. All of those apps work right now- why do
I want them to fail? Anything that requires me to edit old apps to make
Velocity 1.5 work is not backwards compatible. (and will retard adoption of
1.5).
It would have been nicer if this had always generated an error. For new
apps this is better. But for old apps it is actively harmful to change
this. So let's make this a config option and turn it on by default for 2.0
.
WILL
On 3/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote:
On 3/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
I'm starting to agree with you, Llwellyn. Though I don't think we
should
change the behavior of the templates for existing users.
even if the behavior is buggy/broken? it's not like the extra or
missing arguments were doing anything functionally. throwing an
exception, however, will add functionality (as Malcom demonstrated.
we already warned that their macro call was broken in the logs, i
think it is fair to escalate that to an exception, especially if we
provide a config option to log instead of throw an exception.
of course, if you feel strongly about this, i won't -1 a log-only
default, and i'll let them that do the work implement it the way they
want :). it's just my opinion; i won't be dogmatic on it. :)
WILL
On 3/21/06, Llewellyn Falco <[EMAIL PROTECTED]> wrote:
Personally, i feel that templates whose macro calls don't match up
to
the macro definitions are *already* broken.
this is my general thought on the whole thing too.
and as we deal in financial transactions, I take a general view of
it is better not to show something than to show something wrong.
however, I can understand that in an entertainment situation you might
have
the exact opposite view.
again though, I think this goes back to a 2 modes of running.
development - always halt on errors - someone's there to fix them.
deployment - do the best you can - log what goes wrong
and see a setting much more in this idea.
btw: this is also why I always develop with the UberspectTestImpl and
rather
think that it should be default Uberspect, while currently it is only
in
the
test classes.
Llewellyn.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
