Some great replies by Matt Kruse.
I'd like to propose, in addition:
13. In all but trivial circumstances, events and callbacks should
always be implemented with named functions. Invoking in-situ
anonymous functions and callbacks, as convenient as these may appear,
are eventually going to give somebody, somewhere, fits. We forget
this when we create trivial demos and code-examples.
-- Incidentally, I couldn't find any documentation, official or
otherwise, on callbacks (in general) and callback-seeding within
plugins (specifically) when I looked long-and-hard for this sometime
last week.
14. Extensibility means hooking "critical junctures". However end-
user usability means hooking "predictable junctures". To minimize
this dichotomy, first follow Matt's Rule #4 (All logic should be
broken up into the smallest logical chunk possible) so "critical
junctures" and "predictable junctures" are likely proximate. Next
consider hooking inherently predictable locations, for example the
very beginning of event code (i.e. pre-process native events) and the
very end of methods invoked by those events (i.e. post-process the
calls that emanate from events).
The main benefit of proscribing systematic extensibility at
predictable junctures is they are, by definition, easy to identify,
document, and conceptually convey.
THEREFORE, if there is merit to 13. and 14., in non-trivial plugins,
don't just blindly seed hot-spots with a callback opportunity.
Provide consistently-named function extensions, and seed for callbacks
at the very top of native events, and at the end of named-function
extensions.
**---** Steve
On Feb 24, 5:57 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
