[cosmo-dev] DOM ids for wayward elements

[Matthew Eernisse]

Responses inline below ...

Travis Vachon wrote:
> I'm actually not advocating a namespaced scheme like the one proposed 
> there, nor am I proposing we track ids anywhere. I'm saying we should 
> make sure ids are semantically descriptive, and solve the problem of id 
> collisions if and when we have it.

You folks tell me how you want to do it, and I'll follow whatever 
process you come up with.

>> It will actually be a little more work for me (I'll happily explain in 
>> detail as to why to anyone interested :))
> 
> Given the chatter on IRC (it's been in the Windmill channel only because 
> that's where it started, sorry about that!) I think it is necessary to 
> do this on this list. Sorry to create this extra work, but I think 
> working out this issue now in this forum will really help us work in the 
> future.

The difference for me personally is obvious.

What I do now:
Document already existing JS namespace paths for QA for any new pieces 
of UI. Add refs to any elements that don't already have them (that's 
happened maybe twice in the last year?).
Time required in a year: less than 20 minutes.
Cognitive overhead: Approaching zero

What I will have to do:
Come up with semantically meaningful ids for every element of the UI 
that I create (down to each and every button of every dialog box), with 
enough specificity to ensure a very low probability of collision with 
any other element in the UI.
Time required in a year: Unknown (aggregate 10 minutes? 20?)
Cognitive overhead: Definitely above zero, enough to annoy me

Having actually used both approaches on large, complicated, Ajaxy Web 
apps, I can definitively say that the first approach requires 
significantly less effort for me personally.

That's all really beside the point, given the obvious advantages 
(robustness, transparency) of the unique-ids approach for testability.

Y'all figure out what you want to do with this, and let me know what the 
process is.

As I mentioned all those references to the the various parts of the UI 
are there anyway, and will continue to be there, so existing tests won't 
break in the meantime.

Thanks.


Matthew