PDA

View Full Version : Ref Property



rodrigok
16 Feb 2011, 3:35 PM
what happened with ref property?

aconran
16 Feb 2011, 3:47 PM
rodrigok -

It's been replaced with a far more powerful ComponentQuery implementation.

http://dev.sencha.com/deploy/ext-4.0-pr1/docs/api/Ext.ComponentQuery.html

This has been integrated throughout the framework at the Component and Container level. For example you can search child/down/up/next/previous just like you've become accustomed to with DomQuery.

We have plans to implement a compatibility layer that will bring ref back for older apps. However, you should check out ComponentQuery it is FAR FAR more powerful and eliminates many of the problems you may have had with ref in the past.

rodrigok
16 Feb 2011, 3:58 PM
Ok, thanks, very useful this new feature, but I think that ref property is still useful in many cases for quick acess for child componentes.

Greate job with ExtJS 4, waiting for themes with examples

Thanks

rodrigok
16 Feb 2011, 4:03 PM
This thread should be in Help section, is not a realy bug. Any Moderator can move this post? Thanks.

aconran
16 Feb 2011, 4:13 PM
rodrigok -

Its much more flexible now.... For example you can search down the component hierarchy for something like this:



reffedItem = this.child('*[ref=myRef]');

steffenk
17 Feb 2011, 3:23 AM
so you still suggest using ref and using query, or is itemId the best way to reference?

TommyMaintz
17 Feb 2011, 4:53 AM
I would suggest getting references just using ComponentQuery right now. I think we might be able to implement something like references: on a container. Maybe something like the following API would work.



references: {
submitButton: 'button[type=submit]'
}


That would add a reference to a button inside this container as a property like container.submitButton.

For now I would suggest using component query though.

Steffen Hiller
17 Feb 2011, 6:29 AM
Not sure if I'm happy with any of those solutions.

The ComponentQuery is powerful, yes, but most of the times I just need a simple automatic reference in my container to its child items.

And having to do something like:


references: {
submitButton: 'button[type=submit]'
}

feels a bit overhead to me.

Can we not have a simplified 'ref' feature, where we specify a ref name, and after the initComponent of a Panel, it loops through all child items and creates those refs.
I know that in the original ref feature, you also need to specify a path like '../childItem'.
Can that not be eliminated, I mean having to specify a path? Would it be a too much of a performance issue to run those ref loops after each container init?


That's just my spontaneous 2 cents.
Thanks.

TommyMaintz
17 Feb 2011, 7:52 AM
Alright, I will make sure we have some more discussions on this internally ;)

Steffen Hiller
17 Feb 2011, 8:03 AM
:)

P.S. Why not in public? :) It might save you from explaining in the future and receive a bunch of questions. Instead you have a thread with all your thoughts and reasons you can link to in the future.

That leads me to the question why Sencha always keeps API changes & features secret until they release them or rather keeps the decision making process behind closed doors? :-|

Just wondering. :)

Christiand
17 Feb 2011, 8:10 AM
That would make too many chief, not enough indians. At some point, you need to stop talking and move forward. That's my guess.

TommyMaintz
17 Feb 2011, 8:15 AM
Actually I don't think we are deliberately trying to keep these things secret. In most cases we just want to have discussions about it internally first. That way we can come back to the community with more confidence on where we want to go with a particular API. We have so many different developers in the team nowadays that usually the internal discussions that we have are pretty much reflective of what they would be on the forums. In a conference room they just go a lot quicker and better managed then on a public forum. Else it would take weeks to get something done! I will however make sure that once we have discussed this particular request, we will come to you guys for feedback ;)

Steffen Hiller
17 Feb 2011, 8:22 AM
That would be cool regarding the feedback.

It's just I had various cases where threads were "closed" with the comment: We've something way more powerful and better coming in the next version. And then you as a user sit there a few months or so and hope they can read your mind and release something that you had in mind and that would be helpful for you. :)
This happened with this ref feature for example.

