[jquery-dev] Re: New $() behaviour
Blog posts of dubious quality, like this one, http://jquery-howto.blogspot.com/2009/07/identifying-locating-mouse-position-in.html , have frequently peddled this bit of info. Again, I'm totes in favour of this happening, but am just mentioning that this type of code does exist. Support for $().ready() makes a big difference... On Dec 13, 9:42 pm, aHeckman aaron.heckm...@gmail.com wrote: I like the change. even if it breaks some code here and there. The previous behavior was too much magic and confusing to any developer that hasn't peered under the covers. On Dec 13, 8:24 pm, John Resig jere...@gmail.com wrote: The most frequent case I've seen is $().ready() (which still works and I plan on continuing to make work, at least for the time being). I haven't really seen other cases being used in the wild - do you have any examples? --John On Sun, Dec 13, 2009 at 8:06 PM, ajpiano ajpi...@gmail.com wrote: A recent commit -http://github.com/jquery/jquery/commit/04524287d3e0112deae570ff9247c7... - changed the behaviour of $() from $(document) to $([]). This is a change that I can truly jibe with, and I think the behaviour makes sense. No one likes having to do $([]) to create an empty jQuery object. Unfortunately, no change for 1.4 has made me think will break a lot of people's code like this one. For some inane reason, people (and a lot of tutorials) really started using the $() shortcut, so the change kind of makes me somewhat uneasy. Would love to hear any other perspectives on this. Should the change stay in and be loudly shouted as a potential 1.4 transition issue, or rolled back? -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/jquery-dev?hl=en. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@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.
[jquery-dev] Re: new version policies - specifically RE: sibling selector in 1.3.2
Ah. I wasn't aware of the 1.3.3 skip. Two to three months sounds fairly ideal. Go, go, go! Thanks for the follow-up. _jason On Nov 13, 3:15 pm, John Resig jere...@gmail.com wrote: The problem is that, at this point, we're going for 1.4 so it'll be hard for us to integrate it immediately. Although, the solution that you outline isn't completely ideal, either. Having too many releases causes users to never upgrade, for fear of another release coming out soon. We've found that the optimal release cycle is around 2-3 months for point release, 1 year for major release. Of course we missed the 1.3.3 release, but that's mostly because the team decided to push through and go straight for 1.4, instead. --John On Fri, Nov 13, 2009 at 2:41 PM, Jason Persampieri papp...@gmail.com wrote: Pardon me for being a little late to this particular party :) I just ran in to the Broken sibling selector in 1.3.2 bug that was discovered and fixed at the end of March (7 months ago!). I've worked around it by removing the blocks of code specified in the bug report and re-minifying it. But I wonder why I had to do that. Why not release a version 1.3.3 (or 1.3.2.1) that fixes this? It's seems to be a very simple fix for a relatively major feature and could potentially save a lot of debugging time. Should *every* bug get a point release? Of course not. But 1.3.2 has been the 'latest stable release' for quite a while, no? Honestly, it may be close enough to 1.3.3 (or whatever the next big version is) for this particular issue to matter, but for future development, this would make jQuery seem even more production-ready than it already is. Just for context, I actually had to upgrade from 1.3.1 in order to fix the clone of a clone issue in IE. _jason -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/jquery-dev?hl=. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@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=.
[jquery-dev] Re: New Feature: optional IE fixes
Or we could have separate jQuery for each browser ? As we are discussing in length at jQuery dinamyc composition thread ;o) --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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new option for validate() (code included)
validate is a jQuery plugin... you should discuss about your upgrade in some discussion board about the plugin... here we discuss about jQuery core -- everything has got to end sometime we were satellites drifting off into space vega 4 - burn and fade away --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new option for validate() (code included)
ok, after testing this myself i found a few issues... here is the
revised changes/line numbers
209: errorElement: label,
ADDED 210: errorElementClass: ,
211: focusInvalid: true,
450: errors: function() {
ADDED 451: var errorElementClassToUse =
this.settings.errorElementClass.length 1 ?
this.settings.errorElementClass : this.settings.errorClass;
CHANGED 452: return $( this.settings.errorElement + . +
errorElementClassToUse , this.errorContext );
453: },
616: // refresh error/success class
CHANGED 617: label.removeClass().addClass
( this.settings.errorElementClass.length1?
this.settings.errorElementClass : this.settings.errorClass );
618:
619:// check if we have a generated label, replace the message then
620: label.attr(generated) label.html(message);
621:} else {
622:// create label
623:label = $( + this.settings.errorElement + /)
624:.attr({for: this.idOrName(element), generated: true})
CHANGED 625:.addClass(this.settings.errorElementClass.length1?
this.settings.errorElementClass : this.settings.errorClass)
626:.html(message || );
627:if ( this.settings.wrapper ) {
i have posted the revised jquery.validate.js here:
http://pastebay.com/41589
here is an example usage:
$(#myform).validate({
errorElementClass:someClass,
errorClass: anotherClass
})
again, let me know what i need to do to help get this commited.
thanks
On Aug 21, 12:41 pm, IT cla...@gmail.com wrote:
i think this belongs in the bug tracker, but wanted to post here first
for thoughts...
While using the validator i ran into some confusion in trying to set a
separate style (class) to the the invalid element and its label.
There are some complicated ways of setting this defined within the
documentation using the highlight option... but its not as easy as it
could be for something seemingly common.
to make things easier, i have added an additional option to the
validator method called errorElementClass. IF this option is set,
when the label is rendered, the class attribute of the label is set
toerrorElementClass, if errorElementClass is not set, the existing
option errorClass is applied. Because errorClass is used if
errorElementClass is not set, this change is backwards compatible with
existing code.
this only takes two changes within the latest version of
jquery.validate.js here are the affected line numbers:
209: errorElement: label,
ADDED 210: errorElementClass: error,
211: focusInvalid: true,
623: .attr({for: this.idOrName(element), generated: true})
CHANGED 624: .addClass(this.settings.errorElementClass.length 1 ?
this.settings.errorElementClass : this.settings.errorClass )
625: .html(message || );
does this make sense? or is this redundant with some other
functionality i am unaware of? if this change makes sense, let me
know how best to go about getting it incorporated into the next
release.
Thanks
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[jquery-dev] Re: New callback for ajax: receiving handling readyState == 3
Therefore I added some simple code to handle my need, however I can't get it to work in IE7/8 or Safari 3.2.3 but it does work in FF 3.0.10 ,Opera 9.64 and Chrome 2.0.172.28 (with a slight delay). I'm not sure what symptoms you're experiencing, but... Are you expecting every request to go through readyState==3? That isn't guaranteed. An XHR can go from 2 to 4. Also, jQuery uses polling -- not an event -- to check readyState, so if XHR went to 3 for a very short time it might not be caught by a poll anyway. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new project - fluidIA - open source UI prototyping based on jQuery
Thanks Paul. :) On May 21, 10:49 pm, Paul Bakaus paul.bak...@googlemail.com wrote: Hey Jakub, this looks really cool! I'm cc'ing my friend Tom here, since he had a very similar idea some time ago, and I'm sure he's interested in learning more about your approach. Cheers, Paul On Fri, May 22, 2009 at 9:13 AM, Jakub jlinow...@gmail.com wrote: Hello, A year ago, on a part time basis I started an open source user interface prototyping project -www.fluidIA.org. Recently this turned into a grad project. Seeing the powerful potential of jQuery, I've relied on this Javascript library to build this browser based application. The tool aims to empower interaction designers and developers to quickly generate wireframes/prototypes, and more so, allows for rapid refinement through object orientation and inheritance. Support for state based objects has also been already implemented. A working Firefox copy is running over at: http://stage.fluidia.org For the fluidIA project, one of my upcoming tasks is also to explore the ability to create a UI for jQuery's event handling capabilities. In turn, this could result in something of a WYSIWYG editor for event based interactions. However, for more powerful logic and data binding, the environment will also support the ability to toggle fluidIA objects and replace them with real code, should developers wish to program the desired interactions. In a way then, these objects can act as guiding or exploratory ideas which would then evolve to proper code. Here are two very rough sketches of this: http://fluidia.org/wp/?p=192 (toggle) http://fluidia.org/wp/?p=94 (low-fi events) So why am I writing about all this here? Well, so far I've been a one man army doing design, development and recently user testing. Just thought to throw the project up here should there be any interested developers / designers in participating. I'm really a generalist (visual and interaction designer by education), and thought it would be cool to work with some pro developers on this. 1. So far I've opened the source over at: http://github.com/fluidia/fluidia/tree/master 2. I have also opened up the design process: http://fluidia.org/wp/?category_name=sketches where I am interested in contributions from others as well. (Am really interested in running an open source + open design project and see how designers could collaborate with developers.) 3. Google Groups:http://groups.google.com/group/fluidia Should any jQuery gurus be interested in working on this project, please let me know. Would love to hear from you. Cheers, Jakub Linowski www.fluidia.org www.linowski.ca -- Paul Bakaus UI Architect --http://paulbakaus.comhttp://www.linkedin.com/in/paulbakaus --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new project - fluidIA - open source UI prototyping based on jQuery
Jakub, I have an open source project that is supposed to provide some railable patterns to jquery/jquery ui. The on-going idea is to provide some very general patterns to allow ui development to become more automated. jquery-claypool provides mvc, routing, lazy loading, dependency injection, filters (aop), category logging, convention-over-configuration, while not requiring any sort of inheritence dependencies. It very light weight and even supports server-side development. My real goal for it has been for minimal generated code to allow flexible ui or commandline integration with jquery-ui/jquery, like flash/flex for jquery, while still adhering to the jquery-way as much as possible. jquery-claypool is not jquery or jquery-ui, nor is it what your doing, but it strongly compliments their goals without duplicating them. http://github.com/thatcher http://claypooljs.com http://docs.jquery.com/Plugins/Claypool It very stable, very minimal, very extensible, and very understable for folks who come from application framework backgrounds like django, rails, spring, etc. It was very recently releases as a 1.0 though I've used it for about a year and a half in development and it will be released with a library of congress production project in about 12 days. I will contribute effort if you decide to use it. Thanks, Thatcher On Sun, May 24, 2009 at 8:00 PM, Jakub jlinow...@gmail.com wrote: Thanks Paul. :) On May 21, 10:49 pm, Paul Bakaus paul.bak...@googlemail.com wrote: Hey Jakub, this looks really cool! I'm cc'ing my friend Tom here, since he had a very similar idea some time ago, and I'm sure he's interested in learning more about your approach. Cheers, Paul On Fri, May 22, 2009 at 9:13 AM, Jakub jlinow...@gmail.com wrote: Hello, A year ago, on a part time basis I started an open source user interface prototyping project -www.fluidIA.org. Recently this turned into a grad project. Seeing the powerful potential of jQuery, I've relied on this Javascript library to build this browser based application. The tool aims to empower interaction designers and developers to quickly generate wireframes/prototypes, and more so, allows for rapid refinement through object orientation and inheritance. Support for state based objects has also been already implemented. A working Firefox copy is running over at: http://stage.fluidia.org For the fluidIA project, one of my upcoming tasks is also to explore the ability to create a UI for jQuery's event handling capabilities. In turn, this could result in something of a WYSIWYG editor for event based interactions. However, for more powerful logic and data binding, the environment will also support the ability to toggle fluidIA objects and replace them with real code, should developers wish to program the desired interactions. In a way then, these objects can act as guiding or exploratory ideas which would then evolve to proper code. Here are two very rough sketches of this: http://fluidia.org/wp/?p=192 (toggle) http://fluidia.org/wp/?p=94 (low-fi events) So why am I writing about all this here? Well, so far I've been a one man army doing design, development and recently user testing. Just thought to throw the project up here should there be any interested developers / designers in participating. I'm really a generalist (visual and interaction designer by education), and thought it would be cool to work with some pro developers on this. 1. So far I've opened the source over at: http://github.com/fluidia/fluidia/tree/master 2. I have also opened up the design process: http://fluidia.org/wp/?category_name=sketches where I am interested in contributions from others as well. (Am really interested in running an open source + open design project and see how designers could collaborate with developers.) 3. Google Groups:http://groups.google.com/group/fluidia Should any jQuery gurus be interested in working on this project, please let me know. Would love to hear from you. Cheers, Jakub Linowski www.fluidia.org www.linowski.ca -- Paul Bakaus UI Architect --http://paulbakaus.comhttp://www.linkedin.com/in/paulbakaus -- Christopher Thatcher --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new project - fluidIA - open source UI prototyping based on jQuery
Hey Jakub, this looks really cool! I'm cc'ing my friend Tom here, since he had a very similar idea some time ago, and I'm sure he's interested in learning more about your approach. Cheers, Paul On Fri, May 22, 2009 at 9:13 AM, Jakub jlinow...@gmail.com wrote: Hello, A year ago, on a part time basis I started an open source user interface prototyping project - www.fluidIA.org. Recently this turned into a grad project. Seeing the powerful potential of jQuery, I've relied on this Javascript library to build this browser based application. The tool aims to empower interaction designers and developers to quickly generate wireframes/prototypes, and more so, allows for rapid refinement through object orientation and inheritance. Support for state based objects has also been already implemented. A working Firefox copy is running over at: http://stage.fluidia.org For the fluidIA project, one of my upcoming tasks is also to explore the ability to create a UI for jQuery's event handling capabilities. In turn, this could result in something of a WYSIWYG editor for event based interactions. However, for more powerful logic and data binding, the environment will also support the ability to toggle fluidIA objects and replace them with real code, should developers wish to program the desired interactions. In a way then, these objects can act as guiding or exploratory ideas which would then evolve to proper code. Here are two very rough sketches of this: http://fluidia.org/wp/?p=192 (toggle) http://fluidia.org/wp/?p=94 (low-fi events) So why am I writing about all this here? Well, so far I've been a one man army doing design, development and recently user testing. Just thought to throw the project up here should there be any interested developers / designers in participating. I'm really a generalist (visual and interaction designer by education), and thought it would be cool to work with some pro developers on this. 1. So far I've opened the source over at: http://github.com/fluidia/fluidia/tree/master 2. I have also opened up the design process: http://fluidia.org/wp/?category_name=sketches where I am interested in contributions from others as well. (Am really interested in running an open source + open design project and see how designers could collaborate with developers.) 3. Google Groups: http://groups.google.com/group/fluidia Should any jQuery gurus be interested in working on this project, please let me know. Would love to hear from you. Cheers, Jakub Linowski www.fluidia.org www.linowski.ca -- Paul Bakaus UI Architect -- http://paulbakaus.com http://www.linkedin.com/in/paulbakaus --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
It would be quite nice if. $ ( defined as: )
function(selector, context) {
// The jQuery object is actually just the init
constructor
'enhanced'
return new jQuery.fn.init(selector, context);
}
if the above will have a few sanity checks so that one can do this :
try {
jq = $(..., ..) ;
} catch ( x )
{
// x.number === jQuery.error_code
// x. message == jQuery error message
}
This would remove 90% of issues and will explain to a lot of people a
lot about jQuery ...
PS: of course to even start jQuery in the presence of serious abuses
like Object.prototype extensions one is always welcomed to start from
http://dbj.org/jquery.1.3.2.safe.slow.js
-- DBJ
On May 19, 2:13 pm, Julian Aubourg aubourg.jul...@gmail.com wrote:
Oh yes, I understood, I was just answering to the last statement you made in
your previous post about logging rather than throwing exceptions :)
2009/5/19 David Zhou da...@nodnod.net
Well, there's no reason not to throw exceptions too. The point was a
script that monkeypatched jQuery to allow for some of the debugging
features being discussed.
-- dz
On Tue, May 19, 2009 at 9:00 AM, Julian Aubourg
aubourg.jul...@gmail.com wrote:
I dunno.
From what I witnessed, when jQuery starts to complain/halt, the problem
is
generally elsewhere, especially when you keep references to nodes/select
results like I personnaly do. Exceptions would be nice imo, so that you
get
the callstack. Logs are good as long as all of the application being
developped is heavily consoled or else you won't know anything about
the
context of the problem.
Of course, I'm talking from the point of view of someone who develops
sites
that are ultra-heavy in the js department.
2009/5/19 David Zhou da...@nodnod.net
I wonder if it's feasible to monkeypatch debugging wrappers around
jQuery core methods. You don't even need it to throw errors -- a
simple console.log warning would suffice.
-- dz
On Tue, May 19, 2009 at 8:38 AM, Julian Aubourg
aubourg.jul...@gmail.com wrote:
jquery.debug.js / jquery.release.js ? ;)
I really like this idea. When I first started using jQuery, I
sometimes
had
some issues determining what it was I was doing wrong when jQuery
complained
deep in its internal functions.
2009/5/19 Matt Kruse m...@thekrusefamily.com
On May 19, 5:32 am, DBJDBJ dbj...@gmail.com wrote:
This is an discussion on library develeopment philosophy.
There are only two sides to this coin: fast and dangerous and safe
and
slow.
I think this is another use for a jQuery development build. One
that
would generate warnings of empty selector results, invalid arguments,
etc. It could also detect possible conflicts like this that would
cause jQuery to misbehave and alert the developer.
Once development is done, you swap in the production version of
jQuery and avoid the penalty his that comes with all the debug stuff.
Matt Kruse- Hide quoted text -
- Show quoted text -
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[jquery-dev] Re: new $
Where am I blaming the jQuery ? I was not clear enough. I suggest my strategy. Unashamedly. Task : help to the company which tried to switch to jQuery but failed. 1. have ready: jquery.1.3.2.safe.slow.js (with all the gotchas you can think off, added ) 2. impose it 3. when dust settles on the battlefiled switch back to jquery.1.3.2.js Job done -- DBJ On May 18, 3:14 pm, Ricardo ricardob...@gmail.com wrote: Anyone works within the constraints of his knowledge and tools. Not protecting code from Object.prototype (yet) has been a design decision to not sacrify performance just to tolerate bad practice, afaik. From your other example, do you think car companies should limit the car's max speed to avoid complaints? I don't think so. You're repeatedly complaining about jQuery's intolerance on bad code and flexibility at the same time. The only issue at play here is the lack of understanding of the library, javascript and debugging by those you mention. I mean, you're blaming jQuery on below intermediate coder's errors, that's like blaming the car for a bad driver. Fix that and everything will be fine, or just forget trying to push the library onto unwilling developers. jQuery has few restrictions, just reading the docs is enough to adapt, have they? cheers On May 17, 8:51 pm, DBJDBJ dbj...@gmail.com wrote: @Andrea Here is a very nice and very recent example of what am I talking about, please find it in the thread : Error in attr when adding function to Object.prototype Options ... The proverbial Object.prototype ;o) Please go and explain to the developer who started this thread, why is jQuery not to blame that it does not work in presence of Object.prototype abuse. He is blaming jQuery and everyone who tried to explain why is there no logic in extending Object.prototype. He will rather have it, and not use the jQuery. I (usually) do not waste time in that kind of discussions and just place: for ( var j in Object,prototype ) delete Object.prototype[j] ; on the top of my jQuery file. Which then I impose ;o) --DBJ On May 17, 2:46 pm, Andrea Giammarchi andrea.giammar...@gmail.com wrote: jQuery is a library, not a language ... new $ where $ return a new something else is allowed by JavaScript specs ... it is not an error, syntax speaking, it is just like people using whatever.toString() rather than + whatever ... you are creating a drama over a truly simple and common mistake for unskilled JS developers but still, it does not harm anybody and if the application does not work is not because of new $. I am sure you have hundreds of valid arguments about their bad practices, but tell them that their code is crap and cannot work because new $ is allowed ( by JavaScript itself, it is NOT jQuery ) is an error as well. It is not about JavaScript panorama only, there are crap developers for evey languages and actually truly skilled developers are rare but nobody cares that much ... I see horrors in famouse PHP CMS every day but these CMS are famous I have seen crappy logic in pieces of Zend Framework but it is suppose to be enterprise I cannot blame anybody using a programming language in a bad way as long as results are somehow reached ... I agree that this would have been a better world if every paid developers was truly senior but I cannot find a single argument in this thread about jQuery, sorry. On Sun, May 17, 2009 at 2:00 PM, DBJDBJ dbj...@gmail.com wrote: Allow me to be very clear: Issue is in MOUNTAIN of legacy javascript/css/html ... Company X decides to improve its portal or whatever horrid pile of sugar they might have amassed, and then yet another team is made to do it. Which usually consist of visual basic/delphi/sql/asp developers who are all avid followers of jQuery. They simply include jQuery in these pages , and then ... nothing works. Then they struggle for approx few weeks and just then they declare that jQuery is very bad and then they either revert back to ASP or JSP or whatever horros you can think of. But. Minority admits they need to learn a bit more and then they call people in to help them out. This is where we usaly come in. And this is where we use my version of jQuery to show them where are they making mistakes and for us to understand what is going on. And then fun starts when the legacy code has to be removed/destroyed/ forgotten. In those moments I would like Ricardo and Andrea to stand in front of these (by now highly annoyed) managers and developers and tell them : .. jQuery does it work as it's supposed to, it's not it's duty to enforce good practices ... or alert users of javascript syntax errors... What is the issues here is the jQ usage patterns not jQ itself. And this is a very big mountain to climb for a very big portion of
[jquery-dev] Re: new $
@Peter Always refreshing to meet a JavaScript guru, helping with a guru device ;) @ALL This is an discussion on library develeopment philosophy. There are only two sides to this coin: fast and dangerous and safe and slow. Library developers task is to find a balance between the two. But, it is very difficult to balnce on the edge. jQuery is (currently) fast and dangerous, which is very popular choice it seems. Unless one is burnt when trying to make a mess out of legacy javascript +css+html and introduce jQuery in the same time. -- DBJ On May 18, 4:36 pm, pete higgins phigg...@gmail.com wrote: From your other example, do you think car companies should limit the car's max speed to avoid complaints? I don't think so. Some do. http://en.wikipedia.org/wiki/Governor_(device) Regards, Peter --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
On May 19, 5:32 am, DBJDBJ dbj...@gmail.com wrote: This is an discussion on library develeopment philosophy. There are only two sides to this coin: fast and dangerous and safe and slow. I think this is another use for a jQuery development build. One that would generate warnings of empty selector results, invalid arguments, etc. It could also detect possible conflicts like this that would cause jQuery to misbehave and alert the developer. Once development is done, you swap in the production version of jQuery and avoid the penalty his that comes with all the debug stuff. 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
jquery.debug.js / jquery.release.js ? ;) I really like this idea. When I first started using jQuery, I sometimes had some issues determining what it was I was doing wrong when jQuery complained deep in its internal functions. 2009/5/19 Matt Kruse m...@thekrusefamily.com On May 19, 5:32 am, DBJDBJ dbj...@gmail.com wrote: This is an discussion on library develeopment philosophy. There are only two sides to this coin: fast and dangerous and safe and slow. I think this is another use for a jQuery development build. One that would generate warnings of empty selector results, invalid arguments, etc. It could also detect possible conflicts like this that would cause jQuery to misbehave and alert the developer. Once development is done, you swap in the production version of jQuery and avoid the penalty his that comes with all the debug stuff. 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
I wonder if it's feasible to monkeypatch debugging wrappers around jQuery core methods. You don't even need it to throw errors -- a simple console.log warning would suffice. -- dz On Tue, May 19, 2009 at 8:38 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: jquery.debug.js / jquery.release.js ? ;) I really like this idea. When I first started using jQuery, I sometimes had some issues determining what it was I was doing wrong when jQuery complained deep in its internal functions. 2009/5/19 Matt Kruse m...@thekrusefamily.com On May 19, 5:32 am, DBJDBJ dbj...@gmail.com wrote: This is an discussion on library develeopment philosophy. There are only two sides to this coin: fast and dangerous and safe and slow. I think this is another use for a jQuery development build. One that would generate warnings of empty selector results, invalid arguments, etc. It could also detect possible conflicts like this that would cause jQuery to misbehave and alert the developer. Once development is done, you swap in the production version of jQuery and avoid the penalty his that comes with all the debug stuff. 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
I dunno. From what I witnessed, when jQuery starts to complain/halt, the problem is generally elsewhere, especially when you keep references to nodes/select results like I personnaly do. Exceptions would be nice imo, so that you get the callstack. Logs are good as long as all of the application being developped is heavily consoled or else you won't know anything about the context of the problem. Of course, I'm talking from the point of view of someone who develops sites that are ultra-heavy in the js department. 2009/5/19 David Zhou da...@nodnod.net I wonder if it's feasible to monkeypatch debugging wrappers around jQuery core methods. You don't even need it to throw errors -- a simple console.log warning would suffice. -- dz On Tue, May 19, 2009 at 8:38 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: jquery.debug.js / jquery.release.js ? ;) I really like this idea. When I first started using jQuery, I sometimes had some issues determining what it was I was doing wrong when jQuery complained deep in its internal functions. 2009/5/19 Matt Kruse m...@thekrusefamily.com On May 19, 5:32 am, DBJDBJ dbj...@gmail.com wrote: This is an discussion on library develeopment philosophy. There are only two sides to this coin: fast and dangerous and safe and slow. I think this is another use for a jQuery development build. One that would generate warnings of empty selector results, invalid arguments, etc. It could also detect possible conflicts like this that would cause jQuery to misbehave and alert the developer. Once development is done, you swap in the production version of jQuery and avoid the penalty his that comes with all the debug stuff. 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
Well, there's no reason not to throw exceptions too. The point was a script that monkeypatched jQuery to allow for some of the debugging features being discussed. -- dz On Tue, May 19, 2009 at 9:00 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: I dunno. From what I witnessed, when jQuery starts to complain/halt, the problem is generally elsewhere, especially when you keep references to nodes/select results like I personnaly do. Exceptions would be nice imo, so that you get the callstack. Logs are good as long as all of the application being developped is heavily consoled or else you won't know anything about the context of the problem. Of course, I'm talking from the point of view of someone who develops sites that are ultra-heavy in the js department. 2009/5/19 David Zhou da...@nodnod.net I wonder if it's feasible to monkeypatch debugging wrappers around jQuery core methods. You don't even need it to throw errors -- a simple console.log warning would suffice. -- dz On Tue, May 19, 2009 at 8:38 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: jquery.debug.js / jquery.release.js ? ;) I really like this idea. When I first started using jQuery, I sometimes had some issues determining what it was I was doing wrong when jQuery complained deep in its internal functions. 2009/5/19 Matt Kruse m...@thekrusefamily.com On May 19, 5:32 am, DBJDBJ dbj...@gmail.com wrote: This is an discussion on library develeopment philosophy. There are only two sides to this coin: fast and dangerous and safe and slow. I think this is another use for a jQuery development build. One that would generate warnings of empty selector results, invalid arguments, etc. It could also detect possible conflicts like this that would cause jQuery to misbehave and alert the developer. Once development is done, you swap in the production version of jQuery and avoid the penalty his that comes with all the debug stuff. 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
Oh yes, I understood, I was just answering to the last statement you made in your previous post about logging rather than throwing exceptions :) 2009/5/19 David Zhou da...@nodnod.net Well, there's no reason not to throw exceptions too. The point was a script that monkeypatched jQuery to allow for some of the debugging features being discussed. -- dz On Tue, May 19, 2009 at 9:00 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: I dunno. From what I witnessed, when jQuery starts to complain/halt, the problem is generally elsewhere, especially when you keep references to nodes/select results like I personnaly do. Exceptions would be nice imo, so that you get the callstack. Logs are good as long as all of the application being developped is heavily consoled or else you won't know anything about the context of the problem. Of course, I'm talking from the point of view of someone who develops sites that are ultra-heavy in the js department. 2009/5/19 David Zhou da...@nodnod.net I wonder if it's feasible to monkeypatch debugging wrappers around jQuery core methods. You don't even need it to throw errors -- a simple console.log warning would suffice. -- dz On Tue, May 19, 2009 at 8:38 AM, Julian Aubourg aubourg.jul...@gmail.com wrote: jquery.debug.js / jquery.release.js ? ;) I really like this idea. When I first started using jQuery, I sometimes had some issues determining what it was I was doing wrong when jQuery complained deep in its internal functions. 2009/5/19 Matt Kruse m...@thekrusefamily.com On May 19, 5:32 am, DBJDBJ dbj...@gmail.com wrote: This is an discussion on library develeopment philosophy. There are only two sides to this coin: fast and dangerous and safe and slow. I think this is another use for a jQuery development build. One that would generate warnings of empty selector results, invalid arguments, etc. It could also detect possible conflicts like this that would cause jQuery to misbehave and alert the developer. Once development is done, you swap in the production version of jQuery and avoid the penalty his that comes with all the debug stuff. 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
On May 19, 7:51 am, David Zhou da...@nodnod.net wrote: I wonder if it's feasible to monkeypatch debugging wrappers around jQuery core methods. You don't even need it to throw errors -- a simple console.log warning would suffice. Definitely feasible. See something I posted here a while ago: http://groups.google.com/group/jquery-dev/browse_thread/thread/5360f7b3d67a2ddc The problem is that jQuery changes fairly frequently (unfortunately) and the debug plugin would need to constantly be changed to stay up-to- date since it would be so closely tied to the jQuery code. It would be better to put the debugging into the source itself, then use a builder to create a debug version and a release version. In the absence of that, though, it would be fantastic to have a group of people working on a debug plugin. 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
rather than another branch with dirty code in the middle, I would prefer a
dedicated jQuery.debug.js as external file able to wrap everything and
redefine the library itself.
in this way you can use always latest jQuery version and add, locally, a
script with jQuery.debug.js file where inside you'll find something like:
jQuery = $ = (function($){
function jQuery(){
if(this instanceof jQuery)
throw new Error(it does not make sense to use new $);
return $.apply(null, arguments);
};
jQuery.prototype = $.prototype;
return jQuery;
})($);
the same could be done for methods, in prototype or static.
This is worthy if what you need to check are arguments, scopes, other rather
than core code itself ( at least that should be jQuery problem, I mean
errors check )
On Tue, May 19, 2009 at 3:23 PM, Matt Kruse m...@thekrusefamily.com wrote:
On May 19, 7:51 am, David Zhou da...@nodnod.net wrote:
I wonder if it's feasible to monkeypatch debugging wrappers around
jQuery core methods. You don't even need it to throw errors -- a
simple console.log warning would suffice.
Definitely feasible. See something I posted here a while ago:
http://groups.google.com/group/jquery-dev/browse_thread/thread/5360f7b3d67a2ddc
The problem is that jQuery changes fairly frequently (unfortunately)
and the debug plugin would need to constantly be changed to stay up-to-
date since it would be so closely tied to the jQuery code.
It would be better to put the debugging into the source itself, then
use a builder to create a debug version and a release version.
In the absence of that, though, it would be fantastic to have a group
of people working on a debug plugin.
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
-~--~~~~--~~--~--~---
[jquery-dev] Re: new $
Right, I think this is what Matt and I are getting at. Also, I think
it shouldn't be impossible to track jQuery changes. The internals
might change, but if we're mostly error checking published API, that
should be fairly stable.
-- dz
On Tue, May 19, 2009 at 11:02 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
rather than another branch with dirty code in the middle, I would prefer a
dedicated jQuery.debug.js as external file able to wrap everything and
redefine the library itself.
in this way you can use always latest jQuery version and add, locally, a
script with jQuery.debug.js file where inside you'll find something like:
jQuery = $ = (function($){
function jQuery(){
if(this instanceof jQuery)
throw new Error(it does not make sense to use new $);
return $.apply(null, arguments);
};
jQuery.prototype = $.prototype;
return jQuery;
})($);
the same could be done for methods, in prototype or static.
This is worthy if what you need to check are arguments, scopes, other rather
than core code itself ( at least that should be jQuery problem, I mean
errors check )
On Tue, May 19, 2009 at 3:23 PM, Matt Kruse m...@thekrusefamily.com wrote:
On May 19, 7:51 am, David Zhou da...@nodnod.net wrote:
I wonder if it's feasible to monkeypatch debugging wrappers around
jQuery core methods. You don't even need it to throw errors -- a
simple console.log warning would suffice.
Definitely feasible. See something I posted here a while ago:
http://groups.google.com/group/jquery-dev/browse_thread/thread/5360f7b3d67a2ddc
The problem is that jQuery changes fairly frequently (unfortunately)
and the debug plugin would need to constantly be changed to stay up-to-
date since it would be so closely tied to the jQuery code.
It would be better to put the debugging into the source itself, then
use a builder to create a debug version and a release version.
In the absence of that, though, it would be fantastic to have a group
of people working on a debug plugin.
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
-~--~~~~--~~--~--~---
[jquery-dev] Re: new project
On May 19, 1:26 pm, jquerypla...@gmail.com jquerypla...@gmail.com wrote: i started a new project called jplanet. it's a content aggregator about jquery. see more inhttp://jplanet.tumblr.com/ What are your sources? The list I see is a little confusing and I'm not sure where it's all coming from. I also took a stab at aggregating jQuery info here: http://www.javascripttoolbox.com/gadget/jquery/ I've been using it in my iGoogle page for a few weeks and it's been great for me. I plan to clean it up a bit more and possibly add more content sources. I've also been messing with a tool to monitor Twitter for searches, such as jquery or javascript and aggregate posted url's, show relationships between users posting on the topic, find the most important users for the topic, etc. I may release that at some point in the future. It's kind of a cool way to see what's going on in the jQuery Cloud. 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new project
On May 19, 4:40 pm, Matt Kruse m...@thekrusefamily.com wrote: The list I see is a little confusing and I'm not sure where it's all coming from. I also took a stab at aggregating jQuery info here:http://www.javascripttoolbox.com/gadget/jquery/ I've been using it in my iGoogle page for a few weeks and it's been great for me. I plan to clean it up a bit more and possibly add more content sources. I've also been messing with a tool to monitor Twitter for searches, such as jquery or javascript and aggregate posted url's, show relationships between users posting on the topic, find the most important users for the topic, etc. I may release that at some point in the future. It's kind of a cool way to see what's going on in the jQuery Cloud. hi matt currently, i'm collecting my initial bookmark and some sites about jquery that supports rss. soon i'll write a list into sidebar with these sources. about twitter, i really thought in monitor twitter but there are many junk things, as . i'm studing a good way for implement this integration. thanks --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
Anyone works within the constraints of his knowledge and tools. Not protecting code from Object.prototype (yet) has been a design decision to not sacrify performance just to tolerate bad practice, afaik. From your other example, do you think car companies should limit the car's max speed to avoid complaints? I don't think so. You're repeatedly complaining about jQuery's intolerance on bad code and flexibility at the same time. The only issue at play here is the lack of understanding of the library, javascript and debugging by those you mention. I mean, you're blaming jQuery on below intermediate coder's errors, that's like blaming the car for a bad driver. Fix that and everything will be fine, or just forget trying to push the library onto unwilling developers. jQuery has few restrictions, just reading the docs is enough to adapt, have they? cheers On May 17, 8:51 pm, DBJDBJ dbj...@gmail.com wrote: @Andrea Here is a very nice and very recent example of what am I talking about, please find it in the thread : Error in attr when adding function to Object.prototype Options ... The proverbial Object.prototype ;o) Please go and explain to the developer who started this thread, why is jQuery not to blame that it does not work in presence of Object.prototype abuse. He is blaming jQuery and everyone who tried to explain why is there no logic in extending Object.prototype. He will rather have it, and not use the jQuery. I (usually) do not waste time in that kind of discussions and just place: for ( var j in Object,prototype ) delete Object.prototype[j] ; on the top of my jQuery file. Which then I impose ;o) --DBJ On May 17, 2:46 pm, Andrea Giammarchi andrea.giammar...@gmail.com wrote: jQuery is a library, not a language ... new $ where $ return a new something else is allowed by JavaScript specs ... it is not an error, syntax speaking, it is just like people using whatever.toString() rather than + whatever ... you are creating a drama over a truly simple and common mistake for unskilled JS developers but still, it does not harm anybody and if the application does not work is not because of new $. I am sure you have hundreds of valid arguments about their bad practices, but tell them that their code is crap and cannot work because new $ is allowed ( by JavaScript itself, it is NOT jQuery ) is an error as well. It is not about JavaScript panorama only, there are crap developers for evey languages and actually truly skilled developers are rare but nobody cares that much ... I see horrors in famouse PHP CMS every day but these CMS are famous I have seen crappy logic in pieces of Zend Framework but it is suppose to be enterprise I cannot blame anybody using a programming language in a bad way as long as results are somehow reached ... I agree that this would have been a better world if every paid developers was truly senior but I cannot find a single argument in this thread about jQuery, sorry. On Sun, May 17, 2009 at 2:00 PM, DBJDBJ dbj...@gmail.com wrote: Allow me to be very clear: Issue is in MOUNTAIN of legacy javascript/css/html ... Company X decides to improve its portal or whatever horrid pile of sugar they might have amassed, and then yet another team is made to do it. Which usually consist of visual basic/delphi/sql/asp developers who are all avid followers of jQuery. They simply include jQuery in these pages , and then ... nothing works. Then they struggle for approx few weeks and just then they declare that jQuery is very bad and then they either revert back to ASP or JSP or whatever horros you can think of. But. Minority admits they need to learn a bit more and then they call people in to help them out. This is where we usaly come in. And this is where we use my version of jQuery to show them where are they making mistakes and for us to understand what is going on. And then fun starts when the legacy code has to be removed/destroyed/ forgotten. In those moments I would like Ricardo and Andrea to stand in front of these (by now highly annoyed) managers and developers and tell them : .. jQuery does it work as it's supposed to, it's not it's duty to enforce good practices ... or alert users of javascript syntax errors... What is the issues here is the jQ usage patterns not jQ itself. And this is a very big mountain to climb for a very big portion of developers. Number of people who are beyond intermediate skills in javascript+css, is in reality very very small ... -- DBJ On May 16, 12:17 pm, Ricardo ricardob...@gmail.com wrote: Well, you shouldn't let your clients mess with your javascript, minify it before deploying. Anything that happens is their own problem - that is, if you're not hired to do it. jQuery does it work as it's supposed to, it's not it's duty to enforce good practices (wishful thinking) or alert users of
[jquery-dev] Re: new $
From your other example, do you think car companies should limit the car's max speed to avoid complaints? I don't think so. Some do. http://en.wikipedia.org/wiki/Governor_(device) Regards, Peter --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
Allow me to be very clear:
Issue is in MOUNTAIN of legacy javascript/css/html ... Company X
decides to improve its portal or whatever horrid pile of sugar they
might have amassed, and then yet another team is made to do it. Which
usually consist of visual basic/delphi/sql/asp developers who are
all avid followers of jQuery. They simply include jQuery in these
pages , and then ... nothing works. Then they struggle for approx few
weeks and just then they declare that jQuery is very bad and then
they either revert back to ASP or JSP or whatever horros you can think
of. But. Minority admits they need to learn a bit more and then they
call people in to help them out.
This is where we usaly come in. And this is where we use my version of
jQuery to show them where are they making mistakes and for us to
understand what is going on.
And then fun starts when the legacy code has to be removed/destroyed/
forgotten. In those moments I would like Ricardo and Andrea to stand
in front of these (by now highly annoyed) managers and developers and
tell them :
.. jQuery does it work as it's supposed to, it's not it's duty to
enforce
good practices ... or alert users of javascript syntax errors...
What is the issues here is the jQ usage patterns not jQ itself. And
this is a very big mountain to climb for a very big portion of
developers. Number of people who are beyond intermediate skills in
javascript+css, is in reality very very small ...
-- DBJ
On May 16, 12:17 pm, Ricardo ricardob...@gmail.com wrote:
Well, you shouldn't let your clients mess with your javascript, minify
it before deploying. Anything that happens is their own problem - that
is, if you're not hired to do it.
jQuery does it work as it's supposed to, it's not it's duty to enforce
good practices (wishful thinking) or alert users of javascript syntax
errors.
On May 15, 8:03 pm, DBJDBJ dbj...@gmail.com wrote:
I have only clients no boses, who blame it on jQuery until they
are caught that is ;o)
I am catching them with jQ version I have adorned with this kind of
checks like the one we are discussing here.
You will be amazed (same as me) what are javascript/css/html newcomers
capable of doing.
One more check I am going to add is this one to stop them doing new $
() ...
Thanks
--DBJ
On May 15, 10:43 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Tell your head of whatever that a title in a contract does not necessary
mean extraordinary skills and if he would like to improve his JavaScript
knowledge he is more than welcome in this ml ( probably more as reader
... )
anyway ...
function init(selector, context){
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can not new $());
return new jQuery.fn.init(selector, context);
};
function jQuery(selector, context) {
return jQuery.fast ?
new jQuery.fn.init(selector, context) :
init.call(this, selector, context)
;
};
Conditional is a bit faster than an if but still it is something that does
not make sense because as I said the nature of the jQuery callback is
dual (
both function/constructor ... it does not matter which way you call it,
the
result will always be an instance of jQuery, if you like weist time
writing an alread implicit new everywhere, it cannot be a jQuery issue,
do
you agree? )
On Fri, May 15, 2009 at 10:20 AM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
;) I still see an if statement there, heh.
I prefer the conditional comments + build system approach.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
DBJDBJ wrote:
... If a user uses new $ this user simply does not truly understand/
know
JavaScript but fortunately will not harm anybody...
No it wont, unless this user is a team leader and starts blaming
jQuery on everything.
And this happens much more than anyone here (it seems) realises.
But. This is another subject.
PS:
jQuery.fast = false ;
jQuery.error_code = 0xABCD ;
function(selector, context) {
if ( ! jQuery.fast)
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can
not new $());
return new jQuery.fn.init(selector, context);
}
On May 14, 2:59 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
to do that you need to change the contructor:
function(selector, context) {
if(this instanceof jQuery)
throw new Error(Can not new $());
return new jQuery.fn.init(selector, context);
}
this means an extra if for each jQuery call, something not that
welcome
for
performances reason. At the same time, jQuery itself relies in this
JavaScript peculiarity, so I would not create conflicts between
jQuery
[jquery-dev] Re: new $
jQuery is a library, not a language ... new $ where $ return a new something
else is allowed by JavaScript specs ... it is not an error, syntax speaking,
it is just like people using whatever.toString() rather than + whatever
... you are creating a drama over a truly simple and common mistake for
unskilled JS developers but still, it does not harm anybody and if the
application does not work is not because of new $.
I am sure you have hundreds of valid arguments about their bad practices,
but tell them that their code is crap and cannot work because new $ is
allowed ( by JavaScript itself, it is NOT jQuery ) is an error as well.
It is not about JavaScript panorama only, there are crap developers for evey
languages and actually truly skilled developers are rare but nobody cares
that much ... I see horrors in famouse PHP CMS every day but these CMS are
famous I have seen crappy logic in pieces of Zend Framework but it is
suppose to be enterprise I cannot blame anybody using a programming
language in a bad way as long as results are somehow reached ... I agree
that this would have been a better world if every paid developers was truly
senior but I cannot find a single argument in this thread about jQuery,
sorry.
On Sun, May 17, 2009 at 2:00 PM, DBJDBJ dbj...@gmail.com wrote:
Allow me to be very clear:
Issue is in MOUNTAIN of legacy javascript/css/html ... Company X
decides to improve its portal or whatever horrid pile of sugar they
might have amassed, and then yet another team is made to do it. Which
usually consist of visual basic/delphi/sql/asp developers who are
all avid followers of jQuery. They simply include jQuery in these
pages , and then ... nothing works. Then they struggle for approx few
weeks and just then they declare that jQuery is very bad and then
they either revert back to ASP or JSP or whatever horros you can think
of. But. Minority admits they need to learn a bit more and then they
call people in to help them out.
This is where we usaly come in. And this is where we use my version of
jQuery to show them where are they making mistakes and for us to
understand what is going on.
And then fun starts when the legacy code has to be removed/destroyed/
forgotten. In those moments I would like Ricardo and Andrea to stand
in front of these (by now highly annoyed) managers and developers and
tell them :
.. jQuery does it work as it's supposed to, it's not it's duty to
enforce
good practices ... or alert users of javascript syntax errors...
What is the issues here is the jQ usage patterns not jQ itself. And
this is a very big mountain to climb for a very big portion of
developers. Number of people who are beyond intermediate skills in
javascript+css, is in reality very very small ...
-- DBJ
On May 16, 12:17 pm, Ricardo ricardob...@gmail.com wrote:
Well, you shouldn't let your clients mess with your javascript, minify
it before deploying. Anything that happens is their own problem - that
is, if you're not hired to do it.
jQuery does it work as it's supposed to, it's not it's duty to enforce
good practices (wishful thinking) or alert users of javascript syntax
errors.
On May 15, 8:03 pm, DBJDBJ dbj...@gmail.com wrote:
I have only clients no boses, who blame it on jQuery until they
are caught that is ;o)
I am catching them with jQ version I have adorned with this kind of
checks like the one we are discussing here.
You will be amazed (same as me) what are javascript/css/html newcomers
capable of doing.
One more check I am going to add is this one to stop them doing new $
() ...
Thanks
--DBJ
On May 15, 10:43 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Tell your head of whatever that a title in a contract does not
necessary
mean extraordinary skills and if he would like to improve his
JavaScript
knowledge he is more than welcome in this ml ( probably more as
reader ... )
anyway ...
function init(selector, context){
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can not new $());
return new jQuery.fn.init(selector, context);
};
function jQuery(selector, context) {
return jQuery.fast ?
new jQuery.fn.init(selector, context) :
init.call(this, selector, context)
;
};
Conditional is a bit faster than an if but still it is something that
does
not make sense because as I said the nature of the jQuery callback is
dual (
both function/constructor ... it does not matter which way you call
it, the
result will always be an instance of jQuery, if you like weist time
writing an alread implicit new everywhere, it cannot be a jQuery
issue, do
you agree? )
On Fri, May 15, 2009 at 10:20 AM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
;) I still see an if statement there, heh.
I prefer the conditional comments
[jquery-dev] Re: new $
DBJDBJ - I'd be interested in hearing all of the gotchas that the engineers have run into using jQuery. It's interesting that they'd try to do new $, as there is no logical reason for it and it isn't in the examples, but for some reason they used it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
@Andrea Can you forget 'new $()' for a sec please? I am talking here about people who crash a car and than blame it on the car because it is too fast ... Get it ? They (jQ novices) blame it on the jQ because it lets them do things, they are not supposed to do. On jQ or JS. Yes they do bad javascript in essence , but then they blame it on the jQuery. Like : ... jQuery is too slow, let's use X or ... jQuery is not OO, lets use Y or .. jQuery is not secure, lets use Z and all sorts of unbelievable crap ... True, this is happening with other langauages and libraries but this is jQ forum, so I would rather not widen this thread which is anyway way of the mark as it is ... -- DBJ On May 17, 9:05 pm, Josh Powell seas...@gmail.com wrote: DBJDBJ - I'd be interested in hearing all of the gotchas that the engineers have run into using jQuery. It's interesting that they'd try to do new $, as there is no logical reason for it and it isn't in the examples, but for some reason they used it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
@Andrea
Here is a very nice and very recent example of what am I talking
about, please find it in the thread : Error in attr when adding
function to Object.prototype Options ...
The proverbial Object.prototype ;o) Please go and explain to the
developer who started this thread, why is jQuery not to blame that it
does not work in presence of Object.prototype abuse.
He is blaming jQuery and everyone who tried to explain why is there no
logic in extending Object.prototype. He will rather have it, and not
use the jQuery.
I (usually) do not waste time in that kind of discussions and just
place: for ( var j in Object,prototype ) delete Object.prototype[j] ;
on the top of my jQuery file. Which then I impose ;o)
--DBJ
On May 17, 2:46 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
jQuery is a library, not a language ... new $ where $ return a new something
else is allowed by JavaScript specs ... it is not an error, syntax speaking,
it is just like people using whatever.toString() rather than + whatever
... you are creating a drama over a truly simple and common mistake for
unskilled JS developers but still, it does not harm anybody and if the
application does not work is not because of new $.
I am sure you have hundreds of valid arguments about their bad practices,
but tell them that their code is crap and cannot work because new $ is
allowed ( by JavaScript itself, it is NOT jQuery ) is an error as well.
It is not about JavaScript panorama only, there are crap developers for evey
languages and actually truly skilled developers are rare but nobody cares
that much ... I see horrors in famouse PHP CMS every day but these CMS are
famous I have seen crappy logic in pieces of Zend Framework but it is
suppose to be enterprise I cannot blame anybody using a programming
language in a bad way as long as results are somehow reached ... I agree
that this would have been a better world if every paid developers was truly
senior but I cannot find a single argument in this thread about jQuery,
sorry.
On Sun, May 17, 2009 at 2:00 PM, DBJDBJ dbj...@gmail.com wrote:
Allow me to be very clear:
Issue is in MOUNTAIN of legacy javascript/css/html ... Company X
decides to improve its portal or whatever horrid pile of sugar they
might have amassed, and then yet another team is made to do it. Which
usually consist of visual basic/delphi/sql/asp developers who are
all avid followers of jQuery. They simply include jQuery in these
pages , and then ... nothing works. Then they struggle for approx few
weeks and just then they declare that jQuery is very bad and then
they either revert back to ASP or JSP or whatever horros you can think
of. But. Minority admits they need to learn a bit more and then they
call people in to help them out.
This is where we usaly come in. And this is where we use my version of
jQuery to show them where are they making mistakes and for us to
understand what is going on.
And then fun starts when the legacy code has to be removed/destroyed/
forgotten. In those moments I would like Ricardo and Andrea to stand
in front of these (by now highly annoyed) managers and developers and
tell them :
.. jQuery does it work as it's supposed to, it's not it's duty to
enforce
good practices ... or alert users of javascript syntax errors...
What is the issues here is the jQ usage patterns not jQ itself. And
this is a very big mountain to climb for a very big portion of
developers. Number of people who are beyond intermediate skills in
javascript+css, is in reality very very small ...
-- DBJ
On May 16, 12:17 pm, Ricardo ricardob...@gmail.com wrote:
Well, you shouldn't let your clients mess with your javascript, minify
it before deploying. Anything that happens is their own problem - that
is, if you're not hired to do it.
jQuery does it work as it's supposed to, it's not it's duty to enforce
good practices (wishful thinking) or alert users of javascript syntax
errors.
On May 15, 8:03 pm, DBJDBJ dbj...@gmail.com wrote:
I have only clients no boses, who blame it on jQuery until they
are caught that is ;o)
I am catching them with jQ version I have adorned with this kind of
checks like the one we are discussing here.
You will be amazed (same as me) what are javascript/css/html newcomers
capable of doing.
One more check I am going to add is this one to stop them doing new $
() ...
Thanks
--DBJ
On May 15, 10:43 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Tell your head of whatever that a title in a contract does not
necessary
mean extraordinary skills and if he would like to improve his
JavaScript
knowledge he is more than welcome in this ml ( probably more as
reader ... )
anyway ...
function init(selector, context){
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can
[jquery-dev] Re: new $
... If a user uses new $ this user simply does not truly understand/
know
JavaScript but fortunately will not harm anybody...
No it wont, unless this user is a team leader and starts blaming
jQuery on everything.
And this happens much more than anyone here (it seems) realises.
But. This is another subject.
PS:
jQuery.fast = false ;
jQuery.error_code = 0xABCD ;
function(selector, context) {
if ( ! jQuery.fast)
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can
not new $());
return new jQuery.fn.init(selector, context);
}
On May 14, 2:59 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
to do that you need to change the contructor:
function(selector, context) {
if(this instanceof jQuery)
throw new Error(Can not new $());
return new jQuery.fn.init(selector, context);
}
this means an extra if for each jQuery call, something not that welcome for
performances reason. At the same time, jQuery itself relies in this
JavaScript peculiarity, so I would not create conflicts between jQuery
developers and users.
If a user uses new $ this user simply does not truly understand/know
JavaScript but fortunately will not harm anybody.
On Thu, May 14, 2009 at 10:23 AM, DBJDBJ dbj...@gmail.com wrote:
Ah, new $, is possible and therefore not barred ... Left in there as a
sort of a land-mine for the newcomers ? Or as an esoteric test for GC
developers ? Highly useless it seems to me.
Back to reality and jQuery. $ is defined as:
function(selector, context) {
// The jQuery object is actually just the init constructor
'enhanced'
return new jQuery.fn.init(selector, context);
}
Maybe I am just searching for ECMA harmony, but will $() definition
that throws an exception if new-ed , be usefull :
try {
new $ ;
} catch ( x )
{
// x. message == Can not new $()
}
Au-contraire : will this hurt anyone ? Is exception throwing
porgramming idiom damaging for jQuery?
--DBJ
PS: if Python was choosen as a Netscape scripting language, World
would be a better place ... If nothing else its name is less
ridiculous ... ;o)
On May 14, 9:04 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
it's called JavaScript :D
jokes a part, every function is a constructor as well so new function is
always valid.
If the function returns an object, it does not matter which new is
because
it will be an instance of returned object one.
if it is a primitive it will simply be lost:
var a = new function(){return 123;};
// a is an instance of anonymous function
this allows us to create Python like initializations:
function PythonLike(){
return this instanceof arguments.callee ? this : new
arguments.callee;
};
alert(PythonLike() instanceof PythonLike);
alert(new PythonLike() instanceof PythonLike);
true in both cases
jQuery returns a new jQuery.prototype.init where init method shares the
same
prototype ... better now? :-)
On Wed, May 13, 2009 at 11:57 PM, DBJDBJ dbj...@gmail.com wrote:
Why is this allowed :
var jq = new $ ;
Does it matter?
-- 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
-~--~~~~--~~--~--~---
[jquery-dev] Re: new $
;) I still see an if statement there, heh.
I prefer the conditional comments + build system approach.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
DBJDBJ wrote:
... If a user uses new $ this user simply does not truly understand/
know
JavaScript but fortunately will not harm anybody...
No it wont, unless this user is a team leader and starts blaming
jQuery on everything.
And this happens much more than anyone here (it seems) realises.
But. This is another subject.
PS:
jQuery.fast = false ;
jQuery.error_code = 0xABCD ;
function(selector, context) {
if ( ! jQuery.fast)
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can
not new $());
return new jQuery.fn.init(selector, context);
}
On May 14, 2:59 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
to do that you need to change the contructor:
function(selector, context) {
if(this instanceof jQuery)
throw new Error(Can not new $());
return new jQuery.fn.init(selector, context);
}
this means an extra if for each jQuery call, something not that welcome for
performances reason. At the same time, jQuery itself relies in this
JavaScript peculiarity, so I would not create conflicts between jQuery
developers and users.
If a user uses new $ this user simply does not truly understand/know
JavaScript but fortunately will not harm anybody.
On Thu, May 14, 2009 at 10:23 AM, DBJDBJ dbj...@gmail.com wrote:
Ah, new $, is possible and therefore not barred ... Left in there as a
sort of a land-mine for the newcomers ? Or as an esoteric test for GC
developers ? Highly useless it seems to me.
Back to reality and jQuery. $ is defined as:
function(selector, context) {
// The jQuery object is actually just the init constructor
'enhanced'
return new jQuery.fn.init(selector, context);
}
Maybe I am just searching for ECMA harmony, but will $() definition
that throws an exception if new-ed , be usefull :
try {
new $ ;
} catch ( x )
{
// x. message == Can not new $()
}
Au-contraire : will this hurt anyone ? Is exception throwing
porgramming idiom damaging for jQuery?
--DBJ
PS: if Python was choosen as a Netscape scripting language, World
would be a better place ... If nothing else its name is less
ridiculous ... ;o)
On May 14, 9:04 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
it's called JavaScript :D
jokes a part, every function is a constructor as well so new function is
always valid.
If the function returns an object, it does not matter which new is
because
it will be an instance of returned object one.
if it is a primitive it will simply be lost:
var a = new function(){return 123;};
// a is an instance of anonymous function
this allows us to create Python like initializations:
function PythonLike(){
return this instanceof arguments.callee ? this : new
arguments.callee;
};
alert(PythonLike() instanceof PythonLike);
alert(new PythonLike() instanceof PythonLike);
true in both cases
jQuery returns a new jQuery.prototype.init where init method shares the
same
prototype ... better now? :-)
On Wed, May 13, 2009 at 11:57 PM, DBJDBJ dbj...@gmail.com wrote:
Why is this allowed :
var jq = new $ ;
Does it matter?
-- 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
-~--~~~~--~~--~--~---
[jquery-dev] Re: new $
Tell your head of whatever that a title in a contract does not necessary
mean extraordinary skills and if he would like to improve his JavaScript
knowledge he is more than welcome in this ml ( probably more as reader ... )
anyway ...
function init(selector, context){
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can not new $());
return new jQuery.fn.init(selector, context);
};
function jQuery(selector, context) {
return jQuery.fast ?
new jQuery.fn.init(selector, context) :
init.call(this, selector, context)
;
};
Conditional is a bit faster than an if but still it is something that does
not make sense because as I said the nature of the jQuery callback is dual (
both function/constructor ... it does not matter which way you call it, the
result will always be an instance of jQuery, if you like weist time
writing an alread implicit new everywhere, it cannot be a jQuery issue, do
you agree? )
On Fri, May 15, 2009 at 10:20 AM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
;) I still see an if statement there, heh.
I prefer the conditional comments + build system approach.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
DBJDBJ wrote:
... If a user uses new $ this user simply does not truly understand/
know
JavaScript but fortunately will not harm anybody...
No it wont, unless this user is a team leader and starts blaming
jQuery on everything.
And this happens much more than anyone here (it seems) realises.
But. This is another subject.
PS:
jQuery.fast = false ;
jQuery.error_code = 0xABCD ;
function(selector, context) {
if ( ! jQuery.fast)
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can
not new $());
return new jQuery.fn.init(selector, context);
}
On May 14, 2:59 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
to do that you need to change the contructor:
function(selector, context) {
if(this instanceof jQuery)
throw new Error(Can not new $());
return new jQuery.fn.init(selector, context);
}
this means an extra if for each jQuery call, something not that welcome
for
performances reason. At the same time, jQuery itself relies in this
JavaScript peculiarity, so I would not create conflicts between jQuery
developers and users.
If a user uses new $ this user simply does not truly understand/know
JavaScript but fortunately will not harm anybody.
On Thu, May 14, 2009 at 10:23 AM, DBJDBJ dbj...@gmail.com wrote:
Ah, new $, is possible and therefore not barred ... Left in there as a
sort of a land-mine for the newcomers ? Or as an esoteric test for GC
developers ? Highly useless it seems to me.
Back to reality and jQuery. $ is defined as:
function(selector, context) {
// The jQuery object is actually just the init constructor
'enhanced'
return new jQuery.fn.init(selector, context);
}
Maybe I am just searching for ECMA harmony, but will $() definition
that throws an exception if new-ed , be usefull :
try {
new $ ;
} catch ( x )
{
// x. message == Can not new $()
}
Au-contraire : will this hurt anyone ? Is exception throwing
porgramming idiom damaging for jQuery?
--DBJ
PS: if Python was choosen as a Netscape scripting language, World
would be a better place ... If nothing else its name is less
ridiculous ... ;o)
On May 14, 9:04 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
it's called JavaScript :D
jokes a part, every function is a constructor as well so new function
is
always valid.
If the function returns an object, it does not matter which new is
because
it will be an instance of returned object one.
if it is a primitive it will simply be lost:
var a = new function(){return 123;};
// a is an instance of anonymous function
this allows us to create Python like initializations:
function PythonLike(){
return this instanceof arguments.callee ? this : new
arguments.callee;
};
alert(PythonLike() instanceof PythonLike);
alert(new PythonLike() instanceof PythonLike);
true in both cases
jQuery returns a new jQuery.prototype.init where init method shares
the
same
prototype ... better now? :-)
On Wed, May 13, 2009 at 11:57 PM, DBJDBJ dbj...@gmail.com wrote:
Why is this allowed :
var jq = new $ ;
Does it matter?
-- 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
[jquery-dev] Re: new $
I have only clients no boses, who blame it on jQuery until they
are caught that is ;o)
I am catching them with jQ version I have adorned with this kind of
checks like the one we are discussing here.
You will be amazed (same as me) what are javascript/css/html newcomers
capable of doing.
One more check I am going to add is this one to stop them doing new $
() ...
Thanks
--DBJ
On May 15, 10:43 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Tell your head of whatever that a title in a contract does not necessary
mean extraordinary skills and if he would like to improve his JavaScript
knowledge he is more than welcome in this ml ( probably more as reader ... )
anyway ...
function init(selector, context){
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can not new $());
return new jQuery.fn.init(selector, context);
};
function jQuery(selector, context) {
return jQuery.fast ?
new jQuery.fn.init(selector, context) :
init.call(this, selector, context)
;
};
Conditional is a bit faster than an if but still it is something that does
not make sense because as I said the nature of the jQuery callback is dual (
both function/constructor ... it does not matter which way you call it, the
result will always be an instance of jQuery, if you like weist time
writing an alread implicit new everywhere, it cannot be a jQuery issue, do
you agree? )
On Fri, May 15, 2009 at 10:20 AM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
;) I still see an if statement there, heh.
I prefer the conditional comments + build system approach.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
DBJDBJ wrote:
... If a user uses new $ this user simply does not truly understand/
know
JavaScript but fortunately will not harm anybody...
No it wont, unless this user is a team leader and starts blaming
jQuery on everything.
And this happens much more than anyone here (it seems) realises.
But. This is another subject.
PS:
jQuery.fast = false ;
jQuery.error_code = 0xABCD ;
function(selector, context) {
if ( ! jQuery.fast)
if(this instanceof jQuery)
throw new Error( jQuery.error_code, Can
not new $());
return new jQuery.fn.init(selector, context);
}
On May 14, 2:59 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
to do that you need to change the contructor:
function(selector, context) {
if(this instanceof jQuery)
throw new Error(Can not new $());
return new jQuery.fn.init(selector, context);
}
this means an extra if for each jQuery call, something not that welcome
for
performances reason. At the same time, jQuery itself relies in this
JavaScript peculiarity, so I would not create conflicts between jQuery
developers and users.
If a user uses new $ this user simply does not truly understand/know
JavaScript but fortunately will not harm anybody.
On Thu, May 14, 2009 at 10:23 AM, DBJDBJ dbj...@gmail.com wrote:
Ah, new $, is possible and therefore not barred ... Left in there as a
sort of a land-mine for the newcomers ? Or as an esoteric test for GC
developers ? Highly useless it seems to me.
Back to reality and jQuery. $ is defined as:
function(selector, context) {
// The jQuery object is actually just the init constructor
'enhanced'
return new jQuery.fn.init(selector, context);
}
Maybe I am just searching for ECMA harmony, but will $() definition
that throws an exception if new-ed , be usefull :
try {
new $ ;
} catch ( x )
{
// x. message == Can not new $()
}
Au-contraire : will this hurt anyone ? Is exception throwing
porgramming idiom damaging for jQuery?
--DBJ
PS: if Python was choosen as a Netscape scripting language, World
would be a better place ... If nothing else its name is less
ridiculous ... ;o)
On May 14, 9:04 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
it's called JavaScript :D
jokes a part, every function is a constructor as well so new function
is
always valid.
If the function returns an object, it does not matter which new is
because
it will be an instance of returned object one.
if it is a primitive it will simply be lost:
var a = new function(){return 123;};
// a is an instance of anonymous function
this allows us to create Python like initializations:
function PythonLike(){
return this instanceof arguments.callee ? this : new
arguments.callee;
};
alert(PythonLike() instanceof PythonLike);
alert(new PythonLike() instanceof PythonLike);
true in both cases
jQuery returns a new jQuery.prototype.init where init method shares
the
same
prototype ... better now? :-)
On Wed, May 13, 2009 at 11:57
[jquery-dev] Re: new $
For junior js developers it is normal, I would be surprised otherwise, the problem sometimes are company looking for skills but asking (paying) for a junior role junior==to learn this stuf, even useless, pro stuff ... that's it, and I still do not get the problem at all, sorry. On May 16, 2009 12:03 AM, DBJDBJ dbj...@gmail.com wrote: I have only clients no boses, who blame it on jQuery until they are caught that is ;o) I am catching them with jQ version I have adorned with this kind of checks like the one we are discussing here. You will be amazed (same as me) what are javascript/css/html newcomers capable of doing. One more check I am going to add is this one to stop them doing new $ () ... Thanks --DBJ On May 15, 10:43 am, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Tell your head of whatever that a title in a contract does not necessary mean extraordinary sk... nadir.seen.f...@gmail.comwrote: ;) I still see an if statement there, heh.I prefer the conditional comments + build... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new $
it's called JavaScript :D
jokes a part, every function is a constructor as well so new function is
always valid.
If the function returns an object, it does not matter which new is because
it will be an instance of returned object one.
if it is a primitive it will simply be lost:
var a = new function(){return 123;};
// a is an instance of anonymous function
this allows us to create Python like initializations:
function PythonLike(){
return this instanceof arguments.callee ? this : new arguments.callee;
};
alert(PythonLike() instanceof PythonLike);
alert(new PythonLike() instanceof PythonLike);
true in both cases
jQuery returns a new jQuery.prototype.init where init method shares the same
prototype ... better now? :-)
On Wed, May 13, 2009 at 11:57 PM, DBJDBJ dbj...@gmail.com wrote:
Why is this allowed :
var jq = new $ ;
Does it matter?
-- 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
-~--~~~~--~~--~--~---
[jquery-dev] Re: new $
Ah, new $, is possible and therefore not barred ... Left in there as a
sort of a land-mine for the newcomers ? Or as an esoteric test for GC
developers ? Highly useless it seems to me.
Back to reality and jQuery. $ is defined as:
function(selector, context) {
// The jQuery object is actually just the init constructor
'enhanced'
return new jQuery.fn.init(selector, context);
}
Maybe I am just searching for ECMA harmony, but will $() definition
that throws an exception if new-ed , be usefull :
try {
new $ ;
} catch ( x )
{
// x. message == Can not new $()
}
Au-contraire : will this hurt anyone ? Is exception throwing
porgramming idiom damaging for jQuery?
--DBJ
PS: if Python was choosen as a Netscape scripting language, World
would be a better place ... If nothing else its name is less
ridiculous ... ;o)
On May 14, 9:04 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
it's called JavaScript :D
jokes a part, every function is a constructor as well so new function is
always valid.
If the function returns an object, it does not matter which new is because
it will be an instance of returned object one.
if it is a primitive it will simply be lost:
var a = new function(){return 123;};
// a is an instance of anonymous function
this allows us to create Python like initializations:
function PythonLike(){
return this instanceof arguments.callee ? this : new arguments.callee;
};
alert(PythonLike() instanceof PythonLike);
alert(new PythonLike() instanceof PythonLike);
true in both cases
jQuery returns a new jQuery.prototype.init where init method shares the same
prototype ... better now? :-)
On Wed, May 13, 2009 at 11:57 PM, DBJDBJ dbj...@gmail.com wrote:
Why is this allowed :
var jq = new $ ;
Does it matter?
-- 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
-~--~~~~--~~--~--~---
[jquery-dev] Re: new $
to do that you need to change the contructor:
function(selector, context) {
if(this instanceof jQuery)
throw new Error(Can not new $());
return new jQuery.fn.init(selector, context);
}
this means an extra if for each jQuery call, something not that welcome for
performances reason. At the same time, jQuery itself relies in this
JavaScript peculiarity, so I would not create conflicts between jQuery
developers and users.
If a user uses new $ this user simply does not truly understand/know
JavaScript but fortunately will not harm anybody.
On Thu, May 14, 2009 at 10:23 AM, DBJDBJ dbj...@gmail.com wrote:
Ah, new $, is possible and therefore not barred ... Left in there as a
sort of a land-mine for the newcomers ? Or as an esoteric test for GC
developers ? Highly useless it seems to me.
Back to reality and jQuery. $ is defined as:
function(selector, context) {
// The jQuery object is actually just the init constructor
'enhanced'
return new jQuery.fn.init(selector, context);
}
Maybe I am just searching for ECMA harmony, but will $() definition
that throws an exception if new-ed , be usefull :
try {
new $ ;
} catch ( x )
{
// x. message == Can not new $()
}
Au-contraire : will this hurt anyone ? Is exception throwing
porgramming idiom damaging for jQuery?
--DBJ
PS: if Python was choosen as a Netscape scripting language, World
would be a better place ... If nothing else its name is less
ridiculous ... ;o)
On May 14, 9:04 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
it's called JavaScript :D
jokes a part, every function is a constructor as well so new function is
always valid.
If the function returns an object, it does not matter which new is
because
it will be an instance of returned object one.
if it is a primitive it will simply be lost:
var a = new function(){return 123;};
// a is an instance of anonymous function
this allows us to create Python like initializations:
function PythonLike(){
return this instanceof arguments.callee ? this : new
arguments.callee;
};
alert(PythonLike() instanceof PythonLike);
alert(new PythonLike() instanceof PythonLike);
true in both cases
jQuery returns a new jQuery.prototype.init where init method shares the
same
prototype ... better now? :-)
On Wed, May 13, 2009 at 11:57 PM, DBJDBJ dbj...@gmail.com wrote:
Why is this allowed :
var jq = new $ ;
Does it matter?
-- 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
-~--~~~~--~~--~--~---
[jquery-dev] Re: NEW! jQuery Multiple File Upload Plugin v1.40
Hey Diego,
Thanks for the heads up. I'm definitely going to test this out!
If you can though, please keep these types of announcements focused on
the main jQuery mailing list. The Dev list is geared towards topics
involving the internals of the jQuery core lib and not general topics.
Rey...
Diego A. wrote:
NEW! jQuery Multiple File Upload Plugin v1.40
http://www.fyneworks.com/jquery/multiple-file-upload/
New features:
1. API method to reset control (remove all file selections) like
this:
$('input:file').MultiFile('reset')
Improvements:
1. Now entirely based in the $.fn.MultiFile namespace
2. Now uses $.fn.data to store control settings
3. The plugin will automatically disable the dummy additional input
element when the form is submitted conventionally or by using the
form
plugin - this removes the extra empty file from the end of the array.
IMPORTANT:
Be notified of future updates via this Twitter account:
http://twitter.com/fyneworks
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[jquery-dev] Re: NEW! jQuery Multiple File Upload Plugin v1.40
Hi Rey,
Sure no problem. Actually, I don't want to clutter any of the jQuery lists
with announcements anymore so I've created a twitter account where I'll post
updates regarding my plugins.
I've also made this pretty obvious for new plugin users so they start
following the twitter account as soon as they first download the plugin.
I'll probably announce the next major update on the main jQuery mailing list
for one last time, then I'll just leave it down to twitter...
Cheers,
Diego A.
2009/4/2 Rey Bango r...@iambright.com
Hey Diego,
Thanks for the heads up. I'm definitely going to test this out!
If you can though, please keep these types of announcements focused on
the main jQuery mailing list. The Dev list is geared towards topics
involving the internals of the jQuery core lib and not general topics.
Rey...
Diego A. wrote:
NEW! jQuery Multiple File Upload Plugin v1.40
http://www.fyneworks.com/jquery/multiple-file-upload/
New features:
1. API method to reset control (remove all file selections) like
this:
$('input:file').MultiFile('reset')
Improvements:
1. Now entirely based in the $.fn.MultiFile namespace
2. Now uses $.fn.data to store control settings
3. The plugin will automatically disable the dummy additional input
element when the form is submitted conventionally or by using the
form
plugin - this removes the extra empty file from the end of the array.
IMPORTANT:
Be notified of future updates via this Twitter account:
http://twitter.com/fyneworks
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[jquery-dev] Re: New to the jQuery Development Game
The best technique to get started is to go in the bug tracker, find an open ticket and to produce a working (or failing, as the case may be) test case if it doesn't have one already. If it passes or fails, bring it to our attention (here on the mailing list) and we can start to look in to it more. This is definitely the best way to get started. --John On Tue, Feb 24, 2009 at 8:44 PM, d3r1v3d (Gavin Mulligan) vtga...@gmail.com wrote: Hey there everyone, I've been interested in joining an open source project for a little while now and, given that I work with jQuery on a daily basis at my job, I was thinking of helping out with development - whether it be tracking down bugs, routine maintenance, or whatever needs doing. I'm just curious how you guys do things around these parts. In short, does anyone have any suggestions about how I can 'get my foot in the door' and start helping out? Is there a special way to go about getting assigned tickets from the bug tracker or is it programmer a la carte (to use a delicious analogy)? I apologize for the spam, I tried searching to see if this kind of stuff has been thrown around in this group before, but came up empty- handed. Thanks. - Gavin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: New to the jQuery Development Game
To help with test cases, here are a couple tools to help with the boilerplate: http://jquery.nodnod.net/ http://jsbin.com/ -- dz On Tue, Feb 24, 2009 at 10:32 PM, John Resig jere...@gmail.com wrote: The best technique to get started is to go in the bug tracker, find an open ticket and to produce a working (or failing, as the case may be) test case if it doesn't have one already. If it passes or fails, bring it to our attention (here on the mailing list) and we can start to look in to it more. This is definitely the best way to get started. --John On Tue, Feb 24, 2009 at 8:44 PM, d3r1v3d (Gavin Mulligan) vtga...@gmail.com wrote: Hey there everyone, I've been interested in joining an open source project for a little while now and, given that I work with jQuery on a daily basis at my job, I was thinking of helping out with development - whether it be tracking down bugs, routine maintenance, or whatever needs doing. I'm just curious how you guys do things around these parts. In short, does anyone have any suggestions about how I can 'get my foot in the door' and start helping out? Is there a special way to go about getting assigned tickets from the bug tracker or is it programmer a la carte (to use a delicious analogy)? I apologize for the spam, I tried searching to see if this kind of stuff has been thrown around in this group before, but came up empty- handed. Thanks. - Gavin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: New to the jQuery Development Game
Thanks a ton. PS - Sorry for the duplicate post. I'm still a newb when it comes to newsgroups as well, it seems. - Gavin On Feb 24, 10:35 pm, David Zhou da...@nodnod.net wrote: To help with test cases, here are a couple tools to help with the boilerplate: http://jquery.nodnod.net/http://jsbin.com/ -- dz On Tue, Feb 24, 2009 at 10:32 PM, John Resig jere...@gmail.com wrote: The best technique to get started is to go in the bug tracker, find an open ticket and to produce a working (or failing, as the case may be) test case if it doesn't have one already. If it passes or fails, bring it to our attention (here on the mailing list) and we can start to look in to it more. This is definitely the best way to get started. --John On Tue, Feb 24, 2009 at 8:44 PM, d3r1v3d (Gavin Mulligan) vtga...@gmail.com wrote: Hey there everyone, I've been interested in joining an open source project for a little while now and, given that I work with jQuery on a daily basis at my job, I was thinking of helping out with development - whether it be tracking down bugs, routine maintenance, or whatever needs doing. I'm just curious how you guys do things around these parts. In short, does anyone have any suggestions about how I can 'get my foot in the door' and start helping out? Is there a special way to go about getting assigned tickets from the bug tracker or is it programmer a la carte (to use a delicious analogy)? I apologize for the spam, I tried searching to see if this kind of stuff has been thrown around in this group before, but came up empty- handed. Thanks. - Gavin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new whitehouse.gov uses jQuery
Actually, they're also using jQuery UI. They wouldn't be able to update to v1.3 until the next version of jQuery UI (1.6) comes out, as the latest stable release of UI (1.5.3) is not compatible with jQuery 1.3. See http://blog.jquery.com/2009/01/16/jquery-ui-16rc5-compatible-with-jquery-13/ for more info. - Richard On Wed, Jan 21, 2009 at 12:13 AM, Leeoniya leeon...@gmail.com wrote: they're still at v1.2.6 though...tsk tsk tsk. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: new whitehouse.gov uses jQuery
true, i didn't think of that. good call. On Jan 21, 5:03 am, Richard D. Worth rdwo...@gmail.com wrote: Actually, they're also using jQuery UI. They wouldn't be able to update to v1.3 until the next version of jQuery UI (1.6) comes out, as the latest stable release of UI (1.5.3) is not compatible with jQuery 1.3. See http://blog.jquery.com/2009/01/16/jquery-ui-16rc5-compatible-with-jqu... for more info. - Richard On Wed, Jan 21, 2009 at 12:13 AM, Leeoniya leeon...@gmail.com wrote: they're still at v1.2.6 though...tsk tsk tsk. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[jquery-dev] Re: New Selector Engine Patch
IE7 == Tests completed in 1328 milliseconds. 4 tests of 153 failed. Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727) 1. selector module: element (1, 8, 9) 2. Select all elements, no comment nodes 5. selector module: class (3, 13, 16) 12. Escaped Class (.test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] 14. Descendant scaped Class (div .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] 16. Child escaped Class (form .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] weepy --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New Selector Engine Patch
Congratulations on nearing completion of this fantastic selector engine, John! Very exciting stuff. --Karl On Nov 1, 2008, at 11:37 AM, John Resig wrote: Hey Everyone - I've been working on a new selector engine for jQuery on-and-off again these past couple months and I finally have something ready to land: http://dev.jquery.com/ticket/3563 I've been working on the code for this project over here: http://github.com/jeresig/sizzle/tree/master (The end goal is to have this become the new default selector engine in a number of libraries - Prototype, MochiKit, Dojo, and TinyMCE have all expressed interest in using it, as well.) It passes the test suite in Firefox 3, Safari 3.1, and IE 6. There is one minor bug in Firefox 3.1 and another minor one in Opera 9.6 - both of which are specific browser bugs (and I'm filing appropriately) and neither of which are show stoppers. It's a considerable boost in performance over what we have now, in jQuery. I'll go into specific details later (once we're sure that there's no major bugs). Let me know if you have any questions and I'll be happy to answer them (although I'll be going out of town tomorrow for a week). --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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New Selector Engine Patch
Are you sure that's Firefox 3 and not Firefox 3.1? Because I can get that selector to fail in 3.1 but not in 3.0 (that's the error that I was referring to in my email). Right now Mozilla appears to have mis-implemented the CSS :enabled selector (or, at least, implemented it differently from other browsers). Unfortunately there doesn't appear to be any consensus on what actually should be matched by the selector amongst browser vendors. Because of this we're going to see similar bugs pop up because of querySelectorAll. Test suite: http://ejohn.org/apps/sizzle/test/ --John On Sat, Nov 1, 2008 at 1:34 PM, Dan Switzer [EMAIL PROTECTED] wrote: John, In FF 3.0.3, I had the following fail for me: selector module: pseudo (:) selectors (1, 33, 34) Enabled UI Element (#form input:enabled) expected: [ input#text1, input#radio1, input#radio2, input#check1, input#check2, input#hidden2, input#name ] result: [ input#text1, input#radio1, input#radio2, input#check1, input#check2, input#hidden1, input#hidden2, input#name ] -Dan On Sat, Nov 1, 2008 at 1:26 PM, Karl Swedberg [EMAIL PROTECTED] wrote: Congratulations on nearing completion of this fantastic selector engine, John! Very exciting stuff. --Karl On Nov 1, 2008, at 11:37 AM, John Resig wrote: Hey Everyone - I've been working on a new selector engine for jQuery on-and-off again these past couple months and I finally have something ready to land: http://dev.jquery.com/ticket/3563 I've been working on the code for this project over here: http://github.com/jeresig/sizzle/tree/master (The end goal is to have this become the new default selector engine in a number of libraries - Prototype, MochiKit, Dojo, and TinyMCE have all expressed interest in using it, as well.) It passes the test suite in Firefox 3, Safari 3.1, and IE 6. There is one minor bug in Firefox 3.1 and another minor one in Opera 9.6 - both of which are specific browser bugs (and I'm filing appropriately) and neither of which are show stoppers. It's a considerable boost in performance over what we have now, in jQuery. I'll go into specific details later (once we're sure that there's no major bugs). Let me know if you have any questions and I'll be happy to answer them (although I'll be going out of town tomorrow for a week). --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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New Selector Engine Patch
John, On Sat, Nov 1, 2008 at 3:02 PM, John Resig [EMAIL PROTECTED] wrote: Are you sure that's Firefox 3 and not Firefox 3.1? Because I can get that selector to fail in 3.1 but not in 3.0 (that's the error that I was referring to in my email). Right now Mozilla appears to have mis-implemented the CSS :enabled selector (or, at least, implemented it differently from other browsers). Unfortunately there doesn't appear to be any consensus on what actually should be matched by the selector amongst browser vendors. Because of this we're going to see similar bugs pop up because of querySelectorAll. Test suite: http://ejohn.org/apps/sizzle/test/ It passes the test in the above link. It failed when I downloaded the GIT package and ran it locally. Perhaps the GIT repository is out-of-date. -Dan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New Selector Engine Patch
You are probably aware that FF2 fails a few but thought I'd just post it back in case others are curious: *5. selector module: class (3, 13, 16)* ... 12. Escaped Class (.test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... 14. Descendant scaped Class (div .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... 16. Child escaped Class (form .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... Anyway, good work on sizzle, and it's nice to see a broad base of the community being open to standardizing on it. Thatcher On Sat, Nov 1, 2008 at 6:33 PM, Dan Switzer [EMAIL PROTECTED] wrote: John, On Sat, Nov 1, 2008 at 3:02 PM, John Resig [EMAIL PROTECTED] wrote: Are you sure that's Firefox 3 and not Firefox 3.1? Because I can get that selector to fail in 3.1 but not in 3.0 (that's the error that I was referring to in my email). Right now Mozilla appears to have mis-implemented the CSS :enabled selector (or, at least, implemented it differently from other browsers). Unfortunately there doesn't appear to be any consensus on what actually should be matched by the selector amongst browser vendors. Because of this we're going to see similar bugs pop up because of querySelectorAll. Test suite: http://ejohn.org/apps/sizzle/test/ It passes the test in the above link. It failed when I downloaded the GIT package and ran it locally. Perhaps the GIT repository is out-of-date. -Dan -- Christopher Thatcher --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New Selector Engine Patch
One thing Id like to ask about Sizzle is if it solves some of the simpler namespace/xml issues that seemed none intuitive in jquery's selector engine? In general my issue has to do with being able to more easily take advantage of extension points in the xhtml specification to use valid namespaced attributes to build jquery extensions, for example markup-aware templating like mjt (but built on jquery to reduce size, improve power etc). Thanks Thatcher On Sat, Nov 1, 2008 at 8:37 PM, chris thatcher [EMAIL PROTECTED] wrote: You are probably aware that FF2 fails a few but thought I'd just post it back in case others are curious: *5. selector module: class (3, 13, 16)* ... 12. Escaped Class (.test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... 14. Descendant scaped Class (div .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... 16. Child escaped Class (form .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... Anyway, good work on sizzle, and it's nice to see a broad base of the community being open to standardizing on it. Thatcher On Sat, Nov 1, 2008 at 6:33 PM, Dan Switzer [EMAIL PROTECTED]wrote: John, On Sat, Nov 1, 2008 at 3:02 PM, John Resig [EMAIL PROTECTED] wrote: Are you sure that's Firefox 3 and not Firefox 3.1? Because I can get that selector to fail in 3.1 but not in 3.0 (that's the error that I was referring to in my email). Right now Mozilla appears to have mis-implemented the CSS :enabled selector (or, at least, implemented it differently from other browsers). Unfortunately there doesn't appear to be any consensus on what actually should be matched by the selector amongst browser vendors. Because of this we're going to see similar bugs pop up because of querySelectorAll. Test suite: http://ejohn.org/apps/sizzle/test/ It passes the test in the above link. It failed when I downloaded the GIT package and ran it locally. Perhaps the GIT repository is out-of-date. -Dan -- Christopher Thatcher -- Christopher Thatcher --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New Selector Engine Patch
Unfortunately, at this point, that's not really happening. The querySelectorAll method (of the Selectors API specification) does not include support for namespaces - thus it's very likely that JavaScript libraries won't support it going forward. One thing that I'd like to fix (and I haven't checked, yet, to see how it works in Sizzle) is to make div match both div/ and foo:div/ elements. At the very least that would allow XML documents to become sort-of usable. --John On Sat, Nov 1, 2008 at 9:41 PM, chris thatcher [EMAIL PROTECTED] wrote: One thing Id like to ask about Sizzle is if it solves some of the simpler namespace/xml issues that seemed none intuitive in jquery's selector engine? In general my issue has to do with being able to more easily take advantage of extension points in the xhtml specification to use valid namespaced attributes to build jquery extensions, for example markup-aware templating like mjt (but built on jquery to reduce size, improve power etc). Thanks Thatcher On Sat, Nov 1, 2008 at 8:37 PM, chris thatcher [EMAIL PROTECTED] wrote: You are probably aware that FF2 fails a few but thought I'd just post it back in case others are curious: 5. selector module: class (3, 13, 16) ... 12. Escaped Class (.test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... 14. Descendant scaped Class (div .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... 16. Child escaped Class (form .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... Anyway, good work on sizzle, and it's nice to see a broad base of the community being open to standardizing on it. Thatcher On Sat, Nov 1, 2008 at 6:33 PM, Dan Switzer [EMAIL PROTECTED] wrote: John, On Sat, Nov 1, 2008 at 3:02 PM, John Resig [EMAIL PROTECTED] wrote: Are you sure that's Firefox 3 and not Firefox 3.1? Because I can get that selector to fail in 3.1 but not in 3.0 (that's the error that I was referring to in my email). Right now Mozilla appears to have mis-implemented the CSS :enabled selector (or, at least, implemented it differently from other browsers). Unfortunately there doesn't appear to be any consensus on what actually should be matched by the selector amongst browser vendors. Because of this we're going to see similar bugs pop up because of querySelectorAll. Test suite: http://ejohn.org/apps/sizzle/test/ It passes the test in the above link. It failed when I downloaded the GIT package and ran it locally. Perhaps the GIT repository is out-of-date. -Dan -- Christopher Thatcher -- Christopher Thatcher --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New Selector Engine Patch
I know it's a pain in the arse so I won't whine. I'll try to look at the code and see if I can help in that area, I feel intuitively like it's a feature that just requires some elbow grease up front before the code is too mature to break backwards compatibility. Without contributing a solution I'm happy with the engine's proposed goal, which it apparently follows though with. On Sat, Nov 1, 2008 at 9:44 PM, John Resig [EMAIL PROTECTED] wrote: Unfortunately, at this point, that's not really happening. The querySelectorAll method (of the Selectors API specification) does not include support for namespaces - thus it's very likely that JavaScript libraries won't support it going forward. One thing that I'd like to fix (and I haven't checked, yet, to see how it works in Sizzle) is to make div match both div/ and foo:div/ elements. At the very least that would allow XML documents to become sort-of usable. --John On Sat, Nov 1, 2008 at 9:41 PM, chris thatcher [EMAIL PROTECTED] wrote: One thing Id like to ask about Sizzle is if it solves some of the simpler namespace/xml issues that seemed none intuitive in jquery's selector engine? In general my issue has to do with being able to more easily take advantage of extension points in the xhtml specification to use valid namespaced attributes to build jquery extensions, for example markup-aware templating like mjt (but built on jquery to reduce size, improve power etc). Thanks Thatcher On Sat, Nov 1, 2008 at 8:37 PM, chris thatcher [EMAIL PROTECTED] wrote: You are probably aware that FF2 fails a few but thought I'd just post it back in case others are curious: 5. selector module: class (3, 13, 16) ... 12. Escaped Class (.test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... 14. Descendant scaped Class (div .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... 16. Child escaped Class (form .test\.foo\[5\]bar) expected: [ span#test.foo[5]bar ] result: [ ] ... Anyway, good work on sizzle, and it's nice to see a broad base of the community being open to standardizing on it. Thatcher On Sat, Nov 1, 2008 at 6:33 PM, Dan Switzer [EMAIL PROTECTED] wrote: John, On Sat, Nov 1, 2008 at 3:02 PM, John Resig [EMAIL PROTECTED] wrote: Are you sure that's Firefox 3 and not Firefox 3.1? Because I can get that selector to fail in 3.1 but not in 3.0 (that's the error that I was referring to in my email). Right now Mozilla appears to have mis-implemented the CSS :enabled selector (or, at least, implemented it differently from other browsers). Unfortunately there doesn't appear to be any consensus on what actually should be matched by the selector amongst browser vendors. Because of this we're going to see similar bugs pop up because of querySelectorAll. Test suite: http://ejohn.org/apps/sizzle/test/ It passes the test in the above link. It failed when I downloaded the GIT package and ran it locally. Perhaps the GIT repository is out-of-date. -Dan -- Christopher Thatcher -- Christopher Thatcher -- Christopher Thatcher --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New History Manager - Finished(-ish)!
You're right on the money, you need the hidden form fields in the native document via a tag or document.write, not by dynamically inserting them. Been there, done that, wore out the T-shirt. -Mike From: Nathan Hammond - To the idea of appending, if the elements are appended to the body (document.body.appendChild(mytextarea);) after it has finished loading the fields are not always repopulated (browser dependent). There are two approaches to this task found in most history managers: document.write(), or inclusion of the HTML in the page layout. I went with the former specifically because I could control it to prevent it from being executed twice (important where we'll want to allow entry from any page on the site) and because it seems to be the more tried and true method. I'm with you, I'd love to use DOM-only methods, but I don't think that is possible. (Please feel free to prove me wrong.) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: New History Manager - Finished(-ish)!
Nathan:
Thanks for having a look.
- To the name, I don't want to define it based on what else exists,
more on innate value. *shrug* Branding, again.
- To the idea of appending, if the elements are appended to the body
(document.body.appendChild(mytextarea);) after it has finished loading
the fields are not always repopulated (browser dependent). There are
two approaches to this task found in most history managers:
document.write(), or inclusion of the HTML in the page layout. I went
with the former specifically because I could control it to prevent it
from being executed twice (important where we'll want to allow entry
from any page on the site) and because it seems to be the more tried
and true method. I'm with you, I'd love to use DOM-only methods, but I
don't think that is possible. (Please feel free to prove me wrong.)
Again, thanks.
Nathan Hammond
On Sep 2, 7:44 pm, Nathan Bubna [EMAIL PROTECTED] wrote:
A.S.H. (Another Simple History)
So, why do you require the call to jssm.inline() to be done inline?
why not just append that html to the end of the body tag contents
instead of relying on document.write?
On Tue, Sep 2, 2008 at 4:26 PM, Nathan Hammond
[EMAIL PROTECTED] wrote:
Okay, before it was just a teaser. Now you can have every bit of it.
Example:http://www.nathanhammond.com/jssm/test/
Source:http://www.nathanhammond.com/jssm/jquery.jssm.zip
The archive includes the absurdly well-documented JavaScript source
file, a plugin for jQuery to make it easy, the example site, and
assorted other goodies. Now that I'm done with it, I won't lie: this
is based on RSH, but intended to replace it--if for no other reason
than it being actively maintained. A later version will remove all
external library dependencies and provide a fully-functioning
JavaScript-library-independent history manager.
What I'm hoping for from this community:
- Somebody to come up with a real name for the project because I'm not
very clever at naming things.
- Somebody so inclined to give it the harshest code review in terms of
optimization, organization, and poor design you can come up with.
- A few good people to take it on a test drive in your favorite (or
not so favorite) browser. (And to let me know if it is broken
anywhere.)
Once I've got a real name for this thing, I'll find it a home on
Google Code, so that is probably the number one priority!
Enjoy! And please have a look!
Nathan Hammond
PS: If you're interested, I have a site that has a much better example
of this in action that I can send out privately.
On Aug 27, 12:27 am, Nathan Hammond [EMAIL PROTECTED] wrote:
I'm going to ask you to use your imagination:
Imagine an AJAX history manager that required absolutely no expertise
to use. Imagine something that could be applied to forms and anchors
to have them automatically be handled by AJAX and still maintain the
browser history (back button, and bookmarking). Imagine something that
works across all browsers supported by jQuery. Imagine something that
still works when JavaScript is disabled or can itself be disabled with
a single line of code. Imagine something that can be added to nearly
any existing static website as a non-intrusive upgrade. Imagine
something that is so stable you can use it on enterprise-level sites.
Imagine something with smart settings that can be easily customized so
you never have to get into the nitty-gritty. Imagine something that
provides callbacks at six separate stages during the AJAX loading
process to accommodate for animating transitions. Imagine something
that provides a page load callback for animating the initial page
load...
And then I'm going to tell you that you don't have to use your
imagination at all. The reason I've disappeared when I said I was
going to be around so much was to focus my efforts on this. To prove
how easy it is, here are two examples that show how easy it is:
$('a').('click');
$('form#someform').('submit');
I'll have an alpha version very soon--possibly tomorrow. I'd love some
help testing it and working out kinks. And if I missed any part of
your wishlist for the perfect history manager in the description, tell
me what else it should do.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
