View Full Version : [CLOSED] NodeInterface should decorate instance not class when a root is specified in a tree

19 Dec 2013, 3:29 PM
When a root node is explicitly configured in a tree panel which uses an externally specified model (as opposed to the implicit one), the model CLASS gets decorated by the methods of the NodeInterface class when the root node is instantiated. This causes the definition of the model to change (it now has all the attributes from NodeInterface). Since model classes may be used outside of a tree and may represent general business objects, this is not correct. The decoration should only happen to the root node model instance and not the model class.

Gary Schlosberg
20 Dec 2013, 5:25 AM
Thanks for the report! Can you please post a test case which reproduces the issue?

20 Dec 2013, 1:48 PM
It has to happen to every node in the tree, which is why the model gets decorated. All the extra fields are set to not persist by default.

It would be expensive to dynamically decorate every node as it gets pushed onto the tree.

This is not a bug, working as intended.

20 Dec 2013, 3:54 PM
I think changing the definition of a class that is meant to be reusable is bad design. I certainly understand the working as designed comment but that doesn't make it a good design decision.

Consider the following use case:
I have a business object with some complex relationships that I want to create and I present a UI which happens to use a treepanel to create an instance of that object. When I'm done creating I serialize the model object (I'm not necessarily using the model's proxy to save the fields - which is another assumption you are making - it's certainly great that the framework provides the proxy but the model should be persistable using any means appropriate for that project/situation - an assumption that's quite unnecessary I might add). So now I have to know which fields have been "polluted" by the NodeInterface decoration otherwise I'll end up sending all these other properties to the server. Why!

If you wanted to decorate every model you can do what I had to do as a workaround which is to define an internal model that extends the model that the user specified and decorate that leaving the user defined model untouched. As a framework you cannot make gratuitous assumptions about how a model is used and the meaning of it's attributes by arbitrarily injecting your own methods and attributes just because Javascript allows you to do that.

20 Dec 2013, 4:14 PM
This workaround is a pretty simple way to get around the problem of not polluting application specific classes with the NodeInterface decoration and therefore not impact performance.

Assuming the treepanel's store config specifies a model (say) A you could in the tree panel code define another model

and use __A__private as the store's model.

Of course there are a number of other cases to consider (what if the application passes in a store that's already instantiated etc). I'm not trying to solve the entire problem but to point out that there is a solution that doesn't compromise the performance problem described below.

I'm adding it to this thread with the hope that anyone else who runs into this issue will at least have an example workaround to get around this problem.

23 Dec 2013, 12:54 PM
I don't agree with the comment posted by the developer but I have added my own notes to this post in the hope that it will be useful for someone who encounters the same problem as I did. It's certainly Sencha's prerogative to decide which bugs are fixable are not - in this case, I think the problem is fixable but if you don't want to do it then the workaround will help.

7 May 2014, 10:28 AM
I realize this issue is closed but I completely missed this request for a fiddle. Here's a link to the fiddle I created to show the problem http://jsfiddle.net/krraghavan/2QUh3/.

I'm writing a blog article about this issue and am happy to pass the link if you need more descriptive details

7 May 2014, 1:12 PM
Where's your blog? Ext JS oriented?

7 May 2014, 1:38 PM
Yes it is. Here's the link - I thought I edited the post to include it but looks like I did not. In any case here it is https://krraghavan.wordpress.com/2014/05/07/extjs-4-2-treepanel-pollutes-reusable-models/