From: Garrett Smith on
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
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
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
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
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