DO NOT REPLY [Bug 34886] - [beanutils] Make long converter more resistant to extra white-spaces

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

DO NOT REPLY [Bug 34886] - [beanutils] Make long converter more resistant to extra white-spaces

Bugzilla from bugzilla@apache.org
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG?
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34886>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND?
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34886





------- Additional Comments From [hidden email]  2005-05-27 11:05 -------
Sorry, that's not what I meant by a use-case. What I meant was an explanation of
what kind of application would be feeding raw user data straight into a very
low-level library like beanutils.

Struts would be one such usecase - user data entered into an HTML form is mapped
to a bean on the webserver for further processing. Only it's not a usecase
because the recommended approach is to declare all fields on the "form bean" as
strings and then apply the validator library to the fields. Only once validation
has been run should the data be mapped to real data.

So what applications out there are feeding raw data into beanutils, and why
can't they validate first like struts-based apps do? (I presume validator also
does transformation like removing thousands-separators and normalising decimal
separators; does it?).

Again, please note that beanutils is a *low-level* library. As such, it needs to
put the emphasis on reliability and maintainability over features. That doesn't
mean it can't provide *any* features to its users, but the more code in
beanutils, the more bugs there will be. And the harder it will be to fix them.
And that's not good in a library that many other apps depend upon to provide
core functionality. So every feature added has to go through a "cost/benefit
analysis", and in particular a thorough justification for why that functionality
can't be implemented reasonably at a higher level (eg by using a validator
library as struts does).

Sorry to be so tough on your proposal, but adding to beanutils is not like
requesting a new feature in end-user program X. Someone needs to really show the
feature is necessary - and unfortunately I can't see that at the moment.
Handling bad user data - yes, that's useful - but why is it best done in beanutils?


--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]