On Feb 24, 3:57 pm, John Resig <jere...@gmail.com> wrote:
> Does anyone have
> any examples of plugins that they wished to extend in a particular
> manner? (I needed the validation plugins X method to do Y - examples
> like that.)
Many!
I've had to re-write BlockUI, Autocomplete, accordian, bgiframe,
context menu, etc. Others I have abandoned completely because they
were overly restrictive. I don't recall the reason in each case.
I've arrived at some guidelines I think should be followed when
writing plugins:
1. No method should be private. Not every method needs to be part of
the API, but don't hide any logic from being customized by a
developer. Just because you can't imagine a case where someone would
need to change the internal logic doesn't mean it won't happen.
2. All static values (strings, class names, numbers, defaults, etc)
should be stored as plugin properties that can be changed
3. Users should be able to over-ride defaults at the plugin level
(true for all instances) or per-instance
4. All logic should be broken up into the smallest logical chunks
possible. Each method should have a very specific task, which can be
over-ridden if needed
5. No assumptions should be made about the user's environment. For
example, don't blindly append newly created DOM elements to the body.
Allow the user to over-ride this default behavior if they wish. Don't
assume you know how to calculate a container's size using the built-in
jquery methods - separate that logic out to a function so I can
customize it if needed. In general, AVOID ASSUMPTIONS.
6. Any time HTML is created inside the plugin, generate it inside a
function that can be over-ridden if the user wants to generate
something slightly different
7. If your plugin has dependencies, do a quick check up-front to make
sure they are there, otherwise alert the developer
8. Any time you have static quoted text (or id's or class names, or
element names, etc), you better have a really good reason for assuming
that the user would never want to change it. And if you have a reason,
it's probably not good enough.
9. Provide many options, but also provide a logical default
implementation. Let the user do as little as possible to begin using
the plugin in a reasonable way, then show them just how much power
they have to customize it.
10. Pass in an {options} parameter instead of a hard-coded list of
options
11. Provide useful examples
12. Use a good code structure like ;(function($){ })(jQuery) and other
common recommendations
That's a short brain-storm at least. Key concept when writing a
general-use plugin - Avoid Assumptions! :)
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
-~----------~----~----~----~------~----~------~--~---
