[Kss-devel] can KSS bindings become dynamic by borring livequery algorithm?
Balazs Ree
ree at ree.hu
Thu Apr 24 08:27:33 CEST 2008
On Wed, 23 Apr 2008 13:37:51 -0400, Brandon Craig Rhodes wrote:
> I wrote:
>
>> My JavaScript competency is not yet great enough for me to determine
>> this on my own ... [has the author of LiveQuery] done something clever
>> that KSS could do as well?
>
> Ahem. Never mind. I did wind up doing a bit more reading, and
> LiveQuery works by specifically intercepting jQuery calls that modify
> the DOM so that it can recompute its bindings. Obviously this will not
> work with KSS since we can't guarantee by what means the user of KSS
> will be modifying his DOM.
I am sure that at one point, we will arrive to KSS being able to rebind
on the events. I also tried to summarize what's needed here:
https://blueprints.launchpad.net/kukit.js/+spec/unbind-events
So first we must make the kss architecture capable of unbinding events at
all. Which means kss event binders must provide an unbind method as well.
About the difficulty of recognizing what has changed in the dom: it is
possible to do this without patching the dom. From every place from kss
(like addClass or setAttribute) we can call the "change hook"
programatically; from every non-kss code where classes or attributes
change, this hook needs to be called to make kss "aware" of the changes.
So this is not the largest challange in the story imo, although truly it
would be more confortable to have a node.onChange and node.onUnload event.
However there is a bigger challenge. Because a change in a node may
invalidate all the events in the subtree, due to the nature of css
selection, in the most pessimistic case, a
single change in the DOM may invalidate all the rules bound to the page
(think of a class change on the body tag). With the current cssquery
algorithm we use, this may be very time consuming to detect. If we could
modify the css selection in a way that we can speed this up, would be
great but I cannot estimate how much work this would be.
--
Balazs Ree
More information about the Kss-devel
mailing list