[Proto-Scripty] Recode jQuery expression in the prototype way
Hi there! I found a very useful script-snippet for endless scrolling. It loads new content via AJAX when the page is near the bottom of the page. My knowledge about JavaScript and Prototype is pretty good actually, but I always had problems with all the measurement stuff. Here's the line of code: var nearBottomOfPage = $(window).scrollTop() $(document).height() - $ (window).height() - 200; How could I get that working with Prototype? Thank you very much! -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes
Hi,
I created a little helper for custom data-attributes:
http://mstuhlmann.wordpress.com/2011/01/10/working-with-custom-data-attributes/
Greets,
mstuhlmann
On 28 Mrz., 12:18, T.J. Crowder t...@crowdersoftware.com wrote:
Because IE munges attributes and properties, you should only ever use
DOM properties for HTML atributes.
This is (as I understand it) one part of the rationale for the `data-`
prefix: There aren't any DOM element properties with those names, and
so IE's broken behavior isn't an issue with them. Yes, it does dump
them on the element instance (if you put a data-foo attribute on a
div, the element instance for that div will indeed have a property
called data-foo on it -- prior to IE9), but it's harmless (though as
always, YMMV).
For instance, try this:http://jsbin.com/ewade3/2
That works fine on IE6, IE7, (I don't have IE8 handy), IE9, Chrome 10,
Safari 5, Firefox 3.6, and Opera 11 under Windows; and Chrome 10,
Firefox 3.6, and Opera 11 under Linux (Ubuntu 10.04 LTS). I don't have
a Mac handy, but it works in Mobile Safari on my iPhone. :-) The IE
checks show that IE6 and IE7 and presumably IE8 (but not IE9, yay) do
dump the data- properties on the element, but you wouldn't look for
them there anyway since no one else does -- stick to `getAttribute`
(or better yet, Prototype's `readAttribute` because of the *other*
insane things IE does with attributes) and you're fine.
HTML5 lets you do this, and pretty much anything else you like, by
adding a data- prefix to the attribute name. Have at it.
HTML5 is not a standard, nor is it widely supported yet.
True. But there are two very different aspects to HTML5: Codifying and
standardizing the things browsers were already doing and had been
doing forever, and defining new things for them to do. By its very
nature, the first part is widely supported. :-) data- attributes
fall into that category (every browser I've ever seen supported custom
attributes on elements; HTML5 reins it in a bit). I dare say that that
subset of HTML5 is a better specification for HTML in the real world
than the HTML4.01 standard from over 11 years ago. Of course, the
trick with the HTML5 spec is knowing which bits are which. ;-)
-- T.J.
On Mar 28, 7:23 am, RobG rg...@iinet.net.au wrote:
On Mar 27, 11:43 am, Walter Lee Davis wa...@wdstudio.com wrote:
On Mar 26, 2011, at 9:37 PM, kstubs wrote:
Is it bad, or does it make parsing objects unstable if you append
custom attributes to an HTML tag? Lets say I want to keep track of
a number, maybe a customers ID, so I do something like:
var div = new Element('div', {'customerID':1234});
The issues are inadvertent overwriting of HTML attributes (so you
can't just use any attribute name, you have to be careful) and IE's
mishandling of DOM element attributes and properties.
To get consistency across browsers, you have to read the attributes
using getAttribute and set them (using code) with setAttribute.
Because IE munges attributes and properties, you should only ever use
DOM properties for HTML atributes.
So you need to be careful to distinguish between the two and only use
the appropriate method, which is why it is usually suggested to not
use custom attributes and to use a data object instead, that way you
only ever use one method that is consistent for all browsers.
which should result in:
div customerID=1234/div
Should being the operative word. Note that in IE, the div DOM
element will have a property of customerID, but it will not in
Firefox. That sort of inconsistency is why you should avoid custom
attributes and properties.
Perhaps that issue is fixed in IE 9, but it will be a very long time
before you can ignore all other versions of IE on the web.
HTML5 lets you do this, and pretty much anything else you like, by
adding a data- prefix to the attribute name. Have at it.
HTML5 is not a standard, nor is it widely supported yet.
--
Rob
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] MessageQueue for queued ajax requests
Hi there,
I want to ensure, that messages are posted in the order, they come in
the stack. My tests at jsFiddle were okay, but with a quick backend
(where the requests are processed very fast) the order is crap.
Sometimes items are posted twice. Is there anybody who can help me
out? Thank you all!
var MessageQueue = Class.create({
initialize: function(url) {
this.url = url;
this.queue = [];
this.idle = false;
},
add: function(message) {
if (this.idle) {
console.log(idle, so saved to queue: + message);
this.queue.push(message);
} else {
console.log(not idle, so pushed directly: + message);
this.push(message);
}
},
push: function(message) {
this.idle = true;
console.log(Ajax.Request will be called now!);
new Ajax.Request(this.url + message= +
encodeURIComponent(message), {
onComplete: function() {
console.log(successfully sent: + message);
if (this.queue.size() 0) {
console.log(queue-size 0, so enqueue next item);
this.push(queued: + this.queue.shift());
}
this.idle = false;
}.bind(this)
});
}
});
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: MessageQueue for queued ajax requests
Hi T.J.,
thank you for your reply. You are right about the idle-flag, I already
renamed it :)
I followed your advice and moved up the idle = false thing, but it
does not work so well.
With a slow connection the code below works fine:
var MessageQueue = Class.create({
initialize: function(url) {
this.url = url;
this.queue = [];
this.busy = false;
},
add: function(message) {
if (this.busy) this.queue.push(message)
else this.push(message);
},
push: function(message) {
this.busy = true;
new Ajax.Request(this.url, {
onSuccess: function() {
alert(message);
this.busy = false;
if (this.queue.size() 0) {
this.push(queued: + this.queue.shift());
}
}.bind(this)
});
}
});
var mq = new MessageQueue(/ajax_html_echo/);
mq.add(First);
mq.add(Second);
mq.add(Third);
But when the backend is fast and you type the hell out of your
keyboard, it seems, that the part
this.push(queued: + this.queue.shift());
is never reached. There is no output with queued:
My thought was, that when new messages arrive, while a request is in
progess, to store them until the request is finished. Then all
messages in the stack should be sent until the busy-flag is set to
false. Therefore I had it below the if-condition.
I saw that the guys at jQuery use a sentinel inprogress which they
unshift/shift to/from the array. But I don't know if that would be
helpful here.
It would be super great if you have the time, to have a second look at
it!
Thank you so much
On 13 Aug., 10:18, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
Your idle flag -- which you seem to use to mean busy processing a
request, which I found *really* confusing at first :-) -- is getting
cleared inappropriately whenever you pull something from your queue. I
don't know that that's the problem, but it's probably wrong. The error
is in your onComplete function:
if (this.queue.size() 0) {
console.log(queue-size 0, so enqueue next item);
this.push(queued: + this.queue.shift());}
this.idle = false; // === Error if `if` above was true
If there's something in the queue, you call `push`, which sets the
flag, starts a new async request, and returns. But then you clear the
flag, so the next time `add` gets called, it'll think it should call
`push` rather than `queue.push` even though there's an outstanding
request.
If you just move the `this.idle = false;` line above the `if`
statement, it should sort out this issue. Whether it solves the
problems you described I can't say, but I suspect it'll solve at least
some of them.
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / comwww.crowdersoftware.com
On Aug 12, 7:55 pm, Moo stuhlm...@fifty-nine.de wrote:
Hi there,
I want to ensure, that messages are posted in the order, they come in
the stack. My tests at jsFiddle were okay, but with a quick backend
(where the requests are processed very fast) the order is crap.
Sometimes items are posted twice. Is there anybody who can help me
out? Thank you all!
var MessageQueue = Class.create({
initialize: function(url) {
this.url = url;
this.queue = [];
this.idle = false;
},
add: function(message) {
if (this.idle) {
console.log(idle, so saved to queue: + message);
this.queue.push(message);
} else {
console.log(not idle, so pushed directly: + message);
this.push(message);
}
},
push: function(message) {
this.idle = true;
console.log(Ajax.Request will be called now!);
new Ajax.Request(this.url + message= +
encodeURIComponent(message), {
onComplete: function() {
console.log(successfully sent: + message);
if (this.queue.size() 0) {
console.log(queue-size 0, so enqueue next item);
this.push(queued: + this.queue.shift());
}
this.idle = false;
}.bind(this)
});
}
});- Zitierten Text ausblenden -
- Zitierten Text anzeigen -
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: MessageQueue for queued ajax requests
Here is a working example:
http://jsfiddle.net/zkuMv/
On 13 Aug., 11:43, Moo stuhlm...@fifty-nine.de wrote:
Hi T.J.,
thank you for your reply. You are right about the idle-flag, I already
renamed it :)
I followed your advice and moved up the idle = false thing, but it
does not work so well.
With a slow connection the code below works fine:
var MessageQueue = Class.create({
initialize: function(url) {
this.url = url;
this.queue = [];
this.busy = false;
},
add: function(message) {
if (this.busy) this.queue.push(message)
else this.push(message);
},
push: function(message) {
this.busy = true;
new Ajax.Request(this.url, {
onSuccess: function() {
alert(message);
this.busy = false;
if (this.queue.size() 0) {
this.push(queued: + this.queue.shift());
}
}.bind(this)
});
}
});
var mq = new MessageQueue(/ajax_html_echo/);
mq.add(First);
mq.add(Second);
mq.add(Third);
But when the backend is fast and you type the hell out of your
keyboard, it seems, that the part
this.push(queued: + this.queue.shift());
is never reached. There is no output with queued:
My thought was, that when new messages arrive, while a request is in
progess, to store them until the request is finished. Then all
messages in the stack should be sent until the busy-flag is set to
false. Therefore I had it below the if-condition.
I saw that the guys at jQuery use a sentinel inprogress which they
unshift/shift to/from the array. But I don't know if that would be
helpful here.
It would be super great if you have the time, to have a second look at
it!
Thank you so much
On 13 Aug., 10:18, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
Your idle flag -- which you seem to use to mean busy processing a
request, which I found *really* confusing at first :-) -- is getting
cleared inappropriately whenever you pull something from your queue. I
don't know that that's the problem, but it's probably wrong. The error
is in your onComplete function:
if (this.queue.size() 0) {
console.log(queue-size 0, so enqueue next item);
this.push(queued: + this.queue.shift());}
this.idle = false; // === Error if `if` above was true
If there's something in the queue, you call `push`, which sets the
flag, starts a new async request, and returns. But then you clear the
flag, so the next time `add` gets called, it'll think it should call
`push` rather than `queue.push` even though there's an outstanding
request.
If you just move the `this.idle = false;` line above the `if`
statement, it should sort out this issue. Whether it solves the
problems you described I can't say, but I suspect it'll solve at least
some of them.
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / comwww.crowdersoftware.com
On Aug 12, 7:55 pm, Moo stuhlm...@fifty-nine.de wrote:
Hi there,
I want to ensure, that messages are posted in the order, they come in
the stack. My tests at jsFiddle were okay, but with a quick backend
(where the requests are processed very fast) the order is crap.
Sometimes items are posted twice. Is there anybody who can help me
out? Thank you all!
var MessageQueue = Class.create({
initialize: function(url) {
this.url = url;
this.queue = [];
this.idle = false;
},
add: function(message) {
if (this.idle) {
console.log(idle, so saved to queue: + message);
this.queue.push(message);
} else {
console.log(not idle, so pushed directly: + message);
this.push(message);
}
},
push: function(message) {
this.idle = true;
console.log(Ajax.Request will be called now!);
new Ajax.Request(this.url + message= +
encodeURIComponent(message), {
onComplete: function() {
console.log(successfully sent: + message);
if (this.queue.size() 0) {
console.log(queue-size 0, so enqueue next
item);
this.push(queued: + this.queue.shift());
}
this.idle = false;
}.bind(this)
});
}
});- Zitierten Text ausblenden -
- Zitierten Text anzeigen -- Zitierten Text ausblenden -
- Zitierten Text anzeigen -
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit
[Proto-Scripty] Re: MessageQueue for queued ajax requests
Thanks T.J.,
your code seems to work quite nice. I updated mine with your hints. I
also removed the alert and replaced it with an update of a container.
It was used for debugging purposes only.
I also added a button, to trigger the add-function by hand.
The problem is, that when you click on the button multiple times (e.g.
3 times) very quickly, it outputs two messages. 2 were added, 2 were
sent. If you have a small timeout between clicks (maybe half a
second), the messages are stored to the queue properly...
It seems that there is no reliable technique to save all user-inputs
which were made in short periods of time :(
Here is an updated version:
http://jsfiddle.net/zkuMv/2/
Thank you so much and I can understand, that you can't dive into
detail so much.
Geetings
Moo
On 13 Aug., 14:23, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
The only remaining problems I'm seeing are that you're using alert
(don't do that, append to the body or something, alert does awkward
things) and you're using onSuccess now instead of onComplete as you
were originally. onComplete is what you want to trigger the next
message (Ajax calls *do* fail).
The queuing seems to work when you use setTimeout to simulate async
ajax:http://jsbin.com/egudo3
...but what the actual problem is when you're doing what you're
describing, I couldn't say without extensive debugging I'm afraid I
don't have time to go into.
Off-topic: Strongly recommend *not* leaving off semicolons and braces
(your add function). You may want to minify later (semicolons) and
leaving off braces in my experience (20+ years in C-like syntax) is
always more trouble than it's worth. YMMV
Good luck,
-- T.J.
On Aug 13, 10:46 am, Moo stuhlm...@fifty-nine.de wrote:
Here is a working example:http://jsfiddle.net/zkuMv/
On 13 Aug., 11:43, Moo stuhlm...@fifty-nine.de wrote:
Hi T.J.,
thank you for your reply. You are right about the idle-flag, I already
renamed it :)
I followed your advice and moved up the idle = false thing, but it
does not work so well.
With a slow connection the code below works fine:
var MessageQueue = Class.create({
initialize: function(url) {
this.url = url;
this.queue = [];
this.busy = false;
},
add: function(message) {
if (this.busy) this.queue.push(message)
else this.push(message);
},
push: function(message) {
this.busy = true;
new Ajax.Request(this.url, {
onSuccess: function() {
alert(message);
this.busy = false;
if (this.queue.size() 0) {
this.push(queued: + this.queue.shift());
}
}.bind(this)
});
}
});
var mq = new MessageQueue(/ajax_html_echo/);
mq.add(First);
mq.add(Second);
mq.add(Third);
But when the backend is fast and you type the hell out of your
keyboard, it seems, that the part
this.push(queued: + this.queue.shift());
is never reached. There is no output with queued:
My thought was, that when new messages arrive, while a request is in
progess, to store them until the request is finished. Then all
messages in the stack should be sent until the busy-flag is set to
false. Therefore I had it below the if-condition.
I saw that the guys at jQuery use a sentinel inprogress which they
unshift/shift to/from the array. But I don't know if that would be
helpful here.
It would be super great if you have the time, to have a second look at
it!
Thank you so much
On 13 Aug., 10:18, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
Your idle flag -- which you seem to use to mean busy processing a
request, which I found *really* confusing at first :-) -- is getting
cleared inappropriately whenever you pull something from your queue. I
don't know that that's the problem, but it's probably wrong. The error
is in your onComplete function:
if (this.queue.size() 0) {
console.log(queue-size 0, so enqueue next item);
this.push(queued: + this.queue.shift());}
this.idle = false; // === Error if `if` above was true
If there's something in the queue, you call `push`, which sets the
flag, starts a new async request, and returns. But then you clear the
flag, so the next time `add` gets called, it'll think it should call
`push` rather than `queue.push` even though there's an outstanding
request.
If you just move the `this.idle = false;` line above the `if`
statement, it should sort out this issue. Whether it solves the
problems you described I can't say, but I suspect it'll solve at least
some of them.
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / comwww.crowdersoftware.com
On Aug 12, 7:55 pm, Moo stuhlm...@fifty-nine.de wrote:
Hi
