Seriously, we have to do away with such one-off hacks and provide support for such common use cases in the framework. I was thinking today that as much as the "blanking" of the password fields represents best practice for handling passwords, it still seems that a whole bunch of uses of the password field become unpleasantly complicated because of it. Is there a possibility of making the default PasswordField behavior to blank out the value, but provide a flag to the component that would output it ?
Overall, my point is that in situations like this "write your own component" seems to be unacceptable advice. A newcomer to the framework shouldn't have to write custom components to solve common problems, they should be solved by the framework.. Just my 2c. Cheers, Alex K On Tue, Sep 2, 2008 at 1:23 PM, Thiago H. de Paula Figueiredo < [EMAIL PROTECTED]> wrote: > Em Tue, 02 Sep 2008 11:27:32 -0300, Markus Joschko < > [EMAIL PROTECTED]> escreveu: > > Hi Ulrich, >> the current PasswordField component always blanks the value. >> If you really want to keep the password (might result into security >> and usability issues as the user has no chance to check whether the >> value is valid and the password will be unencrypted in the HTML), >> write your own password component that extends from AbstractTextField >> but does not blank the value. >> > > My approach is a little bit radical: I disable the password field when > editing an user and provide another form jsut for password changes. > > Thiago > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
