jim-jim-jim / base2 Goto Github PK

I've marked lots of bugs as fixed but none of them have been verified by
the original issue raiser.

I don't really care about this, I just wanted to use the new "Type-Meta"
tag. :-)

Take this:
    base2.JSON.String.toJSONString("I said no!") == "I said no!"

but (unexpected)
    var f=base2.JSON.String.toJSONString;
    f("I said no!") == "I%20said%20no%21"

and (explanation)
    var f=base2.JSON.String.toJSONString;
    f.call(base2.JSON.String, "I said no!") == "I said no!"
    this.escape("I said no") == "I%20said%20no%21"
   escape("I said no") == "I%20said%20no%21"

It took me some time to figure this out, because I though a found a bug. The 
inquiry: it's a bit invisible 
with JSON whether you're dealing with a function or a method. Should we (and 
can we) do something 
about this?

A question: with modules, you can in interface methods refer with "this" to 
static members. But you 
can't in Base classes. Is this by design? The difference confused me.

BTW: can you create a "Type-Inquiry" label (if you think it's a good idea)? 
It's just a bit friendlier for all 
of us (and keeps us from the emotional excitement: THIS IS NOT A DEFECT).

Add more standard properties to MSIIE's event object. Currently only
target, preventDefault() and stopPropagaition() are supported.

Especially mouse event properties:

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent

I'm proposing a file-based builder, instead of the current package-based php 
build script. 

Let me explain. We get rid of all package.xml files. For every javascript file, 
we add "extended" 
comments to state the dependencies. For the file base2/DOM/init.js this will be:

//#uses "namespace,selector-api/Selector"

and the file base2/DOM/namespace.js needs to be updated with:

//#module "DOM"

The uses-statement will tell the linker (I'll call this new builder a linker) 
the file init.js is 
depended on two files. The module-statement will tell the linker to create a 
namespace object. 
The linker will actually replace the module-statement with the following:

var DOM = new base2.Namespace(this, {
    name:    "DOM",

So when we want to use the shortcut DOM.$ in our javascript file, we just add 
the statement 
#uses "DOM/init" to our file. This enables the use of the DOM.$ shortcut, with 
a very footprint. 
The linker will only include the necessary files (I'll leave the actually 
included files as an exercise 
to the reader).

One of the problems of the current build system is the fixed namespaces. Either 
you use the 
whole package, or you don't. Take the IO namespace for example. When a WebDAV 
file system is 
created, is it to be included in this namespace?

Somebody wanting to use the WebDAV file system is likely not to use the Local 
file system, and 
vice versa. Creating a separate namespace is not logical, because of the 
"abstract" classes. So a 
possible solution is to create the sub-namespaces IO.local and IO.WebDAV. The 
"abstract" IO 
classes stay in the IO namespace. But with this solution you get more and more 
namespace 
clutter in your code.

File size increases too. This might partially be solved by lazy loading. But 
often, lazy loading is 
"just too late" loading (in contrast with "just in time"). Users accept waiting 
a couple of seconds 
while a web-page loads. But when they press a button on a page, the expect 
near-instant 
action.

I think the current namespace/build system is quite handy, because it's a 
simple (simple as in 
good) system. But it doesn't scale too well.

This linker idea has not yet 100% crystalized yet, but let me fill in some more 
details. We also 
need a "requires" or "imports" and a "exports" statement, which can be used 
along with the 
"module" statement. The linker makes sure, the namespace object is declared 
correctly.

I still need to think about the file-name to object-name resolution. For 
simplicity, I've assumed 
one object per file, ignored directories a bit and omitted the javascript file 
extension. But I'm 
sure we can solve this.

Also, I don't have a 100% clear picture of the semantics of the statements. How 
do the publish 
and closure attributes of the package.xml map to the (just introduced) 
statements? Or do we 
actually need them? Should files be usable without a namespace, when there are 
no (#using) 
dependencies with a file defining a module-statement?

This needs further studying. I think this should be a team effort. But I think, 
this is the right time 
to debate this issue. But before we do that, the following.

As a bonus, including text files as a variables is more natural:

//#include "popupHtml=popup.html"

This will result in something like:

var popupHtml="<html>...</html>";

And it will be possible to add extended regular expressions (ecma script 4 
proposal) in a nice 
way (I'm working on a translator for that):

//#include "rfc822date=RegExtended(rfc822date.regex)";

To be clear: I don't want to build a Ant-like generic build system. The 
strategy is to only 
implement what we really need. And I think multi line RegExp's are really handy 
(you can do 
comments and named matches too). And also an automatic inclusion of the 
MIT-license might 
be an option. The linker should of course support native packing.

I don't think the linker should have knowledge of javascript itself. I see it 
as a preprocessor, like 
you know it from the C-language.

To conclude: the linker should be build with javascript, not php. We can 
provide for this with 
asp+javascript on Windows/IIS (I've written server-side javascript for years) 
and with 
Rhino+FastCGI for Apache, Lighttpd and others.

Another advantage of writing the linker with javascript: take this line from an 
HTML file:
  <script src="build.php?package=some/package.xml"></script>

When you commit this to subversion, the HTML stops working, because Google 
doesn't support 
server-side scripting. I think it's possible to fall back to client-side 
linking... (note: it's a pretty 
cool idea, but not really important to have).

This ends my idea frenzy. I'm interested to know what you think of all this.

The LocalFileSystem object is implemented fully for ActiveX and XPOM. Java
support is still rudimentary.

Need to add:

copy()
isDirectory()
isFile()
mkdir()
move()
remove()

code: 
base2.DOM.bind(document);
document.addEventListener('DOMContentLoaded',function(e){}, false );

hint: call stack size is only 100 on safari, 1000 on firefox.

now: 
  HTMLElement.addClass(document.getElementById("some_id"),"selected");
idea, also support strings:
  HTMLElement.addClass("some_id","selected");

This would make the API much more clean, because we eliminate another potential 
use of the $-
method.

What steps will reproduce the problem?
1. download and install Gran Paradiso Alpha 4 from
http://developer.mozilla.org/devnews/index.php/2007/04/27/gran-paradiso-alpha-4-
now-available-for-download/
2. notice that base2 doesn't work in there

Please provide any additional information below.
the Mozilla bug about implementing Array.reduce:
https://bugzilla.mozilla.org/show_bug.cgi?id=363040

Shall we do the same? I'm writing unit tests...

What steps will reproduce the problem (two test cases)?
tc 1. JSON.toString(null);
tc 2. JSON.toString({o:null});

What is the expected output? 
tc 1. "null"
tc 2. "{o:null}"

What do you see instead?
tc 1. "{}"
tc 2. "{o:{}}"

I will create testscripts for json, but I ran into this one by accident.

The file ~/src/apps/packer/rhino/lib/js.jar is missing from subversion (it's 
referred to by pack.bat).

Maybe an idea to put it in ~/3rd.pary, with a js.txt readme?

Currently, the getComputedStyle() solution for MSIE simply returns an
element's currentStyle property. This property is not identical to
getComputedStyle() and needs a number of fixed to make it more compatible.

On Safari 2.x run followng js

base2.DOM.bind(document);
base2.DOM.bind(window);

alert(document.defaultView);

it will return "undefined" if those two base2 binds would be omitted it
will return expected object.

Working example at following link:
http://mariuszn3.com/base2/csTest.html 
(click get style link)

and exactly same page but without base2:
http://www.snook.ca/technical/safaridisplaystyle/


Latest version of Base2: Fri, 13 Jul 2007 13:13:32

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<---------------------------------------------------------

- create html file with single <button> element
- link base2 library
- run following code in IE(6 or 7):
base2.DOM.bind(document);
document.matchSingle("button").addEventListener("click", function (e) {
    alert("event.target: " + e.target);
}, false);

You can see it working at: http://mariuszn3.com/base2/eventTarget.html

IE on clicking the button will show alert ""event.target: undefined"

It is on last base2 version (Tue, 26 Jun 2007 15:37:27) on Windows XP
Professional

I'm not planning to fix XmlHttpRequest, but to create some kind of wrapper. I 
need:
- access to the server via http on a http:// hosted page, and access to any 
server from a file:// page 
(not possible with Safari, I'm afraid)
- IE fix
- transparent onsuccess/failure (abstracting aways status code)
- timeout handling
- an option to only allow one request at a time. This is an easy way out of 
concurrency troubles.

I've got a first version, but I haven't seen some standards on this, so it is 
destined to stay in /utils/ 
I'm afraid.

When calling addEventListener with two parameters (without the 3rd capture
false argument), different browsers behave differently:
1) Safari accepts this natively (not according to spec)
2) Firefox throws the exception "Not enough arguments" (according to spec)
3) IE accepts this, when base2-dom is being used.

I would expect base2-dom to repair Safari, and to add addEventListener
support to IE according to spec. In this way, develop and test for one
browser, and run without problems (you always hope) on an other browser.

The addEventListener Method accepts as the second parameter either a
function or an Object[1] that implements the EventListener[2] Interface.

[1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget
[2] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener


While writing the demonstration code I see that event.target is undefined
in IE.

Well, I see there is another addEventListener Issue open, but I decided to
create a new one - that one here is totally different...

-gossi

I'm planning to implement HTMLElement.scrollIntoView repairs (at least older 
versions of Safari 
don't implement it).

One point of discussion: the behaviour of the different implementations are not 
the same. For 
example: IE also scroll's horizontal, when it is called upon an inline element.

Do we repair these kinds of issues too?

src/base2/JavaScript/Date2.js and src/utils/Xstra/Date2.js serve the same 
purpose.

Shall we merge code? We might first want to discuss the difference in 
implementations.

- I like your _createObject2
- I like my implementations of toISO and parse better ;-)
- toISO is supposed to serialize in UTC, according to the lastest mailinglist 
entry:
https://mail.mozilla.org/private/es4-discuss/2007-July/000896.html
- the correct name seams "toISOString"
- new Date2(2007,7-1,21).toISOString() should return "2007-7-21T" and not 
"2007-7-
21T00:00:00.0" (return the shortest possible string)
- Date2.parse should use Date.parse if there's no ISO match
- I have test-cases :-P

What steps will reproduce the problem?
1. base2.instanceOf(null, Object)
2. run the script

What is the expected output? 
- false
What do you see instead?
- exception: Null value (Safari)
- exception: object has no properties (Firefox)

Please use labels and text to provide additional information.
will do ;-)

Example:
document.matchAll('*[title="One\'s title"]')

Fails with error:
SyntaxError: missing ) after condition

See test case and workaround: 
http://veerwest.com/sandbox/base2/

Base.forEach will iterate twice over an Array created with "new Array(2)" in 
Safari, but zero times in 
Firefox. According to Firefox documentation:
"Description
forEach executes the provided function (callback) once for each element present 
in the array. 
callback is invoked only for indexes of the array which have assigned values; 
it is not invoked for 
indexes which have been deleted or which have never been assigned values."

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Object
s:Array:forEach

See also the attached test-case

Boolean.toString is using the word "boolean" as parameter, which is a reserved 
word. But only Safari 
chokes on this.

The base2 legacy code is fairly small, and I think it would be good if it
could be included in the packed base2 file automatically. We're either
going to give it to everyone anyways, or use nasty browser detection
methods to try and give it to only those browsers which need it, and will
almost certainly miss some.

I ran into a weird problem, see attached cases.

I got different error messages when I used the normal and the packed
version of base2. After some debugging, I realized I made an error with
instantiating a class.

Although I learned more about the inner workings of base2, most people
using base2 just want to get their work done. Therefor I suggest adding
some assertions at the top-level of the API, giving library users some more
clues (call it API usability).

Note: this is not a bug for packer, although in firebug it looks like that.

At the moment, replacement functions for RegGrp don't know at what index the 
match 
happened. This can be useful when for example a RegGrp implementation is used 
as parser. With 
that info, the position of a parse error can be used.

Below a diff of my solution. It basically calls the replacement function as it 
was directly called 
from String.replace. Initially I only added the lastIndex/offset argument, but 
to be complete, the 
whole string is added as well.

Index: RegGrp.js
===========================================================
========
--- RegGrp.js  (revision 104)
+++ RegGrp.js  (working copy)
@@ -26,7 +26,9 @@
             var replacement = match.replacement;
             switch (typeof replacement) {
               case "function":
-                return replacement.apply(self, slice(arguments, offset));
+                var matches = slice(arguments, offset, match.length + offset + 
1);
+                var matchIndex = arguments[arguments.length - 2];
+                return replacement.apply(self, matches.concat(matchIndex, 
string));
               case "number":
                 return arguments[offset + replacement];
               default:

new Selector("#id1, #id2") matches 1 node in WebKit, but not in Safari. Weird.

This code throws an exception in Firefox:

new base2.JSB.RuleList({
  "a[type=command]:hover": {
    style: { backgroundColor: "yellow" }
  }
});

The exception in Firefox:
  [Exception... "'SyntaxError: 'a[type=command]:hover' is not a valid CSS selector.' when calling   
method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001c 
(NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "<unknown>" data: no]

In Safari: 'a[type=command]:hover' is not a valid CSS selector.


The thing: I'm not sure if you intend for this code to work (using dynamic 
pseudo selectors), but the 
Firefox exception should really be caught, and re-thrown a bit more friendly.

BTW: the new grid-view for the issues rulez! (first, I didn't notice the 
List/Grid choice on the right)

build html with body contents as follows:
<div>
<p>outer paragraph</p>
</div>
<div id="test"><div><p>inner paragraph</p></div></div>

and run js:
alert(base2.DOM.bind(document.getElementById("test")).matchSingle("div
p").textContent);

It should return "inner paragraph" but returns "outer paragraph"

It happens when we query element contents and query has more than one
simple selector sequence. (the query for "div" will return expected value)

Tested on
Win XP, FF 2.0.0.5

I'm using latest base2: Fri, 13 Jul 2007 17:39:33

Above test can be run at: http://mariuszn3.com/base2/selectors.html

This bug is related to one of last updates as on older base2 selector
queries run ok

Forcing an Array2 object to a string results in an "No default value" in 
Safari. It works in Firefox. 
There's something weird going on. When using the toString method on the Array2 
object, Safari 
gives an "Type error", while there is an internal toString method on this 
object. 

See also attached test.

This is also the reason why getElementsByClassName(["selected"]) doesn't work 
with Safari. It gives 
an "'.selected' is not a valid CSS selector."

probably an invalid selector =), but possibly not ;-)

I want to encourage linking directly to Google's subversion repository to
source base. e.g.

<script src="http://base2.googlecode.com/svn/version/1.0/base2.js"></script>

The code stored in the "version" directory *must* never be overwritten. A
later release will have a new URL:

<script src="http://base2.googlecode.com/svn/version/1.1/base2.js"></script>

@Doekman - Is this a good idea? Or should we use tags? I'm not so hot on
subversion.. :-)

See the included testcase (Error.html). When using legacy.js, the
exception.fileName property (supported by Firefox only) is reported to be
legacy.js, instead of Error.html.

This might confuse developers, because the error reported (by firebug for
example) is claimed to be in legacy.js.

This probably also affects the window.onerror event. Within Gecko, the
fileName property is empty (see Error2.html). Within Internet Explorer, the
fileName is displayed.

When using DOM.DocumentSelector, the returned element(s) are not bound to the 
HTMLElement-
Module.

I expect the following line to work:
  base2.DOM.DocumentSelector.matchSingle(document,'p').addClass('test');

but that results in ...addClass is not a function. This works, though:
  eval(base2.namespace);
  eval(base2.DOM.namespace);
  base2.DOM.DocumentSelector.matchSingle(document,'p').addClass('test');

But: only in Firefox. Safari and WebKit still think addClass isn't a method, 
though.

See also attached test-case.

When using RegGrp with non-capturing matches /(?:red\s+)/, the replacements
after the non-captured submatch get mixed up. See testcase.

I'm not sure is it a bug or a feature ;-) ..following:

base2.DOM.bind(document)
window.addEventListener("unload", function () {}, false)

will return "undefined" error in IE (window has not implemented
addEventListener).
I assume that window object is not fixed at all.

I'm using latest base2: Fri, 13 Jul 2007 17:39:33

What steps will reproduce the problem?
1. attempt to reference any Node (i.e. Node.ELEMENT_NODE) or Event (i.e.
Event.CAPTURING_PHASE) constant
2. removing the base2-dom.js file from code allows them to work again

What is the expected output? What do you see instead?
for Node types 1-12, for Event types 1-3 / returns 'undefined'

What version of the product are you using? On what operating system?
Windows XP/Firefox 2.0.0.3

Please provide any additional information below.

I'm working on a WebDAV filesystem (HTTP++). I will use it for starters to 
determine if a wikiword 
is already defined (for my GoogleWikiParser).

I'm defining this as an issue, to communicate I'm working on this. This way, we 
don't waste time, 
writing the same thing. Any suggestions can be added to this issue.

The wiki is currently bare. Which project member volunteers to start
creating some stubs? I'll happily fill in the gaps.

Using latest base2-dom-fp.js from SVN.

The code snippet attached to this ticket will reproduce the problem.

Calling:

    document.matchSingle( "#noSuchId" );

when no such ID exists will trigger an error in IE6:

"'ownerDocument' is null or not an object"

Works fine in latest FireFox, where it returns null, as expected.

Currently the matchAll/matchSingle() methods do not sort the results into
document order (according to the spec). This is not a huge problem for
base2. Most of the time developers don't care about node order. Also, this
bug only affects selectors that are grouped as a comma-separated list.

e.g. document.matchAll("body,html".item(0));

This should return <html> but returns <body>.

If the query is performed using XPath then this bug does not occur.

The attached test-case will duplicate some properties of a Namespace
object. It seems like overridden properties (base, exports, extend,
namespace and name on base2.BOM) are the one being duplicated. Can't nail
it further down though.

Safari Version 2.0.4 (419.3) has this problem

This behaviour is solved in WebKit.

JSB is broken since the checkin of r99. This means, packer.html is also broken.

If you get r93 of lib/base2-jsb-fp.js, it works fine.

What steps will reproduce the problem?

1. Run a base2 test in IE with a console or FirebugLite.
2. Inspect base2.DOM.Event.bind.toString()

What is the expected output? 

bind: function(event) {
  //-dean: put more fixes here
  this.base(event);
  event.target = event.srcElement;
  return event;
}

What do you see instead?

function(object) { return this(object); // cast }

What version of the product are you using? On what operating system?

Version 1.1, r14. Vista.

Please provide any additional information below.

I believe the issue is that the bind-aware implementation of extend in 
Binding can't find nested @rule versions of bind in _static, and so it 
overwrites them with this.bind.

Another way to test it is like so:

foo = base2.DOM.Binding.extend({}, {"@1":{bind:function(){extended!}}})
>> foo.bind remains Binding.bind

I've been keeping up with the recent ES4 discussion about Hash/Dictionary
objects. They use get/put/has/remove for the core methods. Should we change
to match these? base2 is not officially released yet and we are unlikely to
break anything. I can always create a simple patch to alias the old methods
anyway. What do you think? Too late to change? Or follow standards whilst
we still have time?

The forEach-function doesn't work nicely with a DOM NodeList, because the
typeof a childNodes collection is reported a function.

Testcase:
typeof document.body.childNodes=="function"

Workaround:
Because of that, the forEach.Function variant of forEach is used. A
workaround is to use the array-variant directly:

forEach.Array(document.body.childNodes...

Is there a solution? Like giving the '''typeof object.length == "number"'''
test a higher priority?

Tested Safari: Version 2.0.4 (419.3)
Webkit revision 24064 (dd2007-07-06) has the same behaviour

It would be nice to be able to do something like this:

base2.use("DOM");
base2.use("DOM.extras.scrollIntoView");
base2.use("JSB");

Dojo allows lazy loading like this. It's a very cool feature.

Now JSON.Date.toString returns a string in the format "yyyy-MM-ddThh:mm:ss", 
same as on the 
www.json.org site. 

The enhancement is to render the string in UTC timezone ("time zone less"), 
including milliseconds: 
"yyyy-MM-ddThh:mm:ss:milZ".

Before checking in, I'd like your opinion. 

Link base2 library and run following js code in IE(7 or 6) browser:

base2.DOM.bind(document);
base2.DOM.bind(window);

document.addEventListener("DOMContentLoaded", function() {
    alert("window.getComputedStyle: " + window.getComputedStyle);
    alert("document.defaultView: " + document.defaultView);
    if (document.defaultView) {
        alert("document.defaultView.getComputedStyle: " +
document.defaultView.getComputedStyle);
    }

}, false);

You can see it at http://mariuszn3.com/base2/getComputedStyle.html

I expect to see getComputedStyle as valid methods instead I see them as
"undefined"


I'm using last base2 version (Tue, 26 Jun 2007 15:37:27) on
Windows XP Professional 

You can see working example at http://mariuszn3.com/base2/getComputedStyle.html

When serializing a big structure to a JSON-string, Safari raises the error 
"Maximum call stack size 
exceeded". See attached test-case.

This is actually caused by a bug in Safari: 
http://bugs.webkit.org/show_bug.cgi?id=4045

This is a won't fix in base2, but when you might encounter this bug, you know 
where to look.

Can someone verify this for Safari beta 3 on Windows?