class mapping E11: Allow converter declaration include subclasses in class mapping

[mikewse]

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusion? F ex Person+ or Person...

 

Comments?

 

Best regards

Mike

 

Jose said:

 

Does F4 include inheritance? I mean something like:

          <converter type="bean" match="...AbstractClass" javascript="*">
                 <include method="id" />
          </converter>

         so all subclasses are automatically mapped

        <converter type="bean" match="...ConcreteClass">
               <exclude method="random" />
          </converter>

        and can be modified by other declarations?

 

Mike said:

 

No, F4 is just about setting up the inheritance relation between mapped classes in JavaScript, not saying that subclasses should also be mapped. Mapping subclasses is mentioned in the "pattern replacement" suggestion as one of the questions, so you have now provided feedback to that question :-). Specifying in dwr.xml could be done in many ways, including having a "matchsubclasses=true/false" attribute. 

[Joe Walker-3]

http://bugs.directwebremoting.org/bugs/browse/DWR-268

I concur with Mike that the prefix isn't very obvious. If we had something that appeared in the DTD, it would be far more discoverable.
<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true"/>

Joe.

On Fri, Jul 11, 2008 at 1:18 PM, Mike Wilson <mikewse@...> wrote:

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusion? F ex Person+ or Person...

 

Comments?

 

Best regards

Mike

 

Jose said:

 

Does F4 include inheritance? I mean something like:

          <converter type="bean" match="...AbstractClass" javascript="*">
                 <include method="id" />
          </converter>

         so all subclasses are automatically mapped

        <converter type="bean" match="...ConcreteClass">
               <exclude method="random" />
          </converter>

        and can be modified by other declarations?

 

Mike said:

 

No, F4 is just about setting up the inheritance relation between mapped classes in JavaScript, not saying that subclasses should also be mapped. Mapping subclasses is mentioned in the "pattern replacement" suggestion as one of the questions, so you have now provided feedback to that question :-). Specifying in dwr.xml could be done in many ways, including having a "matchsubclasses=true/false" attribute. 

[XMaNIaC]

I'm not sure because if the converter for the subclass is defined, it should inherit automatically everything from the superclass converter (which implies some kind of ordering or reevaluation). But if the converter for the subclass is missing we have a problem because the "includeSubclass" attribute does not really help to detect subclasses. Classpath scanning is not enough here as 1) the subclass can be in other package 2) we would need to inspect each match further (like Spring does)

Regards

On Fri, Jul 11, 2008 at 4:36 PM, Joe Walker <joe@...> wrote:

http://bugs.directwebremoting.org/bugs/browse/DWR-268

I concur with Mike that the prefix isn't very obvious. If we had something that appeared in the DTD, it would be far more discoverable.
<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true"/>

Joe.

On Fri, Jul 11, 2008 at 1:18 PM, Mike Wilson <mikewse@...> wrote:

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusion? F ex Person+ or Person...

 

Comments?

 

Best regards

Mike

 

Jose said:

 

Does F4 include inheritance? I mean something like:

          <converter type="bean" match="...AbstractClass" javascript="*">
                 <include method="id" />
          </converter>

         so all subclasses are automatically mapped

        <converter type="bean" match="...ConcreteClass">
               <exclude method="random" />
          </converter>

        and can be modified by other declarations?

 

Mike said:

 

No, F4 is just about setting up the inheritance relation between mapped classes in JavaScript, not saying that subclasses should also be mapped. Mapping subclasses is mentioned in the "pattern replacement" suggestion as one of the questions, so you have now provided feedback to that question :-). Specifying in dwr.xml could be done in many ways, including having a "matchsubclasses=true/false" attribute. 

[XMaNIaC]

For some reason (related to the fact that I was coding the classpath scanner) I was thinking in automatic discovering of classes which is irrelevant as at runtime the object hierarchy is available and can be traversed. So how will the conversion procedure work? Will it look through the hierarchy looking for matching converters and apply all of them them? Will it detect conflicts then? Will it allow include/exclude declarations on different converters? What about namespaces?

