View Full Version : Deprecating getEl - Input appreciated
24 Jan 2007, 8:04 AM
In the next release, the Ext object has a lot of shortcut functions on it. For example:
Ext.get('my-el'); // returns Ext.Element
Ext.fly('my-el'); // returns flyweight Ext.Element
Ext.select('div.foo'); // composite
Ext.query('div.foo'); // raw array
In previous versions, getEl() was the global function used to grab an Element and getEls() was used for selectors. In the next release, I am considering removing both in favor of using the functions above. Currently, getEl/getEls are the only global functions that could possibly create a conflict. Removing them seems like a good idea.
For those who didn't like the new way, it would be fairly simple to say:
getEl = Ext.get;
and in fact in compat.js (I am trying to make a compat file to help the transition to 1.0), I will include the alias above.
What do you think?
24 Jan 2007, 8:07 AM
much better imo!
24 Jan 2007, 8:08 AM
Could you explain "Ext.fly('my-el'); // returns flyweight Ext.Element"? What is a flyweight Ext.Element?
24 Jan 2007, 8:23 AM
In a nutshell, 1 Ext.Element object is shared amongst all calls to Ext.fly().
You may have a bunch of elements that can change (via ajax or whatever) and you don't want to create a cached Ext.Element object for every one. You just need to do something to it quickly. In the past, I would use a call to YAHOO.util.Dom/Event to do it. Now, you can reuse a lightweight Element:
It gives you the Element object functionality, without actually creating an Element object. The only caveat is that it should only be for immediate use as a later call to Ext.fly() will change the internal dom node.
24 Jan 2007, 9:35 AM
i like the inclusion of a flyweight accessor. for large applications which use a large amount of calls to getEl(), this could minimize the app footprint in the browser.
24 Jan 2007, 10:49 AM
Regarding the original question, definitely remove getEl(), no question. With the compat file, there's absolutely no reason not to.
24 Jan 2007, 11:29 PM
My understanding of yui-ext is limited but I fail to understand why do we need separate functions??... cant we have single function for "get" and "select" and include "fly" as an optional parameter???..... that way we may be able to have flyweight composites someday....
I still dont know what u mean by raw array..... if it is an array of Ext.Element objects, then I guess that can be implemented as another optional parameter, or maybe another function would be fine here....
if I am missing something, plz excuse me for my ignorance
25 Jan 2007, 8:43 AM
Questions are always good manu, so thank you for asking:
that way we may be able to have flyweight composites someday....
Flyweight composites are already supported and are the default. Passing "true" as the second parameter to the select() function gives a "heavy" composite. This is similar to what you suggested.
Cant we have single function for "get" and "select" and include "fly" as an optional parameter???
The logic of fly and get are completely different. What they can take as an argument is also different. I have made enhancements to trim every last millisecond off of get() in the current build, and the last thing I want to do is add in new logic that slows it down in anyway.
The other part is fly() should be distiguished as a separate action, because using how standard elements are used (e.g. this.el = getEl('foo'), storing a ref) will create hard to track bugs.
And third, but less important - it's shorter and easier to use IMO. :D
As for the raw array, this is when you just want an array of DOM nodes (not a composite element) and is nothing more than a shortcut to DomQuery.
Optional parameters are good for many things (I am a big fan of them, as I'm sure you can tell), but this isn't one of them. Code like Ext.get('whatever', true, false) is not apparent in what it is doing, and IMO looks hideous. Maybe that just me though. :)
I don't see why I can't include a 5th function, Ext.?????() which looks at the args and execs the correct one of those 4 functions, and has an optional flyweight param.
25 Jan 2007, 9:48 AM
I have 2 remarks about the naming of the 'fly' function:
1. The result of the 'fly' function is not implied by the name of the function (not everybody knows what the flyweight pattern is).
2. The 'fly' version of CompositeElement is called CompositeElementLite.
Combining both points I would suggest naming the function getLite (or getl for short).
25 Jan 2007, 11:02 AM
ya now I see that there already is a flyweight version of the CompositeElement in docs... sorry for missing that.... and I agree with condor on the function name.... getLite is much better....
but I dont understand the difference between "get" and "select".... is it only that "get" returns an Ext.Element object and "select" returns a CompositeElement??....
25 Jan 2007, 11:30 AM
"getLite" is a horrible name -- it implies little about what is returned and would be confusing to someone who does know patterns. "getFly" implies exactly what it does (which is more than just a "lite" version -- it's actually a "lite" shared instance, which is different).
"CompositeElement" also implies something about what it is (i.e. Composite pattern). Lack of knowledge about patterns is not a good reason to advocate not using patterns. The best way to increase the general knowledge of patterns in the development community is for people like Jack to use them (with appropriate naming standards), and Jack does a fantastic job of this in Ext.
25 Jan 2007, 7:56 PM
I agree with Brian, I am not a big fan of getLite() either.
I actually really like fly(), you really don't like it? It's short (which is good because I use it everywhere), and to be honest, get() is so fast in the new version most users won't need to use fly() anyway. Those that do should have to understand exactly what it is and what it does. That understanding is important to prevent 100 bug reports of elements no longer functioning. ;)
FYI, CompositeElementLite was a temp name that somehow stuck because it made it way into SVN. ;)
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.