[Prototype-core] jobs
jobs http://alljobsbasics.blogspot.com/2009/05/work-from-home-2.html java jobs http://freehrquestions.blogspot.com/2009/06/java-jobs.html oracle jobs http://freehrquestions.blogspot.com/2009/06/oracle-jobs.html dotnet jobs http://freehrquestions.blogspot.com/2009/06/dotnet-jobs.html sap jobs http://freehrquestions.blogspot.com/2009/06/sap-jobs.html hardware jobs http://freehrquestions.blogspot.com/2009/06/hardware-jobs.html networking jobs http://freehrquestions.blogspot.com/2009/06/networking-jobs.html online jobs http://freehrquestions.blogspot.com/2009/06/online-jobs.html jobs http://alljobsbasics.blogspot.com/2009/05/work-from-home-2.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Changes under the hood to event handling
I was having a poke around under the hood of the latest RC and noticed some changes to event handling (I think the changes were actually made for RC1, but none the less). The event handling system now uses the new Element Storage to cache handlers, and I'm interested to learn the rationale for this. Was the change made simply to adopt Element Storage or are there performance benefits? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Changes under the hood to event handling
The former, I believe. I would tend to think that these changes would actually cause higher memory consumptions on one-paged applications (handlers of removed DOM nodes cannot be garbage collected). On Jun 23, 11:53 pm, Mike Rumble wrote: > I was having a poke around under the hood of the latest RC and noticed > some changes to event handling (I think the changes were actually made > for RC1, but none the less). > > The event handling system now uses the new Element Storage to cache > handlers, and I'm interested to learn the rationale for this. Was the > change made simply to adopt Element Storage or are there performance > benefits? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Suggested addition to Function Methods: .repeat(seconds[, arg...])
I detest the way setInterval() looks, so I came up with this... have been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval = args.shift() *
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5);
Will, of course, repeat repetiousPollFn() every half second.
Almost identical to .delay(), except that it returns setInterval instead of
setTimeout. One thing I intend to add is support for clearInterval, however
I figured I'd at least bring it up here first. I've never
proposed/contributed here before (i'm a lurker of the list :D ) - any
guidance is appreciated.
Rick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Adding a object data to PeriodicalExecuter
Why you can't use closure or Function#curry based on it?
(new PeriodicalExecuter(function(someData){
var x = someData.num;
//
}.curry({ num: 1, text: "string" })));
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Adding a object data to PeriodicalExecuter
I used a inherit class to implement that functionality:
var PeriodicalExecuterUserData = Class.create(PeriodicalExecuter,
{
initialize: function($super, callback, frequency, userdata)
{
this.userdata = userdata;
$super(callback, frequency);
}
});
then you can use this object calling
new PeriodicalExecuterUserData
(
function (pe)
{
// do something inteligent with pe.userdata;
pe.userdata.number++
pe.userdata.string = "string2"
pe.stop();
},
0.1,
{ number: 1, string: "string" }
);
On 22 jun, 18:45, superruzafa wrote:
> Hi, I needed access some object in each iteration of a
> PeriodicalExecuter's function but I didn't want to use global
> variables. So I modified the definition of initialize method of
> PeriodicalExecuter class declaration adding a new parameter "data":
>
> var PeriodicalExecuter = Class.create({
> initialize: function(callback, frequency, data) {
> this.callback = callback;
> this.frequency = frequency;
> this.currentlyExecuting = false;
> this.data = data;
> ...
>
> Then I could retrieve this object through the pe parameter of the
> function called every iteration through pe.data. Would be useful to
> implement officially this? There is any reason to don't do it?
>
> Even, I think I could declare a subclass of PeriodicalExecuter like
> PeriodicalExecuterParam or so.
>
> What do you think?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: XML namespace trouble and possible work-around
2009/6/22 Elit :
>
> Earlier today I ran into a little problem.
> I have this XHTML page which I create with an XML/XSL transformation.
> When the page is loaded, I tried to add an element to it using
> prototype's 'new Element()'. That created an element which I could add
> to the page, but after that I could not get a reference to it with the
> $() function, nor could I call new Element().update() because
> apparently the object didn't get extended. (This occured in Firefox 3
> and Safari 3.2. using prototype 1.6.1_rc3, IE 6 & 8 worked as
> expected)
>
> I found out that the element got added with an empty xmlns attribute
> and I concluded that it was a namespace issue. I tried fixing it by
> calling 'new Element(tagname, { xmlns: 'http://www.w3.org/1999/
> xhtml'}) to match my document's namespace, but that didn't solve the
> problem. I ended up tweaking the Element function so it would use
> document.createElementNS if needed and available (IE doesn't support
> it, but luckily doesn't need it either.)
>
> global.Element = function(tagName, attributes) {
> attributes = attributes || { };
> tagName = tagName.toLowerCase();
> var cache = Element.cache;
> var ns = attributes.xmlns || false; // ADDED
> if (ns) delete attributes.xmlns; // ADDED
> if (SETATTRIBUTE_IGNORES_NAME && attributes.name) {
> tagName = '<' + tagName + ' name="' + attributes.name + '">';
> delete attributes.name;
> if(ns && document.createElementNS) { // ADDED
> return Element.writeAttribute(document.createElementNS(ns,
> tagName), attributes);
> }
> return Element.writeAttribute(document.createElement(tagName),
> attributes);
> }
> if (!cache[tagName]) {
> if(ns && document.createElementNS) { //ADDED if/else
> cache[tagName] = Element.extend(document.createElementNS(ns,
> tagName));
> }
> else {
> cache[tagName] = Element.extend(document.createElement
> (tagName));
> }
> }
> return Element.writeAttribute(cache[tagName].cloneNode(false),
> attributes);
> };
>
>
> So, if I now call new Element(tagName, { xmlns: 'http://www.w3.org/
> 1999/xhtml'}) everything works as expected, and nothing seems broken
> (If I had a nickel every time I heard that hehe)
>
> Don't know if you want to or should add this to Prototype, but I
> thought I'd just post it in case someone runs into the same problem.
>
> >
>
For the majority, should the namespace be defaulted to
'http://www.w3.org/1999/xhtml' if it is not supplied?
My thinking is if this is the default namespace, then the default
namespace should be used when using new Element().
Maybe?
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