For example:

Programmer extends Employee extends Person

<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true">
    <include method="id,name" />
</converter>

<converter type="bean" match="mypkg.dto.Employee" javascript="*" namespace="java" includeSubClass="true">
   <include method="ssn" />
</converter>

<converter type="bean" match="otherpkg.dto.Programmer">
   <include method="expertise" />
   <exclude method="ssn" />
</converter>

On Sat, Jul 12, 2008 at 12:02 PM, Jose Noheda <jose.noheda@...> wrote:

I'm not sure because if the converter for the subclass is defined, it should inherit automatically everything from the superclass converter (which implies some kind of ordering or reevaluation). But if the converter for the subclass is missing we have a problem because the "includeSubclass" attribute does not really help to detect subclasses. Classpath scanning is not enough here as 1) the subclass can be in other package 2) we would need to inspect each match further (like Spring does)

Regards

On Fri, Jul 11, 2008 at 4:36 PM, Joe Walker <joe@...> wrote:

http://bugs.directwebremoting.org/bugs/browse/DWR-268

I concur with Mike that the prefix isn't very obvious. If we had something that appeared in the DTD, it would be far more discoverable.
<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true"/>

Joe.

On Fri, Jul 11, 2008 at 1:18 PM, Mike Wilson <mikewse@...> wrote:

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusion? F ex Person+ or Person...

 

Comments?

 

Best regards

Mike

 

Jose said:

 

Does F4 include inheritance? I mean something like:

          <converter type="bean" match="...AbstractClass" javascript="*">
                 <include method="id" />
          </converter>

         so all subclasses are automatically mapped

        <converter type="bean" match="...ConcreteClass">
               <exclude method="random" />
          </converter>

        and can be modified by other declarations?

 

Mike said:

 

No, F4 is just about setting up the inheritance relation between mapped classes in JavaScript, not saying that subclasses should also be mapped. Mapping subclasses is mentioned in the "pattern replacement" suggestion as one of the questions, so you have now provided feedback to that question :-). Specifying in dwr.xml could be done in many ways, including having a "matchsubclasses=true/false" attribute. 

[Joe Walker-3]

From a users point of view, I would expect that the simplest would be: DWR finds the best* converter for your class and uses the rules defined for that.
I'm not sure that there would be enough of a decrease in verbosity from having inheriting declarations in dwr.xml to offset the increase in complexity.
Is namespacing important when considering server rules? I'm not sure that the ideas conflict.

Joe.

On Sat, Jul 12, 2008 at 2:36 PM, Jose Noheda <jose.noheda@...> wrote:

For some reason (related to the fact that I was coding the classpath scanner) I was thinking in automatic discovering of classes which is irrelevant as at runtime the object hierarchy is available and can be traversed. So how will the conversion procedure work? Will it look through the hierarchy looking for matching converters and apply all of them them? Will it detect conflicts then? Will it allow include/exclude declarations on different converters? What about namespaces?

For example:

Programmer extends Employee extends Person

<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true">

    <include method="id,name" />
</converter>

<converter type="bean" match="mypkg.dto.Employee" javascript="*" namespace="java" includeSubClass="true">
   <include method="ssn" />
</converter>

<converter type="bean" match="otherpkg.dto.Programmer">
   <include method="expertise" />
   <exclude method="ssn" />
</converter>

On Sat, Jul 12, 2008 at 12:02 PM, Jose Noheda <jose.noheda@...> wrote:

I'm not sure because if the converter for the subclass is defined, it should inherit automatically everything from the superclass converter (which implies some kind of ordering or reevaluation). But if the converter for the subclass is missing we have a problem because the "includeSubclass" attribute does not really help to detect subclasses. Classpath scanning is not enough here as 1) the subclass can be in other package 2) we would need to inspect each match further (like Spring does)

Regards

