[Kss-devel] API change in base2

[Balazs Ree]

On Sun, 09 Mar 2008 21:35:45 +0100, Jeroen Vloothuis wrote:

> Balazs Ree wrote:
>> On Sun, 09 Mar 2008 14:39:10 +0100, Malthe Borch wrote:
>>
>>
>>> It seems in base2 1.0 beta, the matchAll-method has been renamed to
>>> querySelectorAll. I changed this locally in dom.js:96 and it seems to
>>> work.
>>>
>>> Note that this version of base2 is larger in size, but gzipped it's
>>> only 1.5 kb more.
>>>     
>>>     
>> Thanks Malthe for spotting this! If there are no objections I would
>> make the kss code test for both versions, this would allow it to
>> operate with both api versions.
>>   
> I was thinking about a way of making it possible to be less depended on
> specific checks. The reason for this is that although jquery may seem a
> bit slower it might be good enough for some (non Plone) applications. If
> these applications already use jquery for something else they should not
> have to drag in base2 just to use KSS.
> 
> The way I propose to handle this is to make a namespace for utility
> functions like CSS selectors. We could also put handy functions like
> forEach etc. in there (which in most cases would just be aliases to the
> functions from base2 / jquery etc.).
> 
> If we implement it like this you would just need to toggle which
> javascript file is loaded (using the plugin system).


You are banging on open doors! The proposal for this is on launchpad 
since quite some time:

http://paste.plone.org/20033

I really remember having discussed this with you personally on more 
occasions, but from your reaction it seems that I may be wrong. 
In any case, I tried to communicate the importance of this work on 
several occasion before to both the kss and the Plone developers, so I am 
glad to receive a positive reaction from you now.

The implementation for this has been finished in the first week of 
January, and is waiting for merge since then. I targeted this to be 
merged for version of kss 1.4, but in the end another decision has been 
made.

I will rebase this on the newest kukit trunk (will be quite some work sue 
to other merges since then), change the 
variable names as discussed with Godefroid on the snowsprint, and submit 
it for a second review. You can expect this within a few days

Besides the implementation of the service layer, the branch contains a 
generic refactored implementation of the entire kukit plugin system, as 
well as several very important code cleanup and a few algorithmic 
speedups as well.

I count on your positive vote for merge.

-- 
Balazs Ree