Just sayin. :)

steffenk
17 Feb 2011, 9:02 AM
My opinion is simular to Steffen's, and not because same first name :)

I love the ref option as it makes the references so easy, just using this.submitButton is much more intuitive than finding it with a query. It there is internally a query doesn't matter, but my code would be very clean this way.

aconran
17 Feb 2011, 11:16 AM
so you still suggest using ref and using query, or is itemId the best way to reference?

Using itemId would be the best way to reference it.



var cmp = this.down('#myItemId');

Animal
17 Feb 2011, 10:09 PM
I would be in favour of some kind of "automated" reference collection the same way we have "renderSelectors" which use DomQuery to grab elements after render.

a "layoutSelectors" object which grabs references using ComQuery selectors in a hash on first layout of the Container.

steffenk
18 Feb 2011, 3:28 AM
just to come back to this issue, when i use itemId. Why should i use component query when getComponent is available? To be honest, using itemId, i expect to reference it with getComponent. How this is solved internally doesn't matter from user perspective. I myself prefer the way my code looks best readable and clean.
Seeing something like this.down('#myItemId') just look exactly like a DOM query, looking for DOM element with id "myItemId" (and down/up etc are valid DOM queries), so there is a fear of mixing these things up.

devtig
24 Feb 2011, 10:15 AM
I would certainly prefer using this.down('#myItemId'); over this.myReffedItem;. The latter may look simpler, but I like the first. Al those reffed items polute my component namespace.

Animal
24 Feb 2011, 7:15 PM
I would certainly prefer using this.down('#myItemId'); over this.myReffedItem;. The latter may look simpler, but I like the first. Al those reffed items polute my component namespace.

They certainly do. And there's so many refs that you cannot have that will collide with properties that already exist.

ComponentQuery is a new departure, but I'm sure people will soon come to rely on it just as much as they rely on DomQuery now.

dajester2008
2 Mar 2011, 10:30 AM
The big issue here in my mind is not which is a better technology - that is an endless (and pointless) war.

The API's keep magically changing, and breaking backwards compatibility. Ext2 -> Ext3 broke alot of stuff, and the same seems to be happening with v4. The users of this library expect their application that they spent endless hours developing to just work without having to go through lines and lines of code to replace missing API dependencies with the new syntax. They expect to gain the benefits of the new core while using the existing API calls.

And furthermore, what we're talking about here is a measly 15 lines of code added to the AbstractComponent class for this to work again.




// from Ext3's Component class source

initRef : function(){
if(this.ref && !this.refOwner){
var levels = this.ref.split('/');
var last = levels.length, i = 0;
var t = this;
while(i < last){
if(t.ownerCt){
t = t.ownerCt;
}
i++;
}
t[levels[--i]] = this;
}
}


and



this.initRef();


in the render() method.

dajester2008
2 Mar 2011, 10:57 AM
We have plans to implement a compatibility layer that will bring ref back for older apps. However, you should check out ComponentQuery it is FAR FAR more powerful and eliminates many of the problems you may have had with ref in the past.

I appologize for my previous post, I didn't read this post as thoroughly as I had thought. This is good news, thank you.

carl23934
2 Apr 2011, 2:41 PM
I really must insist that ref should be brought back. ref was an extremely powerful tool that I thought was just a start to something greater.

Having the ability to easily reference sub-components without querying anything makes for faster code. This was one of my favorite aspects of Ext. JQuery works off this type of querying, and it just makes no sense in the world of javascript component design.

Stanback
2 Apr 2011, 4:49 PM
I was using a ton of refs in my previous code so it took some getting used to (and a bunch of time to port), however, I now prefer the new ComponentQuery methodology. A major maintainability benefit is that it allows nested components to be moved about the hierarchy and .down() will always work. With refs, you had to figure out how far nested the component was and update its ../.. path. While more verbose, I think the up/down/child/next/prev syntax is much more intuitive and explicit.

