On Feb 24, 5:44 pm, John Resig <jere...@gmail.com> wrote:
> > 3. Users should be able to over-ride defaults at the plugin level
> > (true for all instances) or per-instance
> Do you mean something like: .myplugin({ myprop: "override" }) where
> passing in the option overrides it for that instance? (I think that's
> what you meant, just wanted to clarify.)I'm not sure if you mean what I mean :) For example, in my context menu plugin (which is the only plugin I've published so far as an example of some of the concepts I promote): http://www.javascripttoolbox.com/lib/contextmenu/ source: http://www.javascripttoolbox.com/libsource.php/contextmenu/source/jquery.contextmenu.js You can do this: $.contextMenu.shadow = false; This will set the default value of the 'shadow' property to false for all instances created from then on. So what I typically do is include the contextmenu plugin, then in a separate include file per project I will setup the defaults. From then on, everywhere I use the plugin in the app I don't have to worry about setting it up, I can just use it in the "default" state. If I want to over-ride defaults for one specific context menu, I can do it using the options array like: $(".context").contextMenu( [menu] , {options} ); > > 5. No assumptions should be made about the user's environment. For > > example, don't blindly append newly created DOM elements to the body. > Do you mean in the sense that appending to the body is bad - or that > "body" is a static word and thus should be a mutable option in the > plugin (#8). The latter. I've had situations where appending objects to the body caused issues (because of weird layouts, etc). I've also had some situations where I wanted newly-created objects to be children of a specific container, not of the whole body. It's just one example of a situation where a plugin author may assume that every object like an absolutely-position menu should be appended to the body, but by making it configurable it gives the developer flexibility without negatively impacting the plugin functionality at all. > > 10. Pass in an {options} parameter instead of a hard-coded list of > > options > I think the corollary to this would be: If you start having optional > arguments you should really push your users towards using the > {options} object exclusively. Agreed. And required attributes should be hard-coded parameters before the {options}. > This gives a lot to work with, though. I think I'll probably do a > quick re-write of the jQuery.plugin stuff to try and codify some of > these notions. I hope you'll take a quick look at http://www.javascripttoolbox.com/libsource.php/contextmenu/source/jquery.contextmenu.js I don't propose it as a perfect or ideal solution. But it's one approach, and I've built a template from it that I use in developing new plugins. There are some places in the code where I could do some re-writes to better incorporate my own guidelines! Matt Kruse --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
