@tres
An plugin/widget system is about widgets, not DOM elements.
If you have to extend jQuery adding some DOM related stuff, you will
continue to add that stuff to jQuery or jQuery.fn directly or with
extend().
Closures are great to make "private" things, but it requires that
"public" functions are defined inside that closure too. Good for
"singletons", not for prototyping...
On Aug 13, 2:12 am, tres <treshug...@gmail.com> wrote:
> And using:
>
> this.$el
>
> as the jQuery object array is cleaner than using just:
>
> this
>
> ??
>
> I think a big issue we have right now - and I am also partially guilty
> of this - is that we all want to have a part in this. In doing that we
> get blinded by thinking that our way is the best way.
>
> What I see a lot of people trying to do, is make JavaScript into
> something that it isn't. Call me crazy, but I don't think this is the
> proper way to go about this. Yes, it's a very, very flexible language,
> but it doesn't mean we need to change it's core behavior. This will
> come over time.
>
> For what it's worth, in my $.namespace, I implement a very similar
> method that jQuery's core does to implement its namespace and use
> 'this' as an array. You can apply objects to jQuery using the way ES
> intended objects to be used and constructed. Extending these plugins
> are done in the same exact way as ES intended: .prototype. Or if
> you're used to jQuery: .fn. This will allow for inheriting methods
> that will automate plugin configuration etc. if needed.
>
> // create your plugin
> $.fn.pluginName = $.namespace(constructor);
>
> // It doesn't require any special $.extend method, but you can use it:
> $.extend($.fn.pluginName.fn, {
> method1 : function() {},
> method2 : function() {}
>
> });
>
> // or inheritance from an object:
> $.extend($.fn.pluginName.fn, constructor.prototype);
>
> Introducing a whole new way to do something that you can already do
> and adding special rules for "readonly" methods (i.e. "_") immediately
> will make developing a widget/plugin for jQuery much less accessible
> and much less usable. You can already create private methods anyways:
>
> ;(function($) {
>
> // yes, this is 'private'
> function private() {};
>
> // but this is public
> $.fn.test = function() {
> // but you can use private here
> return private();
> };
>
> })(jQuery);
>
> Look, I am not trying to say that everyone needs to use my way, or
> that anyone does. I believe it is the best way to approach this -
> currently. But that is my opinion based on certain facts. I am also
> not trying to be arrogant or offensive, even though it may be. Sorry
> for that.
>
> On Aug 13, 9:29 am, DBJDBJ <dbj...@gmail.com> wrote:
>
> > The big picture
>
> > // this is so much more right
> > $('div').dialog().open();
> > // than this
> > $('div').dialog('open');
>
> > In more than one language, and there is more than one reason, too ...
>
> > Also. Are some "obsessed" with inheritance, here ?
> > This subject is "done and dusted" in the OO community, way way back,
> > in eighties.
> > If you have time, here is one balanced article (and also interesting
> > to this community ) :http://www.berniecode.com/writing/inheritance/
>
> > Etc ...
>
> > --DBJ
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
