Not at all. We are not here to flame or insult anyone. This is a development group discussion. Yes, tempers and passion flare, and sometimes things can be mistaken for arrogance, but I think that a lot of people will be with me on that we are actually here to discuss the future of jQuery rather than insult people. Insulting people isn't worth my time or anyone else's and doesn't get anyone anywhere. Although we all want to help and have a hand in jQuery, I think our end result should be to further the development and future of the library as a team, not individuals. Just because we aren't part of the core team doesn't mean we aren't a team.
Please, back to the actual topic... On Aug 13, 11:49 am, Robert Katić <robert.ka...@gmail.com> wrote: > @tres > > Haha. Are you insulting me? > > On Aug 13, 3:05 am, tres <treshug...@gmail.com> wrote: > > > > > @robert > > > But widgets are all about DOM elements. So why shouldn't a widget > > system be? > > > I don't know about you, but I want the ability to add a multi-method > > API to jQuery without cluttering it's namespace. Namespace clutter is > > bad practice. > > >http://www.javascripttoolbox.com/bestpractices/, scroll to: Avoid > > Cluttering The Global Namespace, it also has links for closures and > > private members > > I know this talks about the global namespace, but this can very well > > be applied to the jQuery namespace. > > >http://www.dustindiaz.com/namespace-your-javascript/, another way for > > private members, but similar in practice > > > As for who expects .dialog() to return a namespace rather than display > > something: When you call jQuery, what does it return? (Hint: a > > namespace) > > > On Aug 13, 10:43 am, Robert Katić <robert.ka...@gmail.com> wrote: > > > > @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 -~----------~----~----~----~------~----~------~--~---
