[jQuery] Re: What am I missing from this plugin?
On 7/23/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote: 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. I see. Thanks.
[jQuery] Re: What am I missing from this plugin?
Stephan Beal wrote:
On Jul 22, 11:57 pm, Klaus Hartl [EMAIL PROTECTED] wrote:
IMHO it is bad practice to store that element in the self, i.e. jQuery,
object.
...
A simple var should be sufficient.
jQuery.fn.myPlugin = function(targetField) {
var textfield = jQuery(targetField);
...
};
Assuming we need to hold on to the target long-term (e.g., in inner
functions or even classes), would this be a more acceptable approach
to using self to sort the jQuery object:
jQuery.fn.myPlugin = function(targetField) {
var self = this;
self.target = targetField;
...
var textfield = jQuery(self.target);
...
};
?
The difference is that this one is holding the selector string, and
not the jQuery object (unless, of course, the user passes a jQ as
targetField).
But that doesn't make any difference. It would still overwrite a
property named target of the jQuery object.
You have to know jQuery very well to not accidently use a name that
isn't already in use. And who knows if jQuery 1.1.4 does not introduce a
target property on the jQuery object? Jörn described that very well a
while ago in another thread - I think that was related to one of your
plugins ;-)
Again, a var should be sufficient using closures. Or if you need to
store things in another object, create a new one but do not use the
jQuery object.
--Klaus
[jQuery] Re: What am I missing from this plugin?
On Jul 23, 9:26 am, Klaus Hartl [EMAIL PROTECTED] wrote:
But that doesn't make any difference. It would still overwrite a
property named target of the jQuery object.
Ah, i now see what you mean. Yes, that would of course be a danger.
You have to know jQuery very well to not accidently use a name that
isn't already in use. And who knows if jQuery 1.1.4 does not introduce a
target property on the jQuery object? Jörn described that very well a
while ago in another thread - I think that was related to one of your
plugins ;-)
Very possibly - i liberally use custom fields to store internal data.
i'll have to go revisit that approach.
Again, a var should be sufficient using closures. Or if you need to
store things in another object, create a new one but do not use the
jQuery object.
Thanks for the clarification.
Something to consider for jQuery:
In my embedded JS code i often create top-level classes for my
applications, e.g.:
function MyApp() { ... }
Then i want client code to be able to safely store their own data in
there without colliding with mine, so i do:
MyApp.client = {};
And that becomes the public place to store any client-specific data,
and my app promises not to touch that field. For example, i have an
ncurses JS wrapper and a small framework built on top of it for
providing basic ncurses app functionality. In that framework i specify
that MyApp.client is the place where client-side code can store their
data, and in my apps i use MyApp.client.windows to store my client-
specific ncurses windows. Here's a screenshot demonstrating what i
mean:
http://spiderape.sourceforge.net/screenshots/ape-20050910.png
(somewhere in there is an object called ApeWS.windows.client - near
the bottom/left)
i think jQuery could benefit from the same idea, with the intention
being that plugin authors have a safe haven where they can attach
data to jQuery objects.
:)
[jQuery] Re: What am I missing from this plugin?
On 7/18/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote: 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? 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? Thanks, Chris.
[jQuery] Re: What am I missing from this plugin?
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
[jQuery] Re: What am I missing from this plugin?
On Jul 22, 2:16 am, barophobia [EMAIL PROTECTED] wrote:
I think I understand but how do I handle the #passwordField part
within the plugin?
In your plugin implementation, simply store a reference to the
#passwordField passed to your plugin. For example, if you plugin looks
like this:
jQuery.fn.myPlugin = function(targetField) {
var self = this;
self.textfield = jQuery(targetField);
... do whatever you normally do ...
... updates of the text field are applied to self.textfield ...
... you can use self.textfield in inner functions, e.g. those
defined as click() handlers ...
}
Now you can call:
$('#button').myPlugin('#IDForSomeTextField');
[jQuery] Re: What am I missing from this plugin?
Stephan Beal wrote:
On Jul 22, 2:16 am, barophobia [EMAIL PROTECTED] wrote:
I think I understand but how do I handle the #passwordField part
within the plugin?
In your plugin implementation, simply store a reference to the
#passwordField passed to your plugin. For example, if you plugin looks
like this:
jQuery.fn.myPlugin = function(targetField) {
var self = this;
self.textfield = jQuery(targetField);
... do whatever you normally do ...
... updates of the text field are applied to self.textfield ...
... you can use self.textfield in inner functions, e.g. those
defined as click() handlers ...
}
Now you can call:
$('#button').myPlugin('#IDForSomeTextField');
IMHO it is bad practice to store that element in the self, i.e. jQuery,
object.
You may eventually overwrite a jQuery core or plugin method on that
special object. That'll hard to track down.
A simple var should be sufficient.
jQuery.fn.myPlugin = function(targetField) {
var textfield = jQuery(targetField);
...
};
--Klaus
[jQuery] Re: What am I missing from this plugin?
On Jul 22, 11:57 pm, Klaus Hartl [EMAIL PROTECTED] wrote:
IMHO it is bad practice to store that element in the self, i.e. jQuery,
object.
...
A simple var should be sufficient.
jQuery.fn.myPlugin = function(targetField) {
var textfield = jQuery(targetField);
...
};
Assuming we need to hold on to the target long-term (e.g., in inner
functions or even classes), would this be a more acceptable approach
to using self to sort the jQuery object:
jQuery.fn.myPlugin = function(targetField) {
var self = this;
self.target = targetField;
...
var textfield = jQuery(self.target);
...
};
?
The difference is that this one is holding the selector string, and
not the jQuery object (unless, of course, the user passes a jQ as
targetField).
[jQuery] Re: What am I missing from this plugin?
On 7/18/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote:
You need to var the generate_to variable in the click handler. Currently
it's a global variable, which makes the second instance overwrite the first
instance. Change:
generate_to = $(this).attr('for');
to:
var generate_to = $(this).attr('for');
Thanks. This works perfectly.
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.)
I think I understand but how do I handle the #passwordField part
within the plugin?
Thanks,
Chris.
