[Prototype-core] Re: Porting the old docs
These tickets seem to have been deleted from Lighthouse. Any reason for this? Was there a problem with the patches being submitted? Thanks, Mike. On Nov 17, 9:56 pm, "T.J. Crowder" wrote: > Cheers Mike! > > I gave you a shout over on the user's list; didn't know you were on > this one... > > -- T.J. :-) > > On Nov 17, 7:24 pm, Mike Rumble wrote: > > > > > I can take some of these over the next week or so. > > > Will make a start promptly. > > > Mike. > > > On Nov 16, 4:15 pm, "T.J. Crowder" wrote: > > > > Hey folks, > > > > I've just completely failed to find the time to port all of the old > > > docs, which is (as a whole) a much bigger job than I thought it would > > > be. > > > > So there are now a bunch of "merge old docs" tickets[1] in Lighthouse, > > > each of which is just a bite-sized task (and has the mostly-formatted > > > PDoc as a file attachment, courtesy of Tobie -- he wrote a script to > > > extract and reformat the Mephisto stuff which does a lot of the work > > > for you). That link will automatically search for them for you. > > > > I solicited help from the users in a post[2] over in the user's > > > mailing list. > > > > [1]https://prototype.lighthouseapp.com/projects/8886-prototype/tickets?q... > > > [2]http://groups.google.com/group/prototype-scriptaculous/browse_thread/... > > > > -- T.J. -- 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: Porting the old docs
I can take some of these over the next week or so. Will make a start promptly. Mike. On Nov 16, 4:15 pm, "T.J. Crowder" wrote: > Hey folks, > > I've just completely failed to find the time to port all of the old > docs, which is (as a whole) a much bigger job than I thought it would > be. > > So there are now a bunch of "merge old docs" tickets[1] in Lighthouse, > each of which is just a bite-sized task (and has the mostly-formatted > PDoc as a file attachment, courtesy of Tobie -- he wrote a script to > extract and reformat the Mephisto stuff which does a lot of the work > for you). That link will automatically search for them for you. > > I solicited help from the users in a post[2] over in the user's > mailing list. > > [1]https://prototype.lighthouseapp.com/projects/8886-prototype/tickets?q... > [2]http://groups.google.com/group/prototype-scriptaculous/browse_thread/... > > -- T.J. --~--~-~--~~~---~--~~ 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: Element#insert taking multiple contents
Agreed. Have often thought that this would be a useful addition.
Element.insert(part1, part2, part3)
and
Element.insert({
top : [part1, part2, part3]
);
should both be able to be implemented without too much hassle and
would provide some really valuable functionality - let's make it
happen!
Mike.
On Nov 6, 7:54 am, Deadelus wrote:
> Probably easier to implement using an Array:
>
> container.insert({
> top: [part1, part2, part3],
> bottom: [part4, part5],
> after: "Hello World"
>
> });
>
> On Nov 5, 9:53 pm, Ngan Pham wrote:
>
>
>
> > Would it be reasonable to implement it so that Element.insert takes as many
> > content as you pass it? This will exclude insertion points of course...
>
> > container.insert(part1);
> > container.insert(part2);
> > container.insert(part3);
>
> > would be:
>
> > container.insert(part1, part2, part3);
>
> > Thanks.
--~--~-~--~~~---~--~~
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: Memory Leak in IE
Ok, good points that I hadn't considered. However, I would think that many developers will just use Event#remove without considering the need to remove the event listeners, which could lead to memory leaks. Maybe an Element#destroy method could fill this gap - remove event listeners, remove element from the DOM and then trash it - a destructive method for when the developer says "OK, I'm done with this element..." On Oct 2, 9:06 am, Jim Higson wrote: > On Thursday 01 October 2009 21:56:30 Mike Rumble wrote: > > > You could also encapsulate this in a function wrapping Element#remove, > > which IMHO is something Prototype should do out of the box. > > Quite disagree: > > * If I remove an element and add it elsewhere, I don't expect its events to > have been de-registered. The code that moves the element shouldn't have to be > aware of the (possibly unrelated) code that added the event listeners in order > to ask it to add them again. > > * Removing from the document is not the same as allowing to be GC'd > > * Some elements may never be added to the document. Eg, an XML document which > you download, manipulate then build some HTML representation of. Perhaps you > want to monitor for mutations and keep the HTML in sync? [1] > > Jim > > [1] Not actually possible in IE or Chrome/Safari but would be nice if it were. > In Chrome DOM mutation events only fire if the element is in the > document:http://jimhigson.blogspot.com/2009/09/chrome-and-dom-mutation-events > > -- > Jim > my wiki ajaxification thing:http://wikizzle.org > my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ 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: Memory Leak in IE
Rather than hacking core consider doing something like...
element.descendants().invoke('stopObserving');
element.stopObserving();
..before removing your element from the DOM.
You could also encapsulate this in a function wrapping Element#remove,
which IMHO is something Prototype should do out of the box.
For the future this kind of request is probably best posted in the
general group.
Mike.
On Sep 30, 2:26 pm, kef wrote:
> Hello,
>
> I am currently working on an AJAX application (prototype 1.6.1). As
> usual, it runs very well on Chrome and Firefox but we encounter
> difficulties, particularly with Internet Explorer 6.
>
> After much research, it appears that the problem is related to the
> "memory leak". In fact, i reload only some parts of page. (I keep
> always the header and footer) so a large part of the memory used is
> never released.
>
> I found a solution partially responsive to my needs but it involves
> changing the core prototype. Prior to Ajax call, I clean all events on
> elements will be replaced (like _destroyCache during the unload of
> window).
>
> There may be a cleaner solution but I have not found.
>
> My changes here:
> remove: function (element) (
> / / Begin Fix
> if (element = $ (element))
> element.stopObserving (false, true);
> / / End Fix
> element.parentNode.removeChild (element);
> return element;
> )
>
> stopObserving function (element, eventName, handler) (
> element = $ (element);
>
> / / Begin Fix
> if (handler === true) (
> for (var i = 0, length = CACHE.length; i if (CACHE [i]. descendantOf
> CACHE & & [i]. DescendantOf (element)) (
> Event.stopObserving (CACHE [i], eventName);
> CACHE [i] = undefined;
> )
> CACHE = CACHE.reject (Object.isUndefined);
> )
> / / End Fix
>
> )
>
> In view of the evolution of AJAX and implementation of Internet
> Explorer browsers, I think it may be advisable to incorporate a
> equivalent system in core of prototype.
>
> Regards, Franck
--~--~-~--~~~---~--~~
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] Node List?
A developer that's recently joined my team is new to Prototype and is
finding himself trying to do things in a jQuery-ish way, for example:
$$('.panel').addClassName('red').addClassName('blue');
I explained the differences between the Prototype and JQuery ways of
doing things, and demonstrated that the same result could be achieved
using Prototype with not a great deal more code:
$$('.panel').invoke('addClassName', 'red').invoke('addClassName',
'blue');
At the same time I noticed the NodeList present in the BBC's new Glow
library (see here:
http://www.bbc.co.uk/glow/docs/1.5/api/glow.dom.nodelist.shtml
), and wondered whether Prototype could benefit of a similar module to
allow the element methods to be invoked on a collection of DOM nodes
(the return of $$) and chained together jQuery-style.
A real basic implementation could look something like this, only less
lame
var NodeList = Class.create(Enumerable, {
initialize : function(elements){
this.elements = elements;
},
_each : function(iterator){
this.elements.each(iterator);
},
item : function(i){
return this.elements[i];
}
addClassName : function(className){
this.elements.invoke('addClassName', className);
return this;
}
// More methods here
});
I don't think Prototype needs to make itself like jQuery, and I'm not
looking to start that debate here. I am however interested to hear if
anyone thinks there is any value in this approach, or indeed if not.
Personally I think it would do well to make Prototype more accessible
to newcomers.
Thanks,
Mike.
--~--~-~--~~~---~--~~
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: Form#request ...request
if it's just a case of not wanting to use 'writeAttribute' on each
use, then I'd suggest using Function#wrap to provide a wrapper for
Form#request rather than modifying source adding.
Came up with this in about five minutes...
Element.addMethods('form', {
request : Form.Methods.request.wrap(function(proceed, element){
var url = Object.isString(arguments[2]);
if(url) element.writeAttribute('action', arguments[2]);
return proceed(element, (url) ? arguments[3]||{} : arguments[2]||
{});
})
});
$('my-form').observe('submit', function(e){
e.stop();
this.request('/new/url', {
method : 'get'
});
});
Worth noting that this will still work in the 'old' way of not
specifying a URL.
Hope this helps.
Mike.
On Feb 4, 10:08 pm, "joe t." wrote:
> i've had an ongoing need to make Form#request less dependent on the
> FORM's action attribute. i either need to keep calling
> $("formID").writeAttribute({action:...}).request(...)
>
> or take the long way around with
> new Ajax.Request(url,{parameters:Form#serialize(), ...});
>
> What are the hazards of allowing the options Object to accept the url
> as well:
>
> myCode.js:
> $("formID").request({url:"server_script.php", onSuccess:...});
>
> prototype.js 1.6.0.3 ~3558:
> var params = options.parameters,
> action = form.readAttribute('action') || options.url || '';
>
> Now, i see immediately that the url option would ultimately get passed
> upward into Ajax.Base.options, but does this cause any trouble? i'm
> just curious, because although it may not get much support, i'd like
> to try it out.
>
> Or, if someone has a better suggestion, i'm open. i'm just sick of
> calling #writeAttribute all the time, and i want to avoid putting a
> fixed action value in the HTML.
> --
> joe t.
--~--~-~--~~~---~--~~
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: New Element.Layout API
Looks really useful, always been frustrated that getDimensions
includes the padding and border sizes (I know that's due to Javascript/
CSS rather that Prototype).
I prefer the 'measure' syntax rather than having to first grab an
instance of Element.Layout. However, 'measure' doesn't seem to cache
the instances of Element.Layout it uses so looks like it's a costly
method at the moment.
Perhaps 'measure' could be amended to cache Element.Layout, maybe with
a way of grabbing a fresh 'snapshot' when it's needed?
Thanks,
Mike.
On Jan 16, 9:27 am, Andrew Dupont wrote:
> I've just committed a couple large API additions in a "layout" branch
> in our Git repository:
>
> http://github.com/sstephenson/prototype/tree/layouthttp://github.com/sstephenson/prototype/blob/9d28f04d98307f652a2d85ff...
>
> It's still very preliminary, but Element.Layout is meant to like a
> lazy-loading, memoized subclass of Hash. It gives measurements and
> offsets of practically any aspect an element's layout box. It's lazy-
> loading because some of these computations are costly and shouldn't be
> done unless strictly necessary.
>
> In other words, I can do something like this...
>
> var foo = $('foo');
> var layout = foo.getLayout();
>
> var width = layout.get('width'); // 144 (or some other number)
> var marginBoxWidth = layout.get('margin-box-width'); // 164 (content +
> padding + border + margin)
>
> Behind the scenes, it determined the "width" (i.e., the content box
> width) by taking the offsetWidth property from the element (which is
> the width of the element's "border box") and subtracting the computed
> padding and border widths on both sides. When it did this, it cached
> the values for many other measurements, like "border-box-width,"
> "padding-left," "padding-right," and so on. If any of these values are
> requested directly, no further computation is necessary.
>
> Furthermore, when we ask for the "margin-box-width" (i.e., the space
> the element truly commands), it knows it needs to fetch "margin-left"
> and "margin-right," but the values of all other properties are already
> cached.
>
> (A caveat: because of the caching, an Element.Layout object should be
> treated like a "snapshot" of an element's dimensions. When the
> dimensions of an object change, you ought to grab a new instance of
> Element.Layout.)
>
> Take a look at the code and tell me what you think. The API is far
> from complete, naturally, but it'd be great to know if people think
> this is the right idea.
>
> Cheers,
> Andrew
--~--~-~--~~~---~--~~
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: A question on the code...
Yep, it would fail because undefined is "falsy".
For more about "falsy" values, have a look here:
http://blog.nydd.org/2008/12/26/falsy-values-%E2%80%9Cjavascript-the-good-parts%E2%80%9D/
On Jan 6, 12:42 pm, "Dave Fliger" wrote:
> So the comparison of:
>
> if ( undefined ) {
>
> would fail. Is that correct?
>
>
>
> On Tue, Jan 6, 2009 at 6:31 AM, artemy tregubenko wrote:
>
> > This is ok, because assignment also returns value. What happens here:
> > - seek for a match
> > - if match found, put match data to "match" and go to main branch
> > - if no match found, put undefined to "match" and go to "else" branch
>
> > On Tue, 06 Jan 2009 15:27:04 +0300, plattecoducks
> > wrote:
>
> > > The following looks like a "freshman" error:
>
> > > ln347 while (source.length > 0) {
> > > ln348 if (match = source.match(pattern)) {
> > > ln349 result += source.slice(0, match.index);
> > > ln350 result += String.interpret(replacement(match));
> > > ln351 source = source.slice(match.index + match[0].length);
> > > ln352 } else {
> > > ln353 result += source, source = '';
> > > ln354 }
> > > ln355 }
>
> > > This comes from the latest download, prototype-1.6.0.3.js. Look at
> > > line 348. This type of code is sprinkled throughout the file.
>
> > > This is an assignment and not a comparison. Thus the statements will
> > > always execute.
>
> > > Can this possibly be correct? Like I said, it looks like a neophyte
> > > error.
>
> > --
> > arty (http://arty.name)
>
> --
> A man has to believe in something; I believe I'll go fishing.
--~--~-~--~~~---~--~~
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: Event delegation / registration ideas
Good point about not being able to clear events, although it would be
pretty straightforward to add this functionality in.
Event delegation works well for groups of elements, especially where
you are adding or removing elements and don't want to have to manually
manage the event listeners for each. However it's less useful for
cases where you might have lots of different instances of different
classes on a page (for example modules, panels, buttons) and need more
fine-grained control over the events. My solution works well in this
case because it allows you to register each event separately as you
would with Event.observe, but it internally delegates the events to
the document.
On Jan 4, 10:50 am, Радослав Станков wrote:
> I'm using event delegation a lot recently. I even opened a ticket for
> it -http://prototype.lighthouseapp.com/projects/8886/tickets/435-eventdel...
>
> The problem I see in your approach, is that Event.stopObserving won't
> clear callback from cache, but if your Event.register becomes
> Event.observe (i.e. in core) this may not be a problem) or you can
> just wrap Event.stopObserving.
>
> More I look your idea more it looks to me like an replacement for
> Event.observe. In the ticket the API for event delegation looked like
> this
>
> document.delegate('a', 'click', function(e){ console.log(e.target) });
>
> Witch saves a lot of writing and loop calling. Unfortunately my
> original idea was to have:
>
> document.delegate('click', {
> 'a': log,
> 'div': log
>
> });
>
> ... but it wasn't approved :( / :)
--~--~-~--~~~---~--~~
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] Event delegation / registration ideas
I've been watching the threads discussing event delegation as I think
it's a great way to speed up apps.
All of the solutions I've seen take a similar approach in using a CSS
selector to match elements for the event, and a parent element to
attach the event to.
I thought I'd try a different approach, namely using a single event
attached to the document and using an API identical to Event.observe
to register the events.
My first bash at this code is below, a fair bit of lifted from
Prototype's event handling. I've called this Event.register rather
than Event.delegate to avoid any confusion in the differing approach
to other event delegation.
// Event.register
Object.extend(Event, (function(){
var registerable = $w('click mouseover');
var cache = {};
function getEventID(element) {
if (element._prototypeEventID) return element._prototypeEventID
[0];
arguments.callee.id = arguments.callee.id || 1;
return element._prototypeEventID = [++arguments.callee.id];
}
function getCacheForID(id) {
return cache[id] = cache[id] || { };
}
function getWrappersForEventName(id, eventName) {
var c = getCacheForID(id);
return c[eventName] = c[eventName] || [];
}
function dispatch(e){
var element = e.target;
while(!e.stopped && element && element.nodeType == 1){
var id = getEventID(element);
var c = getWrappersForEventName(id, e.type);
c.invoke('call', this, e);
element = element.up();
}
}
function initialize(e){
registerable.each(function(eventName){
document.observe(eventName, dispatch);
});
}
function register(element, eventName, handler){
var id = getEventID(element);
var c = getWrappersForEventName(id, eventName);
if (c.pluck("handler").include(handler)) return false;
var wrapper = function(event){
handler.call(element, event);
};
wrapper.handler = handler;
c.push(wrapper);
return wrapper;
}
document.observe('dom:loaded', initialize);
return {
register : function(element, eventName, callback){
element = $(element);
if(registerable.include(eventName)){
register(element, eventName, callback);
return element
}else{
return Event.observe(element, eventName, callback);
}
}
};
})());
// Example usage
function log(e){
console.log(e.target);
}
$$('a').each(function(link){
Event.register(link, 'click', log);
});
I'd be interested to hear any feedback about my approach, in
particular about any potential performance pitfalls this may cause.
It's a first bash, and I've not tested it outside of Firefox.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