On Fri, Jul 11, 2008 at 4:36 PM, Joe Walker <joe@...> wrote:

http://bugs.directwebremoting.org/bugs/browse/DWR-268

I concur with Mike that the prefix isn't very obvious. If we had something that appeared in the DTD, it would be far more discoverable.
<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true"/>

Joe.

On Fri, Jul 11, 2008 at 1:18 PM, Mike Wilson <mikewse@...> wrote:

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusion? F ex Person+ or Person...

 

Comments?

 

Best regards

Mike

 

Jose said:

 

Does F4 include inheritance? I mean something like:

          <converter type="bean" match="...AbstractClass" javascript="*">
                 <include method="id" />
          </converter>

         so all subclasses are automatically mapped

        <converter type="bean" match="...ConcreteClass">
               <exclude method="random" />
          </converter>

        and can be modified by other declarations?

 

Mike said:

 

No, F4 is just about setting up the inheritance relation between mapped classes in JavaScript, not saying that subclasses should also be mapped. Mapping subclasses is mentioned in the "pattern replacement" suggestion as one of the questions, so you have now provided feedback to that question :-). Specifying in dwr.xml could be done in many ways, including having a "matchsubclasses=true/false" attribute. 

[mikewse]

Jose, as you are the source for this suggestion you are very welcome to dig through these questions and try to find a coherent scheme.

 

The main use-case I would think of is one converter clause that says:

    "generate mapped classes for class X and all its subclasses"

 

The details for how conflicting converter clauses should behave can surely be worked out, but at this time I would rather discuss if the simple case above is feasible or not. Finding subclasses means inspecting the inheritance chain on every class in the JVM...

 

Note also that we need the list of all mapped classes as soon as we are generating an interface script, and this may be before these classes have been loaded by the JVM.

 

Best regards

Mike

---

From: Jose Noheda [mailto:jose.noheda@...]
Sent: den 12 juli 2008 15:37
To: users@...
Subject: Re: [dwr-user] class mapping E11: Allow converter declaration include subclasses in class mapping

For some reason (related to the fact that I was coding the classpath scanner) I was thinking in automatic discovering of classes which is irrelevant as at runtime the object hierarchy is available and can be traversed. So how will the conversion procedure work? Will it look through the hierarchy looking for matching converters and apply all of them them? Will it detect conflicts then? Will it allow include/exclude declarations on different converters? What about namespaces?

For example:

Programmer extends Employee extends Person

<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true">
    <include method="id,name" />
</converter>

<converter type="bean" match="mypkg.dto.Employee" javascript="*" namespace="java" includeSubClass="true">
   <include method="ssn" />
</converter>

<converter type="bean" match="otherpkg.dto.Programmer">
   <include method="expertise" />
   <exclude method="ssn" />
</converter>

On Sat, Jul 12, 2008 at 12:02 PM, Jose Noheda <jose.noheda@...> wrote:

I'm not sure because if the converter for the subclass is defined, it should inherit automatically everything from the superclass converter (which implies some kind of ordering or reevaluation). But if the converter for the subclass is missing we have a problem because the "includeSubclass" attribute does not really help to detect subclasses. Classpath scanning is not enough here as 1) the subclass can be in other package 2) we would need to inspect each match further (like Spring does)

Regards

On Fri, Jul 11, 2008 at 4:36 PM, Joe Walker <joe@...> wrote:

http://bugs.directwebremoting.org/bugs/browse/DWR-268

I concur with Mike that the prefix isn't very obvious. If we had something that appeared in the DTD, it would be far more discoverable.
<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true"/>

Joe.

On Fri, Jul 11, 2008 at 1:18 PM, Mike Wilson <mikewse@...> wrote:

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusion? F ex Person+ or Person...

 

Comments?

 

Best regards

Mike

 

Jose said:

 

