I'm a little scared of jumping into this, but I feel I'd like to make a few quick points, as I've run up against these issues myself.
1. I've scheduled time for myself and my team to re-build the plugins site next week. The goal initially is simply to re-create the existing functionality in a more maintainable way, but I'd love to see features added like the following: - Developer uploads his JS, and a gzipped, compressed and/or minified version is automatically generated - Developer specifies in a structured way dependent plugins. This opens up the potential for a plugin and their dependencies to be automatically generated and downloaded. I've love to get all the feedback we can, we have a wiki to help collect and organize things: http://jqueryplugins.pbwiki.com/FrontPage 2. I've been bumping up against the data issue for a few months now on various projects. I admittedly have not spent time trying to do it *right*, due to project constraints. I've built a jQuery plugin to manage the data layer in my application, choosing to do it as a plugin for the reasons explained above. If I had to do this task again right now, I'd choose to do it the same way. John's widget code presents a very interesting possibility though. If the jQuery team adopted a few choice plugins, like a debugging plugin, a data layer plugin, and by putting the widget code into the core, allowed these plugins to be extended, I think a very powerful foundation would be provided to developers. jQuery is about providing choice, and with the size of the user base, all of the choices that are made are magnified 100-fold. So, they cannot be taken lightly. 3. Lastly, I'm involved with collecting and writing down the latest information and practices of building jQuery plugins, and using jQuery in large projects. The group of developers who use jQuery in large projects is small, but important. Large projects are growing in number, and a good foundation is needed, we just need to be careful. My 2 cents. Thanks! Mike Hostetler http://amountaintop.com On Tue, Feb 24, 2009 at 12:51, Justin Meyer <justinbme...@gmail.com> wrote: > > JS is Object Oriented. So are we really just talking about classical > inheritance (and even more specific, _super) ? > > I see how widget.js creates a plugin. But how does one expand on the > plugin? > > I'm more than happy with widget.js if you can easily expand on the > widget. For example, quickly added a delegated hoverenter that will > show a tooltip, or change an existing function. > > I don't think super is necessary at all. I've only used it a few > times, never needed it. But if you let go of _super, and you are able > to easily expand the widget, how is that different than what you are > considering OOP? > > > > > On Feb 24, 1:22 pm, John Resig <jere...@gmail.com> wrote: > > > Quick comments: > > > > > On OOP and not being convinced. What other approaches are you hinting > > > at? OOP being well understood is a valid argument only because > > > inheritance and OO does provide reuse. If you have something that > > > does work in many cases, you are allowed to factor in popularity and > > > understandability. > > > > For example, the widget plugin that I pointed to. I keep talking about > > it so I'll just link to it again: > http://dev.jquery.com/~john/plugins/widget/widget.js<http://dev.jquery.com/%7Ejohn/plugins/widget/widget.js> > > > > This is a case where many of the problems (or complexities) that exist > > in advanced jQuery plugins are already taken care of: extensibility, > > encapsulation, and reusability. > > > > I consider this to be a good example of introducing a selective piece > > of jQuery functionality that'll help developers but without doing a > > wholesale import of OOP techniques. > > > > > Why do you think this would contribute to jQuery bloat anymore than > > > jQuery.UI does? > > > > Because jQuery UI isn't, or doesn't, have the ability to become a > > dependency for nearly every plugin created. As I mentioned before, > > most developers look at the tool of Classes as the be-all and end-all > > of development patterns. Introducing that in a sanctioned manner will > > instantly make it a dependency of countless plugins, at which point we > > would be required to include it in core, out of necessity. It seems > > like it would be a much better option to produce a plugin/widget > > construction utility that solves all the problems that advanced jQuery > > developers encounter, in a style that meshes well with the jQuery > > philosophy, rather than a wholesale import of OOP concepts. > > > > --John > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