Either way, you have to enumerate the components - with refs they are enumerated once when the components are initialized, with component query you are doing it every time you select a component. In real-world terms I would think the difference would be negligible since user-generated events are relatively slow. Any time you need to access a component with high frequency, you would just select a reference and set it to a local variable before using it.

Yes, each major ExtJS release has its idiosyncrasies but I'm willing to trade some API consistency for Sencha's best-practice if it's likely to save time on future development and developer training, as well as keep the codebase as lightweight as possible without sacrificing functionality. I think it's important to look at the changes with an open mind.

Steffen Hiller
2 Apr 2011, 10:44 PM
carl23934 , I agree with Stanback.

I also insisted first to get the ref option back. :)
But I gotta say that after using the ComponentQuery methods up and down a while together with itemId, I got pretty used to it.

You can also more easily write generic base classes and reference components by class typ through the component query.

Give it a try.
Also, you still can make your references at the end of your componentInit by adding something like this.childPanel = this.down('#childPanel'), but maybe you don't need references via properties anymore.

Just my two cents.

Animal
3 Apr 2011, 9:21 AM
I really must insist that ref should be brought back. ref was an extremely powerful tool that I thought was just a start to something greater.

And CQ is the greater thing!

Really, just start trying it.

It's used internally to the framework a lot now. It's such a familiar paradigm when you are used to DOM selection.

Just grab what you need by targetting it with a selector.

refs are not coming back, use CQ and you'll never want them back!

Steffen Hiller
3 Apr 2011, 11:22 AM
Animal, as you mention DOM selection, I wonder why you chose the # prefix for finding cmps by itemIds and no prefix for finding cmps by classes?

It took me a bit to get used to that syntax, since in the DOM world a name without prefix is the id (Correction: selectors use # as well, but was used to get an element by id using Ext.get for example where you don't need #.) and a name with a dot prefix is the class.

So basically it would have been easier for me to get used to:


Ext.ComponentQuery.query('myCt .panel');
or
this.down('myCt')

instead of:


Ext.ComponentQuery.query('#myCt panel');
or
this.down('#myCt');


I got used to it now, but just wondering.

steffenk
3 Apr 2011, 1:35 PM
hey namesake :)

i think it's the sample from the docs
http://dev.sencha.com/deploy/ext-4.0-pr1/docs/api/Ext.ComponentQuery.html

But i also would prevent using id's here. if it's the viewport, ok, but normally you don't use id's.

But hash also works with itemId, doc says:

An itemId or id must be prefixed with a #.

sirrashid
9 May 2011, 11:12 PM
Really need ref for backward compatibility.

I have a huge application where at many places we have used ref.

It is stopping us from moving to ext 4 from 3.

Hope you consider.

Thanks

qlegrand
23 May 2011, 3:33 PM
To my mind it's bad programming practice to need to identify a component at least twice - by an id or itemId in the initial configuration then subsequently to find a reference to it by a component query. So if you need (or wish) to change that id you need to change it elsewhere.

The 'ref' property was an excellent idea and I used it extensively. It just seems crazy to drop it.

jvandemerwe
6 Jun 2011, 2:53 AM
@sirrashid, I totally agree! I have the same. Lots of ref's in my applications and now I have to be convinced that the other thing is more powerful. Sure it is, but it is not done, to simply say let's do something better and forget that we ever said there was something about 'ref'. It's not the only thing that annoys me on Ext4. You can't change simply everything with a new release and forget there was a former release (3), which existed long enough to have quite some applications build on it.

jvandemerwe
6 Jun 2011, 3:09 AM
The big issue here in my mind is not which is a better technology - that is an endless (and pointless) war.

The API's keep magically changing, and breaking backwards compatibility. Ext2 -> Ext3 broke alot of stuff, and the same seems to be happening with v4. The users of this library expect their application that they spent endless hours developing to just work without having to go through lines and lines of code to replace missing API dependencies with the new syntax. They expect to gain the benefits of the new core while using the existing API calls.