Does F4 include inheritance? I mean something like:

          <converter type="bean" match="...AbstractClass" javascript="*">
                 <include method="id" />
          </converter>

         so all subclasses are automatically mapped

        <converter type="bean" match="...ConcreteClass">
               <exclude method="random" />
          </converter>

        and can be modified by other declarations?

 

Mike said:

 

No, F4 is just about setting up the inheritance relation between mapped classes in JavaScript, not saying that subclasses should also be mapped. Mapping subclasses is mentioned in the "pattern replacement" suggestion as one of the questions, so you have now provided feedback to that question :-). Specifying in dwr.xml could be done in many ways, including having a "matchsubclasses=true/false" attribute. 

[XMaNIaC]

On Sat, Jul 12, 2008 at 11:51 PM, Joe Walker <joe@...> wrote:

From a users point of view, I would expect that the simplest would be: DWR finds the best* converter for your class and uses the rules defined for that.
I'm not sure that there would be enough of a decrease in verbosity from having inheriting declarations in dwr.xml to offset the increase in complexity.
Is namespacing important when considering server rules? I'm not sure that the ideas conflict.

If we are just using one converter it's not. Otherwise there could be conflicts and we would need some kind of resolution rules.
 

Joe.

On Sat, Jul 12, 2008 at 2:36 PM, Jose Noheda <jose.noheda@...> wrote:

For some reason (related to the fact that I was coding the classpath scanner) I was thinking in automatic discovering of classes which is irrelevant as at runtime the object hierarchy is available and can be traversed. So how will the conversion procedure work? Will it look through the hierarchy looking for matching converters and apply all of them them? Will it detect conflicts then? Will it allow include/exclude declarations on different converters? What about namespaces?

For example:

Programmer extends Employee extends Person

<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true">

    <include method="id,name" />
</converter>

<converter type="bean" match="mypkg.dto.Employee" javascript="*" namespace="java" includeSubClass="true">
   <include method="ssn" />
</converter>

<converter type="bean" match="otherpkg.dto.Programmer">
   <include method="expertise" />
   <exclude method="ssn" />
</converter>

On Sat, Jul 12, 2008 at 12:02 PM, Jose Noheda <jose.noheda@...> wrote:

I'm not sure because if the converter for the subclass is defined, it should inherit automatically everything from the superclass converter (which implies some kind of ordering or reevaluation). But if the converter for the subclass is missing we have a problem because the "includeSubclass" attribute does not really help to detect subclasses. Classpath scanning is not enough here as 1) the subclass can be in other package 2) we would need to inspect each match further (like Spring does)

Regards

On Fri, Jul 11, 2008 at 4:36 PM, Joe Walker <joe@...> wrote:

http://bugs.directwebremoting.org/bugs/browse/DWR-268

I concur with Mike that the prefix isn't very obvious. If we had something that appeared in the DTD, it would be far more discoverable.
<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true"/>

Joe.

On Fri, Jul 11, 2008 at 1:18 PM, Mike Wilson <mikewse@...> wrote:

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusion? F ex Person+ or Person...

 

Comments?

 

Best regards

Mike

 

Jose said:

 

Does F4 include inheritance? I mean something like:

          <converter type="bean" match="...AbstractClass" javascript="*">
                 <include method="id" />
          </converter>

         so all subclasses are automatically mapped

        <converter type="bean" match="...ConcreteClass">
               <exclude method="random" />
          </converter>

        and can be modified by other declarations?

 

Mike said:

 

No, F4 is just about setting up the inheritance relation between mapped classes in JavaScript, not saying that subclasses should also be mapped. Mapping subclasses is mentioned in the "pattern replacement" suggestion as one of the questions, so you have now provided feedback to that question :-). Specifying in dwr.xml could be done in many ways, including having a "matchsubclasses=true/false" attribute. 

[XMaNIaC]

On Sat, Jul 12, 2008 at 11:53 PM, Mike Wilson <mikewse@...> wrote:

Jose, as you are the source for this suggestion you are very welcome to dig through these questions and try to find a coherent scheme.

 

