base2.$ might create problems in the wild about base2

[GoogleCodeExporter]

I don't really like $/$$. I only added them for the slickspeed test - it 
occurred to
me that there was no single function we could provide for the test. I still 
think it
is a good idea to have global functions for DOM queries, otherwise you have to 
do this:

var match = base2.DOM.Document.matchSingle(document, "#id-selector");

versus:

var match = base2.$("#id-selector");

Maybe we can keep $/$$ but just not export those symbols?

Original comment by [email protected] on 16 Jul 2007 at 9:52

[GoogleCodeExporter]

Ahem, $ is defined in DOM, isn't it?

Anyways, my "analysis"

1) matchSingle("#id")
2) base2.$("#id")
3) DOM.$("#id")
4) DOM$("#id")
5) dom$("#id")
6) css$("#id")

and

1) matchAll("input[@type='text']")
2) base2.$$("input[@type='text']")
3) DOM.$$("input[@type='text']")
4) DOM$$("input[@type='text']")
5) dom$$("input[@type='text']")
6) css$$("input[@type='text']")

Explanation:
1) matchAll just, hmm, isn't it
2) this confuses people, if you didn't make a mistake (use base2.$, but import 
DOM)
3) this is already getting better
4) but it's a function, why just not let it be imported
5) and since functions are in thisCase, is should be lower case
6) because DOM is more than CSS, and css$ is a bit more recognizable for what 
it does, I favour this option.

Original comment by [email protected] on 17 Jul 2007 at 12:12

[GoogleCodeExporter]

A bit to quick:

7) $css("#id")
7) $$css("input[@type='text']")

This will respect the community de-facto standard, of using the $-prefix for 
shortcuts.

Original comment by [email protected] on 17 Jul 2007 at 12:17

[GoogleCodeExporter]

1) matchAll just, hmm, isn't it

Currently it is selectElement/selectAllElements which, amazingly, is worse.

http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html

2) base2.$

I quite like it now. :-(

3) DOM.$

This might be the compromise. :-)

5 - 7) I hate the other suggestions.

What about my suggestion. Include base2.$ and base2.$$ but don't add them to
base2.namespace. That way there will be no global pollution.

Original comment by [email protected] on 17 Jul 2007 at 9:23

[GoogleCodeExporter]

Hmm, I still like the $css. It's short, and we can use the $-prefix for our 
top-7 shortcuts:
- $attach   -> addEventListener
- $style     -> getComputedStyle
- ...

But base2.$ is alright too. PR-technical is also sound ;-)
But it might give the impression it's part of base2, and not DOM...

Original comment by [email protected] on 17 Jul 2007 at 9:41

[GoogleCodeExporter]

I want to add one more argument to the discussion; I still don't have a strong 
opinion about the topic, though.

What user and user groups are we catering for? OK, we implement standards. But 
we also do a bit more. The 
JSB system is pretty cool, but has some entry level barrier. We can help people 
to overcome the barriers to use 
base2, by providing some shortcut methods (but it's of course not the only 
barrier leveling method). And are 
you certain, JSB can cater 100% of all cases? If not, document.getElementById 
will be the common denominator 
in which people think. 

Also, shortcuts are handy to "just get it working first, make it nice later". 
We could benefit from a convention 
for shortcuts. This still will be possible with base2.$ (base2.$attack, ehm, I 
mean base2.$attach for example).

We also can of course define a seperate namespace "shortcuts" to add more 
shortcuts to the base2 namespace 
object... This has as advantage, we can postpone the decision (I still can't 
think of much more examples for 
the shortcuts I listed above).

...just some thoughts...

Original comment by [email protected] on 18 Jul 2007 at 4:06

[GoogleCodeExporter]

Oh yeah, _if_ we create a shortcut namespace, we obviously call it "b2" ;-)

Original comment by [email protected] on 18 Jul 2007 at 4:08

[GoogleCodeExporter]

As stated in issue 31, I think base2.$ should return DOM-bind augmented 
elements.

Original comment by [email protected] on 21 Jul 2007 at 8:43

[GoogleCodeExporter]

I've moved the $ methods to base2.DOM. I'm not sure that the $ methods should 
also bind.

> What user and user groups are we catering for?

base2.DOM implements W3C standards. The target audience is people who want to 
use
standards.

> OK, we implement standards. But we also do a bit more.

Not in this library. Maybe in JSB or another library. This package should only 
do one
job - implement W3C DOM APIs. We can always build something cool on top of 
base2.DOM..

I'm keeping this bug open until we make up our minds. :-)

Original comment by [email protected] on 23 Jul 2007 at 8:56

[GoogleCodeExporter]

> > OK, we implement standards. But we also do a bit more.
> Not in this library.

With "a bit" I meant the $ function, and JSB/JST/RegGrp etc.

Another thought about shortcuts: I think this is also personal. People can have 
their own shortcuts-library. 
Maybe we should encourage that.

Another thought: you know in java the file/stream api is very layered. I think 
it's a shame no shortcuts have 
been defined in the jre itself (at least, until jdk5).

Original comment by [email protected] on 23 Jul 2007 at 9:04

[GoogleCodeExporter]

Longer term, I'm thinking of a base-kit package that includes base2, DOM, JSB, 
JSON
and other goodies. I'd prefer to keep the individual packages small and
self-contained, each package solving one particular problem. I still don't like 
the $
function being in base2.DOM but we'll keep it here for the time being. We 
should have
a new status for issues like this - "Stalled". :-)

Original comment by [email protected] on 23 Jul 2007 at 9:39

[GoogleCodeExporter]

I'm closing this bug. If we decide we don't like DOM.$ we can always raise a 
new issue.

Original comment by [email protected] on 27 Jul 2007 at 10:30

• Changed state: Fixed