Chris,

>> Also, I think I'd change the plug-in a bit. IMO, I would make more sense
>to
>> use like:
>>
>> $("#button").generate_password("#passwordField", iLength);
>>
>> That way you can attach the behavior to any element. Also, by using a
>> selector for the field to update, you could update multiple fields with
>the
>> same value (in those cases where you had both a password and confirm
>> password fields.)
>
>So are you saying that #button will have already been created by the
>user in their HTML and that #passwordField is where the generated text
>should be placed? And beyond that #passwordField could be something
>like .place_generated so that when #button is clicked it sticks the
>generated text into all boxes that have a class of .place_generated?

Yes, the "#button" element would already exist and you'd be attaching the
behavior to that element.

The "#passwordField" would be any valid jQuery selector. You'd just use this
string do something like:

$(arguments[0]).val("new generated password");

This would allow the user the ability to populate multiple fields or a
single field--depending on their selector.

>This sounds like a fine idea except that I wanted it to be
>unobtrusive. If someone doesn't have JS enabled I don't want to have a
>lame-duck button sitting there.
>
>Can it still be unobtrusive but use your suggestion at the same time?

Making it be unobtrusive would be up the developer. The easy way to do this
would be for the user to "hide" the button via CSS and show it after attach
your plug-in. 

The developer could also make their button be able to automatically generate
a password by submitting back to the server and generate a password for user
via server-side processing and reserve the page with the new password.

The problem with generating the button automatically is that there's no way
to control the position of the development--which is important for UI.

-Dan

Reply via email to