The main use-case I would think of is one converter clause that says:

    "generate mapped classes for class X and all its subclasses"

So here is where we differ. When I proposed the feature I was thinking in declaring a hierarchy of converters and overriding properties (and mixing include/exclude rules). I didn't have in mind the possibility of doing class mappings for undeclared classes (not that is not useful). This proposal is completely different as means traversing the whole virtual machine and inspect, class by class, if that class is a subclass of a class for which a converter with the attribute includeSubClass was set.

 

The details for how conflicting converter clauses should behave can surely be worked out, but at this time I would rather discuss if the simple case above is feasible or not. Finding subclasses means inspecting the inheritance chain on every class in the JVM...

Yes, as a startup task..
 

 

Note also that we need the list of all mapped classes as soon as we are generating an interface script, and this may be before these classes have been loaded by the JVM.

 

It's similar to what Spring does (though the checks are slightly different) but setting base package as ""
 

Best regards

Mike

---

From: Jose Noheda [mailto:jose.noheda@...]
Sent: den 12 juli 2008 15:37
To: users@...
Subject: Re: [dwr-user] class mapping E11: Allow converter declaration include subclasses in class mapping

For some reason (related to the fact that I was coding the classpath scanner) I was thinking in automatic discovering of classes which is irrelevant as at runtime the object hierarchy is available and can be traversed. So how will the conversion procedure work? Will it look through the hierarchy looking for matching converters and apply all of them them? Will it detect conflicts then? Will it allow include/exclude declarations on different converters? What about namespaces?

For example:

Programmer extends Employee extends Person

<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true">
    <include method="id,name" />
</converter>

<converter type="bean" match="mypkg.dto.Employee" javascript="*" namespace="java" includeSubClass="true">
   <include method="ssn" />
</converter>

<converter type="bean" match="otherpkg.dto.Programmer">
   <include method="expertise" />
   <exclude method="ssn" />
</converter>

On Sat, Jul 12, 2008 at 12:02 PM, Jose Noheda <jose.noheda@...> wrote:

I'm not sure because if the converter for the subclass is defined, it should inherit automatically everything from the superclass converter (which implies some kind of ordering or reevaluation). But if the converter for the subclass is missing we have a problem because the "includeSubclass" attribute does not really help to detect subclasses. Classpath scanning is not enough here as 1) the subclass can be in other package 2) we would need to inspect each match further (like Spring does)

Regards

On Fri, Jul 11, 2008 at 4:36 PM, Joe Walker <joe@...> wrote:

http://bugs.directwebremoting.org/bugs/browse/DWR-268

I concur with Mike that the prefix isn't very obvious. If we had something that appeared in the DTD, it would be far more discoverable.
<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true"/>

Joe.

On Fri, Jul 11, 2008 at 1:18 PM, Mike Wilson <mikewse@...> wrote:

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusion? F ex Person+ or Person...

 

Comments?

 

Best regards

Mike

 

Jose said:

 

Does F4 include inheritance? I mean something like:

          <converter type="bean" match="...AbstractClass" javascript="*">
                 <include method="id" />
          </converter>

         so all subclasses are automatically mapped

        <converter type="bean" match="...ConcreteClass">
               <exclude method="random" />
          </converter>

        and can be modified by other declarations?

 

Mike said:

 

No, F4 is just about setting up the inheritance relation between mapped classes in JavaScript, not saying that subclasses should also be mapped. Mapping subclasses is mentioned in the "pattern replacement" suggestion as one of the questions, so you have now provided feedback to that question :-). Specifying in dwr.xml could be done in many ways, including having a "matchsubclasses=true/false" attribute. 

[mikewse]

Ok, there seem to have been a misunderstanding here. I suggest that this issue thread (E11) continues to discuss the "includeSubClasses" feature and that a new issue thread may be created for Jose's proposal.

 

So:

 

