search

goupviet / base2

Automatically exported from code.google.com/p/base2
0 stars 0 forks source link

base2.$ might create problems in the wild #24

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The new $ (and $$) function might create problems for users when people mix our 
library with 
others. At least, when the functions are not "compatible". 

If we have a function called "$", I think it should follow the defacto 
(=prototypejs) interface. It 
should then of course enrich the result with base2.DOM.bind. It also might 
optionally log an 
entry (if (console&&console.log)console.log(id)) if the element hasn't been 
found; that saved me a 
lot of time.

But for the current $ and $$ functions: why not just call them $one and $all? 
Or cssOne and 
cssAll? 

That's short enough, and is unlikely to collide with other libraries (I haven't 
researched that). We 
might even create an optional extra's "import" (just a thought, not necessarily 
a good idea):
   eval(base2.DOM.namespace);
   eval(base2.DOM.extra);
or even
  eval(base2.DOM.namespacePlusPlus);

The result of my Quest for the Handy but Hideous Dollar function:
---8<---------------------------------------------------------
prototypejs: http://www.prototypejs.org/api/utility/dollar
  $(id | element) -> HTMLElement, 
  $((id | element)...) -> [HTMLElement...]
  $$(cssRule...) -> [HTMLElement...]

jQuery: http://docs.jquery.com/Core#.24.28_html_.29
  $(html_string) -> jQuery
  $(Element|Array<Element>) -> jQuery
  ...

MochiKit: http://mochikit.com/doc/html/MochiKit/DOM.html#fn-$
  $(id | element ) -> HTMLElement
  $(id | element, ... ) -> [HTMLElement]

MooTools: http://docs.mootools.net/Native/Element.js#$
  $(id | element) -> HTMLElement | false
  $$   -> very extensive

Tibco General Interface: 
http://www.tibco.com/devnet/gi/product_resources34.jsp?tab=
  not used

YUI:
  not used

ASP.NET Ajax (MS): http://ajax.asp.net/docs/
  I remembered they decided against the $-method, and created a $get-method instead:
    http://ajax.asp.net/docs/ClientReference/Global/GetShortCutMethod.aspx
---8<---------------------------------------------------------

Original issue reported on code.google.com by doek...@gmail.com on 16 Jul 2007 at 7:28

GoogleCodeExporter commented 9 years ago 
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 dean.edw...@gmail.com on 16 Jul 2007 at 9:52

GoogleCodeExporter commented 9 years ago 
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 doek...@gmail.com on 17 Jul 2007 at 12:12

GoogleCodeExporter commented 9 years ago 
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 doek...@gmail.com on 17 Jul 2007 at 12:17

GoogleCodeExporter commented 9 years ago 
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 dean.edw...@gmail.com on 17 Jul 2007 at 9:23

GoogleCodeExporter commented 9 years ago 
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 doek...@gmail.com on 17 Jul 2007 at 9:41

GoogleCodeExporter commented 9 years ago 
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 doek...@gmail.com on 18 Jul 2007 at 4:06

GoogleCodeExporter commented 9 years ago 
Oh yeah, _if_ we create a shortcut namespace, we obviously call it "b2" ;-)

Original comment by doek...@gmail.com on 18 Jul 2007 at 4:08

GoogleCodeExporter commented 9 years ago 
As stated in issue 31, I think base2.$ should return DOM-bind augmented 
elements.

Original comment by doek...@gmail.com on 21 Jul 2007 at 8:43

GoogleCodeExporter commented 9 years ago 
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 dean.edw...@gmail.com on 23 Jul 2007 at 8:56

GoogleCodeExporter commented 9 years ago 
> > 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 doek...@gmail.com on 23 Jul 2007 at 9:04

GoogleCodeExporter commented 9 years ago 
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 dean.edw...@gmail.com on 23 Jul 2007 at 9:39

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

Original comment by dean.edw...@gmail.com on 27 Jul 2007 at 10:30