Inherit or Extend Ext.Net & Ext.Net.Mobile together, Namespace problem

  1. #1

    Inherit or Extend Ext.Net & Ext.Net.Mobile together, Namespace problem

    Hi all,
    We are using extended controls which inherited from Ext.Net on our Asp.Net Mvc project,
    and started to build mobile pages using Ext.Net.Mobile.

    We want to extend mobile controls too, to have same extra functionalities and ease of use,
    also we have some Extension methods for Ext.Net control classes
    but we had to do copy/paste and edit because Ext.Net and Ext.Net.Mobile controls have different namespaces and there is no common interface.

    Ext.Net.Button and Ext.Net.Mobile.Button have mostly common named properties but they are different classes in different namespaces.

    is it possible to have IButton interface (maybe on a common dll like Ext.Net.CommonInterfaces) and Button's properties and methods defined in it, after that Ext.Net.Button and Ext.Net.Mobile.Button derives from IButton...

    also have other Interfaces for other classes hierarchically, IPanel, IFormPanel, IGridPanel etc.
  2. #2
    Hello @unicorn64!

    We thought about that at some point, but it turned quite problematic as although seemingly most API matches, in several situations they can diverge even in the type of the property or method parameters so, if we had a common interface with what were common among them, the common part would mostly be very limited, requiring even for extensions to have their version here and there.

    But that's an interesting feedback from you. You been able to just copy and paste your extensions and they are providing what you needed with little to no changes?..

    Anyway, this makes sense, cause you are adding the functionality to a complete class. But the possible common interface -- in general terms -- would be so limited you'd probably be frustrated by it.

    For example, now you can just move over your extension and have your customizations in place. If there were a common interface with what's common between them, then you'll be missing the "not common" functionalities and will have to implement them in some way. So in the end you'd need to change your extensions even more than just copy and pasting!

    As an actual case just to exemplify, for example fields (from Ext.Net.Field) have no validation mechanisms on Mobile. If we could have a common interface between them then, it won't have validation and if you wanted to take advantage of the interfaces you'll have still to make a specific Ext.NET implementation to bring in the validation so, it would not be a drop-in replacement.

    We thought then that this would bring more problems than solutions and decided on splitting the namespace. This may cease to be the truth in the future, as we're seeing more and more Ext.NET components getting to Ext.NET Mobile as ExtJS modern toolkit evolves over time but, by the time it had to be born, that was far from equal. It still is not in the next upcoming release but we can see -- if they keep their pace -- the trends of becoming compatible and code reusability between them becoming more and more abundant.

    I hope these shared thoughts helps you understand why the namespaces are different. In the end, we even made different namespace to at least avoid conflicts for people trying to merge the two libraries in a same project.

    Although we can't support it, we did what was feasible to allow that if one really wanted to try and run both Ext.NET and Ext.NET mobile in the same project. And we got some positive reports about that, and it looks like it is your case too, right?
    Fabrício Murta
    Developer & Support Expert
  3. #3
    Hi @fabricio.murta,
    Thanks for your answer and explanations.

    I realized that there are differences on Ext.Net and Ext.Net.Mobile and some of them are big differences,
    Some controls not exist on mobile, some functions doesnt exist yet, some fuctionalities changed etc,

    But if we look at the subject in terms of OOP, Ext.Net.Field and Ext.Net.Mobile.Field are classes which have mostly common properties and methods. And if i want to add a method (which has codes exactly same on both classes) i have to write 2 extension methods to have same functionality on both classes.

    if Ext.Net.Field and Ext.Net.Mobile.Field are derived from an IField interface (IField could has only common methods and properties, also could be an empty interface too) i can do this only extend IField interface.
    Even more, Ext.Net.Mobile.Field could be derived from IMobileField - which derived from IField - we can check if control is mobile or not

    interface IField
    // really common methods and properties
    interface IClassicField:IField
    // classic spesific methods and properties
    interface IMobileField:IField
    // mobile spesific methods and properties
    public class Ext.Net.Field:IClassicField
    public class Ext.Net.Mobile.Field:IMobileField
    public static class FieldExtensions
       public static AnyExtensionMethod(this IField _this)
          // do common things
          if (_this is IMobileField)
             // do mobile spesific things
          else if (_this is IClassicField)
             // do classic field spesific things
  4. #4
    Hello @unicorn64

    Well, that's not really going to help at all using interfaces, as the interfaces' methods and properties would have to be re-implemented by the user anyway.

    C# Interfaces helps ensuring you implement whats required for a given component, thus you would instead need to re-implement the whole button's functionality which I believe would be much much more code, unfortunately C# does not allow multiple class inheritance -- what is vastly used in ExtJS and been a challenge all-time with Ext.NET development.

    In the end, if using interfaces, you would have to copy paste the whole button again in order to extend it, instead of inheriting what it has and extending it. Well, keeping in mind Ext.NET must be backwards compatible with C# prior to revision 6 -- which I think also didn't improve this limitation.

    Well, I could be a little outdated on the subject, looking forward for your thoughts about rewriting base code on your extensions in order to implement the interfaces.

    No matter what, we took a design decision while putting Ext.NET Mobile together: no project sharing between they both, as it would mean a very high risk of delaying the project considerably and introducing serious issues on the classic Ext.NET which was already working. The refactoring would be just too huge and the regression issues too many to explain the effort. Aside of the disadvantage of using interfaces.
    Fabrício Murta
    Developer & Support Expert
  5. #5
    thanks @fabricio.murta

    it may be required that controls classes must be in seperated namespaces,
    but if at least the utility classes which used in internal process and has the same properties and methods were in a common place.

    ConfigOption, JSON, ComponentListener and even more are same classes which control classes internally use or has property of them.

    Whatever, Life goes on in a way,
    thanks for giving this impressive framework to us ;)

Similar Threads

  1. [CLOSED] There are problem with mobile browsers?
    By dlanza in forum 4.x Legacy Premium Help
    Replies: 1
    Last Post: Jan 31, 2017, 2:38 PM
  2. Replies: 9
    Last Post: Jan 14, 2017, 9:35 PM
  3. [CLOSED] Mobile / Button problem
    By ebeker in forum 3.x Legacy Premium Help
    Replies: 9
    Last Post: Feb 05, 2015, 10:27 PM
  4. Inherit Coolite ScriptManager
    By kowi in forum 1.x Help
    Replies: 3
    Last Post: Nov 12, 2009, 6:56 PM
  5. [CLOSED] problem with old Namespace Example
    By pkellner in forum 1.x Legacy Premium Help
    Replies: 4
    Last Post: Nov 14, 2008, 6:37 PM

Tags for this Thread

Posting Permissions