It's good to know I'm not *totally* out of my mind... :)
Thanks,
Colin
> I'm not a core developer, so my opinion has no weight ... but I like
> the concept. Really. =)
>
> I think it would cleanup the widget destroy functions. For example,
> complex Sortables.
>
> TAG
--~--~-~--~~
Hey I'm excited about it. I think your patch is a great idea.
I'm not a core developer, so my opinion has no weight ... but I like
the concept. Really. =)
I think it would cleanup the widget destroy functions. For example,
complex Sortables.
TAG
On Feb 28, 2007, at 2:24 AM, Colin Mollen
> This is where I was taking issue before. You incur no real performance or
> memory hits by keeping an extra reference (if you wanted a local caching
> policy for a class, that is). 2 references to the same object do not more
> memory take.
There is no reason to maintain two separate caches wher
> Maybe we can expose the (currently hidden) Observer class, allowing for a
> plugin?
I couldn't complain about that now, could I? :)
I still think it would be great to add to core, because then SAU and
other widgets could be patched to take advantage of the separate
caching benefits, but I can'
On 2/28/07, Colin Mollenhour <[EMAIL PROTECTED]> wrote:
>
>
> The gist of my patch is this:
Nice summary.
Lastly, why don't I add this functionality separately instead of
> trying to get Prototype patched? It is because the Event class does
> it's own caching in such a way that cannot be extend
>
> Lastly, why don't I add this functionality separately instead of
> trying to get Prototype patched? It is because the Event class does
> it's own caching in such a way that cannot be extended, so such
> efforts would be duplicating the caching and over-complicating cleanup
> procedures.
This
I'll submit a patch, I just wasn't sure if patches to branches were
submitted differently than patches to the trunk.. and I'll start using
Pastie :)
The gist of my patch is this:
-adds an EventCache class that provides the observe/stopObserving
methods
-the EventCache methods handle creating/remo
On 2/27/07, Colin Mollenhour <[EMAIL PROTECTED]> wrote:
>
>
> Mislav's and Andrew's patch has the same characteristics as the
> original Event class in that the global caching is still done
> internally (although only for IE).
Not only for IE anymore - how else could we remove all handlers from a
Thanks for taking the time to write that up. I think you and I are
more on the same page than we thought, your example looks very similar
in structure to my example. I would be completely happy with what you
proposed except for the redundancy. Since Prototype already does
global caching (only rea
So a couple of hours turned into all day. That's just my life these days. We
have a big demo we're getting ready for on Wed. (I can't wait until we can
release some of this stuff)
Anyway, I'll have to try again to write something more concrete for you
later in the week. Feel free to badger me for
Sorry, Colin. I wish I could put a ton of stuff like this up on my blog
(which is basically not even a blog, for total lack of time)... We're busy
with client projects and launching a startup...
I for one, don't find it all that cumbersome to create my handles/observe
during init, and then stop ob
That's just it, I don't fully understand how your GC class is supposed
to work so I was hoping to see a real-world usage example, but if you
are too busy I can understand that completely (maybe you have a page
up already that you could provide a link to?). I think your focus is
on scalability and
Ok. I see you're more or less married to your solution. Just thought I'd
offer up a proven to work, generic, extendable, scalable solution for anyone
interested. The coupling I was talking about was the fact that, as I
mentioned, you are making the user wait for N objects to dispose when they
close
Lightweight indeed! I've been looking for something like this, and I
would have questioned before whether or not it belongs in Prototype
but it is so short and sweet that it certainly wouldn't do any harm to
add it. +1 for this solution, I really like the simplicity.
Colin
--~--~-~--~--
Well, I had written a nice long response to your critique and GC
system and then FireFox decided to crash (I am very pissed) so this
response will be a bit shorter and more blunt..
I don't see how your proposed GC system supercedes my EventCache
proposal or makes event cleanup simpler. Perhaps yo
Colin... since it has been a while since I've contributed anything novel
here, I'd like to offer up some critiques and some code to possibly help you
out on this path you're on (especially since you mention some performance
issues).
What you are specifically talking about (in this portion of this
Hi,
Just to let you know that I have a very lightweight custom event
implementation which is available here (and which I'd hapilly donate
to Prototype if need be):
http://sandbox.tobielangel.com/custom_event/src/custom_event.js
A demo logging the results to the console is available here:
http:/
Oops, my links are localhost! lol...
Here is the test page:
http://colin.mollenhour.com/events/test.html
And the new hybrid code:
http://colin.mollenhour.com/events/event-hybrid.js
Just in case it wasn't clear before, "hybrid" is Mislav's and Andrew's
6194 patch that has been slightly reconfigure
> But it doesn't stop there. Ken Snyder and Colin Mollenhour have been
> collaborating on #7435 that enhances the Event module with a new cache
> system and some API extensions for bulk observer removing. Maybe some of
> those ideas are worthy, so I'd like to have other's opinions.
Ok, like I sai
I'm working on extending your patch with my EventCache feature. Your
Observer class has grown on me so I'd prefer to just extend your
code. :)
I've been doing a lot of testing and one thing I've noticed is in IE,
if you call Event.stopObserving with a function that isn't currently
being observed
Patch at http://dev.rubyonrails.org/ticket/7625
Patch replaces magic numbers with Node constants (four instances, all
in dom.js). Unit tests run on Firefox/Safari on OS X. Still needs
to be tested in IE.
TAG
On Feb 22, 2007, at 8:53 AM, Tom Gregory wrote:
>
> I'll run a find/replace to r
Hvala.
I'll run a find/replace to replace the numbers with constants, and
submit as a patch for that branch.
TAG
On Feb 22, 2007, at 4:28 AM, Mislav Marohnić wrote:
> On 2/21/07, Tom Gregory <[EMAIL PROTECTED]> wrote:
>
> Isn't that as easy as updating Event.element(), or am I missing
> som
On 2/21/07, Tom Gregory <[EMAIL PROTECTED]> wrote:
>
>
> Isn't that as easy as updating Event.element(), or am I missing
> something?
>
> i.e.
>element: function(event) {
> +var e = event.target || event.srcElement;
> +return (e.nodeType == 3) ? e.parentNode : e;
> -return event.tar
I like "The Magic Numbers", but only on CD, not in my code. So +1 to
replace them with constants.
On 21/02/07, Tom Gregory <[EMAIL PROTECTED]> wrote:
>
> On Feb 21, 2007, at 2:56 PM, Mislav Marohnić wrote:
>
> > Also, what about that Safari text-node event target thing? Should
> > we have a fix fo
On 2/22/07, Christophe Porteneuve <[EMAIL PROTECTED]> wrote:
>
>
> Would you submit a full patch over the latest trunk (and verify all
> existing tests still pass once you're done)?
Well, he just submitted full code (no need for patch) and it's unlikely that
it would break anythink since all it d
Tom Gregory a écrit :
> On a similar but slightly unrelated note, could/should Prototype
> ...
I did a lightweight version of that, out of Prototype though, in my
latest book :-) I hate magic numbers as well. AFAIC, +1.
Would you submit a full patch over the latest trunk (and verify all
exis
On Feb 21, 2007, at 2:56 PM, Mislav Marohnić wrote:
> Also, what about that Safari text-node event target thing? Should
> we have a fix for that also?
>
Isn't that as easy as updating Event.element(), or am I missing
something?
i.e.
element: function(event) {
+var e = event.target ||
27 matches
Mail list logo
