From: Garrett Smith on 17 Dec 2009 17:25 John G Harris wrote: > On Wed, 16 Dec 2009 at 17:25:33, in comp.lang.javascript, Garrett Smith > wrote: > > <snip> >> - 0 SLOC and no bugs whatsoever. > > How can you be sure your test code had no bugs in it ? Good point. Code maintenance involves maintenance of tests. The more code, and especially the more /complicated/ code is going to have more variables that require testing. SRP, or "do one thing only" is applicable to methods and also to tests. I look back on the unit tests I wrote 18 months ago and they are way too complex. I try and keep the unit tests to one assertion. If there are two assertions, I break it up and make another test. The result is the testing becomes clearer. Instead of "test this particular usage pattern", the test is more pure to what unit testing actually is - testing the smallest, testable parts of the code. On the matter of testing, I'd really like something better than YUI test. There are several problems I've grown too frustrated with. There are many improvements that coudl be made, if the author would dedicate the time to it. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 17 Dec 2009 17:58 On Dec 17, 5:25 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > John G Harris wrote: > > On Wed, 16 Dec 2009 at 17:25:33, in comp.lang.javascript, Garrett Smith > > wrote: > > > <snip> > >> - 0 SLOC and no bugs whatsoever. > > > How can you be sure your test code had no bugs in it ? > > Good point. Code maintenance involves maintenance of tests. The more > code, and especially the more /complicated/ code is going to have more > variables that require testing. SRP, or "do one thing only" is > applicable to methods and also to tests. > Yes, and the point that I've made repeatedly regarding get/ setAttribute is that _most_ apps don't need them at all in an HTML DOM. A very recent example where one could have helped:- http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/9c479ab572e72557# For whatever reason, the OP wants to set the value attribute of an input. Of course, I wouldn't recommend a GP wrapper for this one case. I don't recommend GP solutions at all. But seeing as GP solutions are all the rage and you can't expect neophytes to figure these things out, an interface like this would have helped:- attr(el, 'value', 'myvalue'); (If it actually works, of course). I dislike the get/set being in one function (it's not like that in My Library), but these new wrappers were originally designed to replace Dojo's similar methods. Better would be (from My Library):- API.setAttribute(el, 'value', 'myvalue'); -or- E('myid').setAttribute('value', 'whatever'); So, depending on the audience, such wrappers can be useful. Certainly they are a requirement for a CSS selector query engines, parsers, serializers, etc. All of the "major" libraries have some sort of half- hearted attempts. As for the other methods, outside of a test page, you virtually never need removeAttribute. But hasAttribute is occasionally needed (and spottily supported). An example is form serialization. http://www.cinsoft.net/attributes.html
From: Garrett Smith on 17 Dec 2009 18:41 David Mark wrote: > On Dec 17, 5:25 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> John G Harris wrote: >>> On Wed, 16 Dec 2009 at 17:25:33, in comp.lang.javascript, Garrett Smith >>> wrote: >>> <snip> >>>> - 0 SLOC and no bugs whatsoever. >>> How can you be sure your test code had no bugs in it ? >> Good point. Code maintenance involves maintenance of tests. The more >> code, and especially the more /complicated/ code is going to have more >> variables that require testing. SRP, or "do one thing only" is >> applicable to methods and also to tests. >> > > Yes, and the point that I've made repeatedly regarding get/ > setAttribute is that _most_ apps don't need them at all in an HTML > DOM. A very recent example where one could have helped:- > > http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/9c479ab572e72557# > > For whatever reason, the OP wants to set the value attribute of an > input. Of course, I wouldn't recommend a GP wrapper for this one No, the solution provided in the thread, using defaultValue, is shorter, faster. there is no abstraction code download, debug, maintain, and test. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 17 Dec 2009 19:15 Garrett Smith wrote: > Matt Kruse wrote: >> On Dec 11, 1:06 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>> Matt Kruse wrote: >>> | obviously the attr() method is meant to only set string attributes. [...] ng is a event handlers (click, etc) get attached. > > Consider what jQuery actually does with ready, and then with:- > > var el = jQuery("redBox")[0] correction: var el = jQuery("#redBox")[0]; -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Hans-Georg Michna on 18 Dec 2009 09:29
On Sun, 13 Dec 2009 09:44:29 -0800 (PST), David Mark wrote: >E - element >Q - one or more elements (query) >D - document >W - window > >Also, inheriting from E with a few augmentations:- > >F - form >I - image > >I didn't put a lot of thought into them and I never use them, so they >haven't been tested thoroughly. But the typical method is 2-3 lines >long. As you might expect, reading those short methods gives quite an >insight into the API and how to create an alternative interface. And, >of course, they are all "chainable". > >Q('.myclass').fadeIn().onclick(function() { > this.fadeOut(); >}, this); Looks good. The problem is that jQuery already has lots of groupies, including myself. The discussions here have made me warier though. Hans-Georg |