Dec 31, 2011, 1:57 PM
[OPEN] [#128] Can problem of custom events/listeners needing new propery be overcome using Generics?
Hi,
I was reading this post: http://forums.ext.net/showthread.php?10401
I was having the same problem as the original poster of that thread, about how to expose custom listeners on the C# side, as it is quite nice and easy on the ExtJs side.
I saw these two comments, amongst others:
Looking at your code I was wondering, what if you used Generics to overcome this problem? In the case of TreePanel, I think it would mean something like this (untested and removed all the additional attributes just for clarity!):
As it stands, the above would create new problems:
These issues could be solved by doing the following steps:
1. Renaming TreePanel to something like TreePanelProvider:
3. Finally, for someone to write a custom tree control they could simply do this:
In effect, the above simply
I haven't looked at, or tried to modify my local copy of your source code to see if this works. Furthermore, I suspect it may be possible to somehow do this a lot further up the class hierarchy which means other panels could automatically also get the same benefits without them having to be duplicated into each class.
Don't know if that is a possibility? (I can imagine that even if it is a good solution it is not necessarily something that you can easily refactor overnight, depending on how your autogenerated code stuff works.)
I was reading this post: http://forums.ext.net/showthread.php?10401
I was having the same problem as the original poster of that thread, about how to expose custom listeners on the C# side, as it is quite nice and easy on the ExtJs side.
I saw these two comments, amongst others:
Originally Posted by Vladimir
Looking at your code I was wondering, what if you used Generics to overcome this problem? In the case of TreePanel, I think it would mean something like this (untested and removed all the additional attributes just for clarity!):
public partial class TreePanel<TListeners> : TreePanelBase, IAjaxPostBackEventHandler where TListeners : ComponentListeners, new()
{
... all your other code here ...
public TListeners Listeners
{
get
{
if (this.listeners == null)
{
this.listeners = new TListeners();
}
return this.listeners;
}
}
}
I suspect the same could be done for DirectEvents too if people wanted to add their own custom ones. In that case you would do something like this for the class definition:public partial class TreePanel<TListeners, TDirectEvents> : TreePanelBase, IAjaxPostBackEventHandler
where TListeners : ComponentListeners, new()
where TDirectEvents : ComponentDirectEvents, new()
{
... etc ...
public TListeners Listeners { ... }
... etc ...
public TDirectEvents DirectEvents { ... }
... etc ...
}
And the same could go for anything else.As it stands, the above would create new problems:
- How you could possibly use these in ASP.NET markup (due to syntax issues - a control can't be a generic itself I believe)
- Backward compatibility - even if this change is possible and desirable, it would break everyone.
- How could people extend the class
These issues could be solved by doing the following steps:
1. Renaming TreePanel to something like TreePanelProvider:
public partial class TreePanelProvider<TListeners, TDirectEvents> : TreePanelBase, IAjaxPostBackEventHandler
where TListeners : ComponentListeners, new()
where TDirectEvents : ComponentDirectEvents, new()
{
... etc ...
public TListeners Listeners { ... }
... etc ...
public TDirectEvents DirectEvents { ... }
... etc ...
}
2. Creating a new TreePanel class that does not use generics but can still be used by everyone, by simply having this:public class TreePanel : TreePanelProvider<TreePanelDirectListeners, TreePanelDirectEvents>
{
// note, no code needed here, as it is all moved into base class
// this class just becomes a convenience for ASP.NET to be able to support markup
}
(If my assumption that a class with a generic such as Example<T> cannot directly be used as a server control is wrong, you could just have TreePanel itself be TreePanel<TreePanelDirectListeners, TreePanelDirectEvents).3. Finally, for someone to write a custom tree control they could simply do this:
public class MyTreePanel : TreePanelProvider<MyCustomTreePanelDirectListeners, MyCustomTreePanelDirectEvents>
{
// note, no code needed here, as it is all moved into base class
// this class just becomes a convenience for ASP.NET to be able to support markup
}
(If developers don't need custom events, they can continue extending TreePanel itself.)In effect, the above simply
- Pushes all the code in TreePanel into a new parent/base class
- Lets the new parent continue inheriting from the previous parent, thus not breaking functionality
- Allows the remaining TreePanel to be preserved as almost like a "marker" class that can continue to work with ASP.NET markup and therefore preserve backward compatibility where people are already extending it.
- Lets developers create custom tree panels with custom events if needed as shown by Example 3 above (which is minimal and same as Example 2, except it uses different listeners/events). In other words, both your "out of the box" tree panel and developers' custom ones inherit TreePanelProvider, if custom events are needed.
- Lets developers to continue inheriting and extending TreePanel itself if they don't need their own events
I haven't looked at, or tried to modify my local copy of your source code to see if this works. Furthermore, I suspect it may be possible to somehow do this a lot further up the class hierarchy which means other panels could automatically also get the same benefits without them having to be duplicated into each class.
Don't know if that is a possibility? (I can imagine that even if it is a good solution it is not necessarily something that you can easily refactor overnight, depending on how your autogenerated code stuff works.)
Last edited by Daniil; Jan 18, 2013 at 4:23 AM.
Reason: [OPEN] [#128]