discussion

Jérôme,

I did not find a lot of changes (my bad memory I think) but did see this, perhaps new.

“Work on the equivalent of the ‘jQuery.noConflict’ method to avoid conflicts with the use of the ‘$’, ‘$$’ or ‘_’ methods. Cleanup Wink code to remove occurrences of $ by wink.byId (priority 1.)”

Cleaning out references to $ and $$ from wink code is perhaps rewarding on its own. But I would suggest that the resulting code when used with jQuery will still lack the cross-browser compatibility sought by introducing jQuery in the first place. Wink’s UI elements simply do not conform nor are they designed for truly cross-browser use, even with the user’s option to include jQuery.

I would suggest another path. Yes, clean up the $ and $$ references in the code. But then introduce a new ‘$’ method that is similar to ‘$$’ broader as in jQuery, returning a wrapped nodes list. Much of the other functionality such as fragment creation, ready function setting, and and the like can be added in if desired. But this new $ function can be replaced by jQuery or a user’s own version with the sane interface design. The user’s version can include the extended options and the user’s wrapper can be extended to include as much of jQuery’s functionality as required.

The key is the ‘interface’ definition. $ always returns a list of o or more elements, defaults context to the root.document and can accept window as a single ‘element’. The list prototype can be extended by
the user as seen fit.

Well I must go for now and will think about this more.

Greg

Jérôme,

I’ve already done a good bit of that via cut and paste mostly. My approach has been to make a comprehensive jQuery’ish ‘$’. Comprehensive as in handling all of the same functionality:

$( function ),
$( fragment ),
$( selector ) w/ selector as node or string, and
$( selector, context ) w/ context as a node.

This method has no equivalent in Wink – aside from a close ‘$$’ method, so it’s simply an addition to the toolkit.

The next issue with the ‘$’ method is a comprehensive wrapper. The return value from ‘$’ is an array-like class that exposes all the necessary DOM manipulation methods, and more. These methods are designed to apply DOM manipulations to one or more of the nodes collected by the $(…) method. (This is where Wink will best integrate.)

And finally, chaining. Chaining of DOM manipulations methods is a key feature of jQuery-style javascript development. This is easily accomplished by most wrapper methods simply returning ‘this.’ Simply accomplished in our faux ‘$’ class/method.

So, the key is to integrate necessary wink core methods into the faux-$ wrapper; and this is easily accomplished. The wrapper is also extensible by simply adding functionality via “mixing-in” additional methods to the wrapper’s prototype, $.

Example:

wink.mixin( $.prototype, {
…
addClass: function( classNameString )
{
return this.each( function ( node ) {
wink.fx.addClass( node, classNameString );
});
}
…
});

(The method, $.each returns ‘this’ which enables our chaining.)

This examples uses two wink methods: mixin and addClass. Mixin simply extends our jQuery’ish $ method and wink’s addClass method is used as an iterator function for each node in our wrapped nodes list.

Well, that is about it for now. I can paste together a more complete example should someone like.

Greg

Jérôme,

I did cut up one of my code bases to separate out a simple “magic$” function that can stand in for jQuery’s $-selector method. It does not include all of the DOM methods although, these are easily added in via the Class prototype as is usual. It’s small, only some 1650 bytes compressed and framework agnostic. The only dependance is my Collections Class, itself less than 800 bytes compressed.

The Collections Class is a non-standard sub-classing of the Array data type. Collection objects are able to use standard Array bracket ‘[ ]‘ notation for accessing member elements. Also, instantiated collections have full access to all Array data type methods such as ‘sort.’

So, the “magic$” starts out as a sub-class of my Collections Object carrying along all of the benefits of the Array data type. Through standard prototype extending, all other DOM functionality can be added, as desired.

The $’s real purpose is to find one or more DOM nodes that match a specific selector pattern within a certain DOM context. That is:

$( selector [, context] );

where context defaults to the current documentElement. This is what my implementation does, handling a wide range of selector types including:

Function:
DOMContentLoaded event function queue.
Object:
Existing magic$ collection list.
Existing DOM node.
New DOM fragmant.
window.
Simple String:
ID selector.
Tag selector.
Class selector.
Compound single selector.
HTML fragment string.
CSV String:
ID selector.
Tag selector.
Class selector.
Compound single selector.

It could easily be extended to address more cases, should anyone need, but I think this is sufficient for my needs. Some attempt was made to expedite common use cases, but room remains for more such efforts. Similarly, like all cut and paste, additional testing is in order. I did minimal testing of this version but I do not have the equipment required for exhaustive testing.

Of course you could write your own and most likely will at some point. But should you like, I’ll be glad to email you a copy of this one. Just let me know.

On the side, the Collection base class is useful by itself as the missing link between the views and their data models. Properly configured it could be useful in data-binding situations.

Anyway, let me know.

Greg

Hi,

wink does partially not work with chrome 19; is it a chrome bug ?

Hi,

@pepi: do you have that kind of exception: “Uncaught TypeError: Property ‘translate’ of object # is not a function ” ?

Jérôme

Well, this is a problem caused by our HTMLElement prototype extensions. They were in conflict with a new read-only “translate” property for HTML Elements that has been implemented in WebKit.

This is something we have fixed in Wink 1.4.2 by removing “dom.js”.

If you decide to migrate to Wink 1.4.2 (the development branch on github), there will be a few minor changes to make, but you can ask and I’ll guide you through

Jérôme

We intend to relaese Wink 1.4.2 around june 11th

Jérôme