Re: [Springframework-developer] DataBinder < BindException

[<jue...@we...>]

I'm aware that you didn't ask for a change - you just uncovered some =
earlier thoughts of mine :-) I've just reworked DataBinder and =
ServletRequestDataBinder to contain a BindException instead of derive =
from it. That should give the best of both worlds, i.e. exception =
functionality and non-Exception data binders.
=20
Command and form controller implementations should not have to change, =
as they're only seeing a ServletRequestDataBinder on initBinder anyway, =
where they are just supposed to call binder methods, not the formerly =
inherited BindException methods. Code that uses BindUtils should not =
have to change too.
=20
Just custom usage of ServletRequestDataBinder will have to call =
getErrors to get a BindException instance instead of just passing the =
data binder itself like before. We'll note that in the release mail.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rim, Mark
Gesendet: Fr 14.11.2003 01:43
An: spr...@li...
Betreff: [[W3-SPAM]] - RE: [Springframework-developer] DataBinder < =
BindException - Email found in subject



i'm not asking for it to be changed. a major change like that will =
probably have to wait until after 1.0 is released. i'm trying to get a =
deeper understanding of the framework.

just from the names, it seems to me that BindException should extend =
Exception. but where i have trouble is, the justification for DataBinder =
extending BindException. does a DataBinder also need to be thrown and be =
treated as an Errors instance ? or is it convenient to re-use some of =
the BindException routines in DataBinder ?

a lot of the routines in BindException look like they'd be useful in a =
something that would bind values to beans ...



> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
> Sent: Thursday, November 13, 2003 5:36 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] DataBinder < BindException
>
>
> That's an early design decision that goes to back to Rod's
> original com.interface21 version of the framework. As far as
> I understand the rationale, BindException extends Exception
> because this allows to throw the binding status as exception
> if binding errors are to be considered fatal. The thrown
> exception can then be treated as Errors instance for
> convenient checking of the contained errors. This is of
> course a rarely used feature, as binding errors are normally
> not considered fatal.
>=20
> Unfortunately, this has the disadvantage of having not only
> BindException but also its subclasses in the "Exceptions"
> category of the generated javadoc. I'm not really happy about
> that, but the alternative of dropping the exception feature
> and thus not making BindException an Exception also involves
> the obvious need to rename that default implementation of the
> Errors interface. That in turn would mean changing the
> signatures of quite a few template methods in the command and
> form controllers, breaking current implementations.
>=20
> I'm not sure if such a change is worth the effort... What do
> others think?
>=20
> Juergen

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
This message is for the named person's use only. It may contain =
sensitive and private proprietary or legally privileged information. No =
confidentiality or privilege is waived or lost by any mistransmission. =
If you are not the intended recipient, please immediately delete it and =
all copies of it from your system, destroy any hard copies of it and =
notify the sender. You must not, directly or indirectly, use, disclose, =
distribute, print, or copy any part of this message if you are not the =
intended recipient. CREDIT SUISSE GROUP and each legal entity in the =
CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business =
units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all =
e-mail communications through its networks. Any views expressed in this =
message are those of the individual sender, except where the message =
states otherwise and the sender is authorized to state them to be the =
views of any such entity.
Unless otherwise stated, any pricing information given in this message =
is indicative  only, is subject to change and does not constitute an =
offer to deal at any price quoted. Any reference to the terms of =
executed transactions should be treated as  preliminary only and subject =
to our formal written confirmation.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer