RE: class mapping E4: Generate code for JavaScript superclass

I have now checked in the implementation for this report:

 

When an object or bean conversion using class-mapping is initialized at DWR startup, there will also be a check performed to see if any superclass/interface of the class has been mapped. If so, DWR will automatically generate JavaScript code to set up an inheritance chain between these generated classes, in the classic form of:
    MySubClass.prototype = new MySuperClass();
    MySubClass.prototype.constructor = MySubClass;

 

Superclasses will be searched first, and if there is no match, interfaces will be searched starting with the class's own implemented interfaces and then stepping out to the closest superclass's interfaces, and so on. Note that for a superclass/interface to be considered, it's converter has to be added before the "subclass" converter.

---

From: joseph.walker@... [mailto:joseph.walker@...] On Behalf Of Joe Walker
Sent: den 11 juli 2008 10:54
To: users@...
Subject: Re: [dwr-user] class mapping E4: Generate code for JavaScript superclass

Thanks for volunteering.
http://bugs.directwebremoting.org/bugs/browse/DWR-263

Joe.

On Wed, Jul 9, 2008 at 9:59 PM, Mike Wilson <mikewse@...> wrote:

Ok, we can start with the first part of my suggestion and only implement a default behaviour that is not customizable, to avoid new settings in dwr.xml.

I can volunteer to do this.

Any other comments before I go ahead?

 

Best regards

Mike

Generate class mapping code for superclass

 

When mapping class hierarchies it is convenient to also map the inheritance between the classes, to be able to use instanceof in the natural way. That would add the marked (*) code to the generated class:

 

    if (typeof db.Employee != 'function') { 
        db.Employee = function() {
            this.myProp = <initial value>
            .
        }
    }

    db.Employee["$dwrclassname"] = "db.Employee";

    db.Employee["$dwrserverclassname"] = "mypkg.dto.Employee";

*  db.Employee.prototype = new db.Person;

*  db.Employee.prototype.constructor = db.Employee;

 

The JavaScript superclass may map against the class's actual superclass (concrete or abstract) or to any implemented interface. Then how should the superclass be selected if there are several such candidates? The default behaviour I'm thinking of is to try first with the class's superclass and after that all implemented interfaces, in the order returned by Java reflection. The first superclass/interface that has itself been set up for class mapping will be selected as JavaScript superclass for the class.

 

We could also let the developer specify what Java class or interface to use as JavaScript superclass (in case the class inherits/implements more than one class/interface) by introducing a new attribute:

 

    <converter type="bean" match="mypkg.dto.Person"

        javascript="db.Person"/>

    <converter type="bean" match="mypkg.dto.Employee"

        javascript="db.Employee" javascriptsuper="db.Person"/>

 

Here I am suggesting to use the JavaScript class name instead of the Java class name in the attribute, to enforce that superclasses are also mapped. But maybe it is better with the Java class name?

Joe said: 

I'm again going to argue that this is a nice idea, but that the last step could create complexity that we don't really benefit from. Perhaps we should export a parent/child into Javascript when both the parent and the child are separately exported.
 

 

Randy said:

While I'm not sure it's necessary I do see the case where this could be useful in representing some apis.