D
David Mark
Well, either Google Adsense has blown a fuse or there is suddenly a
huge amount of interest in My Library. Regardless, per request, here
is a simple Ajax example.
// Create XHR wrapper object
requester = new API.Requester();
There is also an Updater constructor that inherits from Requester,
automating periodic updates.
API.updateElement(elTestUpdate, 'http://www.cinsoft.net/
testupdate.asp', false, {
effects:[API.effects.fade, API.effects.slide],
duration: 500
}, null, null, requester);
And the OO version:-
E('myid'),update('http://www.cinsoft.net/testupdate.asp', false, {
effects:[API.effects.fade, API.effects.slide],
duration: 500
}, null, null, requester);
Not thrilled with the method signature as it sits, but there it is.
The false argument means replace rather than append content. The two
null values passed are optional callbacks (so not the ideal order for
the arguments). The first callback is called before the update and
the second after.
From the test page (where lots of examples can be found), this
illustrates how the pre-update callback works. In this test case, the
result can be either HTML or XHTML It tries to get a node if there is
XML in the response _and_ it is possible to import nodes, otherwise
settling for a snippet (string) of HTML.
function updateRequestSucceeded(text, xml) {
var el, html, match;
if (api.setElementNodes) { // Can import nodes
if (xml && xml.childNodes && xml.childNodes.length) {
var el = xml.getElementsByTagName('div');
if (el[0]) {
return el[0];
}
}
}
if (text) {
match = text.match(reDiv);
if (match) {
return match[0];
}
else {
myalert('Content not found in response.', null, 'Ajax',
'alertstop');
}
}
else {
myalert('Response is empty.', null, 'Ajax', 'alertstop');
}
}
Yes, my coding style sucked back when I wrote this.
And as I have
mentioned repeatedly, the library is neither perfect, nor an ideal
design. I've changed my mind about several things since then.
Regardless, it beats the living shit out of jQuery, Prrotoype,
CowTools, etc. for two important reasons:-
1. It is virtually never updated (not a typo)
2. Only one person can change it
Yes, those are the opposites of jQuery's selling points. The code
doesn't have to be constantly updated to "keep up" with browsers, nor
does it require a million monkey army to "maintain". Monkeys tend to
make a mess of things anyway. So I've never really understood either
of those selling points.
Documentation isn't complete, nor are there lots of "friendly"
examples out there. But since most of the "majors" are still fixated
on browser sniffing (in one form or another), their documentation and
examples are dubious anyway (i;e. they might work from now until the
next imperative upgrade).
Any questions about the interfaces, post to the mailing list (without
fear of censorship), questions about the underlying code should be
asked here and questions about licensing should be directed to me (I'm
considering which free license to use).
And yes, there is a sequel in the works...
huge amount of interest in My Library. Regardless, per request, here
is a simple Ajax example.
// Create XHR wrapper object
requester = new API.Requester();
There is also an Updater constructor that inherits from Requester,
automating periodic updates.
API.updateElement(elTestUpdate, 'http://www.cinsoft.net/
testupdate.asp', false, {
effects:[API.effects.fade, API.effects.slide],
duration: 500
}, null, null, requester);
And the OO version:-
E('myid'),update('http://www.cinsoft.net/testupdate.asp', false, {
effects:[API.effects.fade, API.effects.slide],
duration: 500
}, null, null, requester);
Not thrilled with the method signature as it sits, but there it is.
The false argument means replace rather than append content. The two
null values passed are optional callbacks (so not the ideal order for
the arguments). The first callback is called before the update and
the second after.
From the test page (where lots of examples can be found), this
illustrates how the pre-update callback works. In this test case, the
result can be either HTML or XHTML It tries to get a node if there is
XML in the response _and_ it is possible to import nodes, otherwise
settling for a snippet (string) of HTML.
function updateRequestSucceeded(text, xml) {
var el, html, match;
if (api.setElementNodes) { // Can import nodes
if (xml && xml.childNodes && xml.childNodes.length) {
var el = xml.getElementsByTagName('div');
if (el[0]) {
return el[0];
}
}
}
if (text) {
match = text.match(reDiv);
if (match) {
return match[0];
}
else {
myalert('Content not found in response.', null, 'Ajax',
'alertstop');
}
}
else {
myalert('Response is empty.', null, 'Ajax', 'alertstop');
}
}
Yes, my coding style sucked back when I wrote this.
And as I havementioned repeatedly, the library is neither perfect, nor an ideal
design. I've changed my mind about several things since then.
Regardless, it beats the living shit out of jQuery, Prrotoype,
CowTools, etc. for two important reasons:-
1. It is virtually never updated (not a typo)
2. Only one person can change it
Yes, those are the opposites of jQuery's selling points. The code
doesn't have to be constantly updated to "keep up" with browsers, nor
does it require a million monkey army to "maintain". Monkeys tend to
make a mess of things anyway. So I've never really understood either
of those selling points.
Documentation isn't complete, nor are there lots of "friendly"
examples out there. But since most of the "majors" are still fixated
on browser sniffing (in one form or another), their documentation and
examples are dubious anyway (i;e. they might work from now until the
next imperative upgrade).
Any questions about the interfaces, post to the mailing list (without
fear of censorship), questions about the underlying code should be
asked here and questions about licensing should be directed to me (I'm
considering which free license to use).
And yes, there is a sequel in the works...