|
class mapping E4: Generate code for JavaScript superclass
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.
|
|
 Re: class mapping E4: Generate code for JavaScript superclass
Thanks for volunteering. http://bugs.directwebremoting.org/bugs/browse/DWR-263Joe. 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.
|
|
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.
Best regards
Mike
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.
|
|
Re: class mapping E4: Generate code for JavaScript superclass
impressive work Mike On Fri, Sep 12, 2008 at 6:08 PM, Mike Wilson <mikewse@...> wrote:
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.
Best regards
Mike
Thanks for volunteering. http://bugs.directwebremoting.org/bugs/browse/DWR-263Joe.
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.
|
|
Re: class mapping E4: Generate code for JavaScript superclass
Nice, thanks. I've removed the hack that makes the test for this pass, and the test still passes. Yeay. Joe. On Fri, Sep 12, 2008 at 5:08 PM, Mike Wilson <mikewse@...> wrote:
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.
Best regards
Mike
Thanks for volunteering. http://bugs.directwebremoting.org/bugs/browse/DWR-263Joe.
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.
|
