Using a distinct password form - or even another page - might help
emphasize that dealing with the Google password field is different from
an ordinary edit (like changing your time zone or window for synch),
and sort of avoid my worry. But the question of spoofing the output with
a static string of 7 or 8 "*" chars remains.
I guess I can create an element id in the existing BeanEditor editor
override, which now looks like:
<t:parameter name="googlePassword">
<t:label for="googlePassword"/>
<t:passwordfield t:id="googlePassword"
value="formUser.googlePassword"/>
</t:parameter>
Michael Prescott wrote:
Consider putting the change-password fields in another form? Either that or
hiding them until the user indicates that they're trying to carry out this
optional operation.
Michael
On Thu, Mar 26, 2009 at 4:15 PM, Charles Coleman <ccole...@email.unc.edu>wrote:
Hi,
My group is working on a little application that will enable users to set
up synchronization between Oracle Calendar and Google Calendar. The user's
interface includes a password field where they must provide their Google
password (if they wish to use the application). The password is encrypted
and stored in a database for later use by the synch job.
PasswordField of course does not render out any content, which I
understand. The reasons for this were well-explained here a few months ago.
However, in this application, I am concerned that the appearance of an empty
field on the user profile page will lead people to worry that their password
needs to be re-entered, and I'd like it to render out a little string of
"*******" instead.
It looks like the relevant render method in the 5.0.18 source is final; so
it seems that my only recourse is to make my own custom component, or
perhaps to use a litttle Javascript to put some dummy content in that field.
Is that right? Of course, I need to look at the 5.1 source still, but, I
suspect, it is final there as well.
The PasswordField is in a BeanEditor, and I'm not even sure if I can get
the element ID to try an adhoc JavaScript trick.
Thanks,
Charles Coleman
Charles E. Coleman
Academic Applications Developer
Office of Arts & Sciences Information Services
University Of North Carolina at Chapel Hill
CB 3056, 06 Howell Hall
Chapel Hill, NC 27599-3056
919.xxx.xxxx (Direct Line)
ccole...@email.unc.edu
AIM: oasisccoleman
http://oasis.unc.edu/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
