Matt, I generally agree with all of your suggestions, and I believe
that if they are applied in practice it will benefit all those who
deal with jquery in one way or another. Having said that, it is highly
unlikely that all those suggestions will be implemented by the
majority of users. These things need to be prioritised and well
documented. I agree with John in that documentation is the single most
important issue that must be addressed.
Also, I do feel that implementing MVC and OOP patterns in the core is
not what jQuery is for. Having them as separate (well documented)
plugin(s) is most practical. And if developers start to implement them
(rightfully or not) to such extend as to question their inclusion in
the core, I think having different versions of jQuery core (e.g.
jQuery, jQuery + MVC) is again the most practical solution. All these
assuming that such plugin(s) will be maintained and improved by the
community, just like jQuery UI.
Some people have raised the issue of data handling and how jQuery
seems not to support this. I must say that I agree with this notion,
even though I haven't really looked into the source of jQuery to make
sure. I have recently started a library, if I may call it this way,
which tries to apply jquery's philosophy (syntax actually) to data
handling (I have JSON in mind). I don't want to 'pollute' this
discussion by providing a link, so if anyone is interested reply back
to me and I'll post it back (hint: jdatastore).
To sum up, I'm all up for documentation and plugin authoring
guidelines in particular. I'll be waiting to see how John's widget
extension ends up and how it can be used.
Cheers
On Feb 25, 12:57 am, 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
-~----------~----~----~----~------~----~------~--~---