1) Should the "includeSubClasses" feature be dismissed on technical grounds or may we still source in algorithms from other projects that have succeeded in making "not-so-bad" implementations?

 

2) Jose: can you make a write-up about your proposal and post it as issue E15 ?

 

Best regards

Mike

---

From: Jose Noheda [mailto:jose.noheda@...]
Sent: den 13 juli 2008 11:29
To: users@...
Subject: Re: [dwr-user] class mapping E11: Allow converter declaration include subclasses in class mapping

On Sat, Jul 12, 2008 at 11:53 PM, Mike Wilson <mikewse@...> wrote:

Jose, as you are the source for this suggestion you are very welcome to dig through these questions and try to find a coherent scheme.

 

The main use-case I would think of is one converter clause that says:

    "generate mapped classes for class X and all its subclasses"

So here is where we differ. When I proposed the feature I was thinking in declaring a hierarchy of converters and overriding properties (and mixing include/exclude rules). I didn't have in mind the possibility of doing class mappings for undeclared classes (not that is not useful). This proposal is completely different as means traversing the whole virtual machine and inspect, class by class, if that class is a subclass of a class for which a converter with the attribute includeSubClass was set.

 

The details for how conflicting converter clauses should behave can surely be worked out, but at this time I would rather discuss if the simple case above is feasible or not. Finding subclasses means inspecting the inheritance chain on every class in the JVM...

Yes, as a startup task..
 

 

Note also that we need the list of all mapped classes as soon as we are generating an interface script, and this may be before these classes have been loaded by the JVM.

 

It's similar to what Spring does (though the checks are slightly different) but setting base package as ""
 

Best regards

Mike

---

From: Jose Noheda [mailto:jose.noheda@...]
Sent: den 12 juli 2008 15:37
To: users@...
Subject: Re: [dwr-user] class mapping E11: Allow converter declaration include subclasses in class mapping

For some reason (related to the fact that I was coding the classpath scanner) I was thinking in automatic discovering of classes which is irrelevant as at runtime the object hierarchy is available and can be traversed. So how will the conversion procedure work? Will it look through the hierarchy looking for matching converters and apply all of them them? Will it detect conflicts then? Will it allow include/exclude declarations on different converters? What about namespaces?

For example:

Programmer extends Employee extends Person

<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true">
    <include method="id,name" />
</converter>

<converter type="bean" match="mypkg.dto.Employee" javascript="*" namespace="java" includeSubClass="true">
   <include method="ssn" />
</converter>

<converter type="bean" match="otherpkg.dto.Programmer">
   <include method="expertise" />
   <exclude method="ssn" />
</converter>

On Sat, Jul 12, 2008 at 12:02 PM, Jose Noheda <jose.noheda@...> wrote:

I'm not sure because if the converter for the subclass is defined, it should inherit automatically everything from the superclass converter (which implies some kind of ordering or reevaluation). But if the converter for the subclass is missing we have a problem because the "includeSubclass" attribute does not really help to detect subclasses. Classpath scanning is not enough here as 1) the subclass can be in other package 2) we would need to inspect each match further (like Spring does)

Regards

On Fri, Jul 11, 2008 at 4:36 PM, Joe Walker <joe@...> wrote:

http://bugs.directwebremoting.org/bugs/browse/DWR-268

I concur with Mike that the prefix isn't very obvious. If we had something that appeared in the DTD, it would be far more discoverable.
<converter type="bean" match="mypkg.dto.Person" javascript="*" includeSubClass="true"/>

Joe.

On Fri, Jul 11, 2008 at 1:18 PM, Mike Wilson <mikewse@...> wrote:

Here's a mail thread for Jose's suggestion on including classes for mapping by subclass in addition to by wildcard (see initial discussion below).

 

I'm interpreting it as being able to say:

    <converter type="bean" match="...mypkg.dto.Person" javascript="*"/>

to mean that the |match| attribute should match Person and all its subclasses.

 

Maybe a suffix would be more natural for indicating subclass inclusio