And furthermore, what we're talking about here is a measly 15 lines of code added to the AbstractComponent class for this to work again.




// from Ext3's Component class source

initRef : function(){
if(this.ref && !this.refOwner){
var levels = this.ref.split('/');
var last = levels.length, i = 0;
var t = this;
while(i < last){
if(t.ownerCt){
t = t.ownerCt;
}
i++;
}
t[levels[--i]] = this;
}
}


and



this.initRef();


in the render() method.


I appologize for my previous post, I didn't read this post as thoroughly as I had thought. This is good news, thank you.

I don't agree that a compatibility layer is a solution to have "old" Ext3 programs run. It creates in the end dirty programming. Like, if I don't understand it in 4, I'll do it still in 3. This is nice for a transition period, but not for the long run. The main issue is that Sencha has to understand that their user base is becoming so large, that they simply can't act that every release change is like going from Ext 0.1 Beta to 0.2 or so. You have to respect to a certain extend also that a great user base is making also a lot of applications, that expect at least backwards compatibility. The forum is too often the source where developers find clarity about migration issues. This means that the compatibility and upgrade guidelines of Sencha are insufficiently documented.

blex2010
27 Jun 2011, 9:49 AM
So do you have an easy way to identity every ref defined and then every use of that ref and then convert to this "better" way of doing things?

Otherwise please bring back ref. Without it we will most likely have to abandon Extjs altogether. The problem is we have a huge investment in this and to go through 100k+ lines trying to figure out where we used a reference and replace it with another way of doing the same thing is never going to happen.

If you have a tool that can identify where we declared refs and then replace them, great. Otherwise it seem like Sencha really doesn't understand how to support enterprise projects and even if it gets better we can't convince management to trust it.

That's really unfortunate as we love it. It just feels like maybe you are too far behind the wall and don't see what impact these changes are having. Just saying the "new way is better" doesn't rewrite 100k lines of code.

:s

StaticVoidMain
22 Oct 2011, 10:59 AM
So do you have an easy way to identity every ref defined and then every use of that ref and then convert to this "better" way of doing things?

Otherwise please bring back ref. Without it we will most likely have to abandon Extjs altogether. The problem is we have a huge investment in this and to go through 100k+ lines trying to figure out where we used a reference and replace it with another way of doing the same thing is never going to happen.

If you have a tool that can identify where we declared refs and then replace them, great. Otherwise it seem like Sencha really doesn't understand how to support enterprise projects and even if it gets better we can't convince management to trust it.

That's really unfortunate as we love it. It just feels like maybe you are too far behind the wall and don't see what impact these changes are having. Just saying the "new way is better" doesn't rewrite 100k lines of code.

:s

I totally agree with you, here is my override to solve this:


Ext.override(Ext.Component, {
initComponent: function () {
this.callParent();
this.on('render', this.setupRefs);
},
setupRefs: function () {
if (this.ref && !this.refOwner) {
var levels = this.ref.split('/');
var last = levels.length, i = 0;
var t = this;
while (i < last) {
if (t.ownerCt) {
t = t.ownerCt;
}
i++;
}
t[levels[--i]] = this;
this.refOwner = t[levels[--i]];
}
});

sumit.madan
10 Nov 2011, 1:41 PM
@StaticVoidMain:

Your override did not work, I modified it to:


Ext.override(Ext.Component, {
afterRender: function () {
this.callOverridden();
this.setupRefs();
},

setupRefs: function () {
if (this.ref && !this.refOwner) {
var levels = this.ref.split('/');
var t = this;
for(var i = 0; i < levels.length - 1; i++) {
if (t.ownerCt) {
t = t.ownerCt;
}
}
t[levels[levels.length - 1]] = this;
this.refOwner = t;
}
}
});