Jun 09, 2014, 2:35 PM
[OPEN] [#507] Feature request - support for Static Direct Methods in custom Components
Hi,
As far as I know (unless it has changed recently - and I just double checked my book to be sure!), Custom Components (e.g. subclass of TreePanel or GridPanel etc) can only have instance Direct Methods, not static ones.
If at all possible, it would be really useful. At least to me :)
A good example of this is a custom TreePanel we use - the tree loader is the same wherever we use it (whether we use it via a WebForms page, a user control, or from deep inside a composite custom control, or even from an MVC View, etc).
To avoid remembering to define a DirectMethod in many places, I currently define an ASHX as a nice/fast independent way to reuse the same loader regardless of where I use that custom TreePanel.
For clean code organization (and easier "bundling" of a custom component) it would be nice to put such a "static" Direct Method onto my custom TreePanel (or custom TreeLoader) itself.
It could even be possible to generate the Direct Method proxy as a prototype method on the JavaScript version of the Custom Control for us perhaps! (With your usual flexible options such as the option to call the client side method something else, etc.)
This helps to keep things together a bit more. Especially when this is extended to include other functionality such as Add, Delete, Reload etc. One ASHX for each is what I currently do, and that is just for one custom component. In our app we have many custom components each with their own set of ASHX's, so we have an explosion of ASHX's.
A static DirectMethod is slightly easier to unit test as well (though ASHX's are admittedly getting easier to unit test too)
By the way, if the proxies had to be in its own "direct" namespace in that client object, that might be quite neat too.
E.g if I had this:
What do you think?
As far as I know (unless it has changed recently - and I just double checked my book to be sure!), Custom Components (e.g. subclass of TreePanel or GridPanel etc) can only have instance Direct Methods, not static ones.
If at all possible, it would be really useful. At least to me :)
A good example of this is a custom TreePanel we use - the tree loader is the same wherever we use it (whether we use it via a WebForms page, a user control, or from deep inside a composite custom control, or even from an MVC View, etc).
To avoid remembering to define a DirectMethod in many places, I currently define an ASHX as a nice/fast independent way to reuse the same loader regardless of where I use that custom TreePanel.
For clean code organization (and easier "bundling" of a custom component) it would be nice to put such a "static" Direct Method onto my custom TreePanel (or custom TreeLoader) itself.
It could even be possible to generate the Direct Method proxy as a prototype method on the JavaScript version of the Custom Control for us perhaps! (With your usual flexible options such as the option to call the client side method something else, etc.)
This helps to keep things together a bit more. Especially when this is extended to include other functionality such as Add, Delete, Reload etc. One ASHX for each is what I currently do, and that is just for one custom component. In our app we have many custom components each with their own set of ASHX's, so we have an explosion of ASHX's.
A static DirectMethod is slightly easier to unit test as well (though ASHX's are admittedly getting easier to unit test too)
By the way, if the proxies had to be in its own "direct" namespace in that client object, that might be quite neat too.
E.g if I had this:
Ext.define('MyApp.CustomTreePanel', {
extend: 'Ext.tree.Tree',
etc...
});
It would be nice to to then have the method available either atMyApp.CustomTreePanel.MyDirectMethod
or (as that could cause collisions, or look odd because of the PascalCase)MyApp.CustomTreePanel.direct.MyDirectMethod
Then, if I have a tree instance, such as "this" or "myTree", I can simply do this.direct.MyDirectMethod({
success: function() {}
)
ormyTree.direct.MyDirectMethod({
success: function() {}
);
Having "direct" on the client side is a tiny bit of branding for you but also maybe a neat separation of concerns/intent on the client side api, so to speak...?What do you think?
Last edited by Daniil; Jun 10, 2014 at 2:59 PM.
Reason: [OPEN] [#507]