On Feb 18, 7:01 am, Mike Alsup <mal...@gmail.com> wrote: > I guess it depends what you want to change. Using extend you can > redefine any of the public functions, but the private functions will > remain private.
I've found that many plugins simply aren't that extensible. This is very bad design, IMO. Only in the simplest cases are plugins a perfect fit for someone's needs. I've ripped apart plugins before because I liked some of what was there, but it didn't allow enough extensibility to allow me to do what I want in the context of a specific web app. In my opinion, there is no need for ANY method in a plugin to be private. Doing so is saying that the author knows all possible uses for the code, and they can be certain that no one will ever want to do anything differently than how they wrote it. There is simply no reason to make anything private. Expose everything. Just in case. Also, many plugins have long methods that perform a bunch of logic, rather than splitting it into multiple functions that can be easily over-ridden and customized. I had to fix a problem with BlockUI a while ago and was disappointed that I had to over-ride a huge function and copy all the logic in it to change one single line. Bad design. I've written a context menu plugin that I think has a better framework: http://www.javascripttoolbox.com/lib/contextmenu/ http://plugins.jquery.com/project/cmenu In this plugin (written partly as an educational exercise) I have tried to separate code functionality into logical pieces, and allow _everything_ to be extensible by the user. This allows greater freedom and flexibility, and I've already seen the code used in ways I hadn't imagined when I wrote it. I am of course open to any suggestions or critiques. Plugins, IMO, seem to be the weakest link when implemting jQuery, and it would be great if there were some better models and guidelines for plugin development that would make the end results better for everyone. Matt Kruse
