Changes to Exclusions / Inclusions

[Kyle Pinette]

Hey Everyone,

I've been using DWR for an intranet site I'm building for my company.  One thing I've run into that would be nice to have is the idea of nested inclusions / exclusions.  See http://bugs.directwebremoting.org/bugs/browse/DWR-398.  Essentially, depending on where the object is nested, allow certain inclusions / exclusions.  This will allow the developer to choose what level of detail they want for the objects returned from the server, depending on where they exist in the object tree.  This would be especially helpful with Hibernate.  Hibernate makes it so easy to create relationships between all of your objects.  Depending on what operations you are performing, you may want only a certain level of detail.  There is no way to control this directly currently.  I am digging through the DWR source now, to re-familiarize myself (I was familiar with 2.0).  I'd like to implement a solution for this problem, but wanted to get some opinions first.

Thanks!

Kyle Pinette

[davidmarginian]

Thanks Kyle.  Perhaps I am complicating things here but I think any
solution needs to not just account for nested inclusion/exlusions but
also some way to specify converters for for the same class that can be
used in situations.  For example a common issue I have encountered is
displaying summary data in some instances and the full object in
others.  Currently there is no way to do this without creating a wrapper
and specifying another converter for the wrapper.

Kyle Pinette wrote:

> Hey Everyone,
>
> I've been using DWR for an intranet site I'm building for my company.  
> One thing I've run into that would be nice to have is the idea of
> nested inclusions / exclusions.  See
> http://bugs.directwebremoting.org/bugs/browse/DWR-398.  Essentially,
> depending on where the object is nested, allow certain inclusions /
> exclusions.  This will allow the developer to choose what level of
> detail they want for the objects returned from the server, depending
> on where they exist in the object tree.  This would be especially
> helpful with Hibernate.  Hibernate makes it so easy to create
> relationships between all of your objects.  Depending on what
> operations you are performing, you may want only a certain level of
> detail.  There is no way to control this directly currently.  I am
> digging through the DWR source now, to re-familiarize myself (I was
> familiar with 2.0).  I'd like to implement a solution for this
> problem, but wanted to get some opinions first.
>
> Thanks!
>
> Kyle Pinette

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kyle Pinette]

Could you provide some sort of example case?  Are you saying not just depending on where the object is nested?  For instance, when you call the server you could pass some sort of parameter specifying whether you want the full object or if you want a trimmed down version.  Is this what you're talking about?  What immediately jumps to mind is providing a configuration where you could define "skeletons" that could be named, and when you make a call to the server side, specify which "skeleton" you want to use.

Kyle Pinette

On Wed, Jul 8, 2009 at 9:29 PM, David Marginian <david@...> wrote:

Thanks Kyle.  Perhaps I am complicating things here but I think any solution needs to not just account for nested inclusion/exlusions but also some way to specify converters for for the same class that can be used in situations.  For example a common issue I have encountered is displaying summary data in some instances and the full object in others.  Currently there is no way to do this without creating a wrapper and specifying another converter for the wrapper.

Kyle Pinette wrote:

Hey Everyone,

I've been using DWR for an intranet site I'm building for my company.  One thing I've run into that would be nice to have is the idea of nested inclusions / exclusions.  See http://bugs.directwebremoting.org/bugs/browse/DWR-398.  Essentially, depending on where the object is nested, allow certain inclusions / exclusions.  This will allow the developer to choose what level of detail they want for the objects returned from the server, depending on where they exist in the object tree.  This would be especially helpful with Hibernate.  Hibernate makes it so easy to create relationships between all of your objects.  Depending on what operations you are performing, you may want only a certain level of detail.  There is no way to control this directly currently.  I am digging through the DWR source now, to re-familiarize myself (I was familiar with 2.0).  I'd like to implement a solution for this problem, but wanted to get some opinions first.

Thanks!

Kyle Pinette

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[davidmarginian]

Yes, I think you are following me, and I think I am being thick :).  
This is probably not as common of a problem as I originally thought, and
I am not sure if we need to support it (as I it will most likely
complicate things a great deal).  I encounter it because I work with a
framework at work (I'll spare you the details) that can at times
generate classes with a ton of fields.  In most cases I only want to
serialize a few of the fields, in others I need to display everything.  
I think the nested inclusion/exlusion feature will solve most of the
problems.

Kyle Pinette wrote:

> Could you provide some sort of example case?  Are you saying not just
> depending on where the object is nested?  For instance, when you call
> the server you could pass some sort of parameter specifying whether
> you want the full object or if you want a trimmed down version.  Is
> this what you're talking about?  What immediately jumps to mind is
> providing a configuration where you could define "skeletons" that
> could be named, and when you make a call to the server side, specify
> which "skeleton" you want to use.
>
> Kyle Pinette
>
>
> On Wed, Jul 8, 2009 at 9:29 PM, David Marginian <david@...
> <mailto:david@...>> wrote:
>
>     Thanks Kyle.  Perhaps I am complicating things here but I think
>     any solution needs to not just account for nested
>     inclusion/exlusions but also some way to specify converters for
>     for the same class that can be used in situations.  For example a
>     common issue I have encountered is displaying summary data in some
>     instances and the full object in others.  Currently there is no
>     way to do this without creating a wrapper and specifying another
>     converter for the wrapper.
>     Kyle Pinette wrote:
>
>         Hey Everyone,
>
>         I've been using DWR for an intranet site I'm building for my
>         company.  One thing I've run into that would be nice to have
>         is the idea of nested inclusions / exclusions.  See
>         http://bugs.directwebremoting.org/bugs/browse/DWR-398.
>          Essentially, depending on where the object is nested, allow
>         certain inclusions / exclusions.  This will allow the
>         developer to choose what level of detail they want for the
>         objects returned from the server, depending on where they
>         exist in the object tree.  This would be especially helpful
>         with Hibernate.  Hibernate makes it so easy to create
>         relationships between all of your objects.  Depending on what
>         operations you are performing, you may want only a certain
>         level of detail.  There is no way to control this directly
>         currently.  I am digging through the DWR source now, to
>         re-familiarize myself (I was familiar with 2.0).  I'd like to
>         implement a solution for this problem, but wanted to get some
>         opinions first.
>
>         Thanks!
>
>         Kyle Pinette
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@...
>     <mailto:dev-unsubscribe@...>
>     For additional commands, e-mail: dev-help@...
>     <mailto:dev-help@...>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kyle Pinette]

After having thought through your idea, I think it would be pretty useful.  For instance, suppose we built it so that you could define different "skeletons", and also define a default.  Most people would probably only define a default, but there is the option of defining others.  I envision being able to do something like this:

<convert converter="h3" match="some.package.User">

<layout default="true">

<property name="login" />
<property name="fullName" />

</layout>
<layout name="full">

<property name="login" />
<property name="fullName" />
<property name="addresses">

<property name="address1" />
<property name="city" />
<property name="state" />

</property>

</layout>

</convert>

Something like that would be pretty useful I think.  It takes care of nested inclusions / exclusions (although my example shows inclusions), and allows you to define different layouts for the object.

Kyle Pinette

On Wed, Jul 8, 2009 at 10:00 PM, David Marginian <david@...> wrote:

Yes, I think you are following me, and I think I am being thick :).  This is probably not as common of a problem as I originally thought, and I am not sure if we need to support it (as I it will most likely complicate things a great deal).  I encounter it because I work with a framework at work (I'll spare you the details) that can at times generate classes with a ton of fields.  In most cases I only want to serialize a few of the fields, in others I need to display everything.  I think the nested inclusion/exlusion feature will solve most of the problems.

Kyle Pinette wrote:

Could you provide some sort of example case?  Are you saying not just depending on where the object is nested?  For instance, when you call the server you could pass some sort of parameter specifying whether you want the full object or if you want a trimmed down version.  Is this what you're talking about?  What immediately jumps to mind is providing a configuration where you could define "skeletons" that could be named, and when you make a call to the server side, specify which "skeleton" you want to use.

Kyle Pinette

On Wed, Jul 8, 2009 at 9:29 PM, David Marginian <david@... <mailto:david@...>> wrote:

   Thanks Kyle.  Perhaps I am complicating things here but I think
   any solution needs to not just account for nested
   inclusion/exlusions but also some way to specify converters for
   for the same class that can be used in situations.  For example a
   common issue I have encountered is displaying summary data in some
   instances and the full object in others.  Currently there is no
   way to do this without creating a wrapper and specifying another
   converter for the wrapper.
   Kyle Pinette wrote:

       Hey Everyone,

       I've been using DWR for an intranet site I'm building for my
       company.  One thing I've run into that would be nice to have
       is the idea of nested inclusions / exclusions.  See
       http://bugs.directwebremoting.org/bugs/browse/DWR-398.
        Essentially, depending on where the object is nested, allow
       certain inclusions / exclusions.  This will allow the
       developer to choose what level of detail they want for the
       objects returned from the server, depending on where they
       exist in the object tree.  This would be especially helpful
       with Hibernate.  Hibernate makes it so easy to create
       relationships between all of your objects.  Depending on what
       operations you are performing, you may want only a certain
       level of detail.  There is no way to control this directly
       currently.  I am digging through the DWR source now, to
       re-familiarize myself (I was familiar with 2.0).  I'd like to
       implement a solution for this problem, but wanted to get some
       opinions first.

       Thanks!

       Kyle Pinette



   ---------------------------------------------------------------------
   To unsubscribe, e-mail: dev-unsubscribe@...

   <mailto:dev-unsubscribe@...>

   For additional commands, e-mail: dev-help@...

   <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[davidmarginian]

As Mike mentioned on the Jira issue, we have to be careful here -
dwr.xml is not the only game in town when it comes to configuration
(Spring, annotations, guice, etc. etc.).  On the surface this seems to
be a pretty large change which involve a lot of work.  How do you plan
on specifying which layout to use?  Couldn't the same thing be
accomplished by simply giving the converter a name - e.g.:

<convert converter="h3" name="full" match="some.package.User"/>
<convert converter="h3" name="summary" match="some.package.User"/>

Of course we would have to add the nested inclusion (per your original
email - include="field.nestedField") but this would allow us to keep a
configuration that is very close to what we have now.

Kyle Pinette wrote:

> After having thought through your idea, I think it would be pretty
> useful.  For instance, suppose we built it so that you could define
> different "skeletons", and also define a default.  Most people would
> probably only define a default, but there is the option of defining
> others.  I envision being able to do something like this:
>
> <convert converter="h3" match="some.package.User">
> <layout default="true">
> <property name="login" />
> <property name="fullName" />
> </layout>
> <layout name="full">
> <property name="login" />
> <property name="fullName" />
> <property name="addresses">
> <property name="address1" />
> <property name="city" />
> <property name="state" />
> </property>
> </layout>
> </convert>
>
> Something like that would be pretty useful I think.  It takes care of
> nested inclusions / exclusions (although my example shows inclusions),
> and allows you to define different layouts for the object.
>
> Kyle Pinette
>
>
> On Wed, Jul 8, 2009 at 10:00 PM, David Marginian <david@...
> <mailto:david@...>> wrote:
>
>     Yes, I think you are following me, and I think I am being thick
>     :).  This is probably not as common of a problem as I originally
>     thought, and I am not sure if we need to support it (as I it will
>     most likely complicate things a great deal).  I encounter it
>     because I work with a framework at work (I'll spare you the
>     details) that can at times generate classes with a ton of fields.
>      In most cases I only want to serialize a few of the fields, in
>     others I need to display everything.  I think the nested
>     inclusion/exlusion feature will solve most of the problems.
>
>     Kyle Pinette wrote:
>
>         Could you provide some sort of example case?  Are you saying
>         not just depending on where the object is nested?  For
>         instance, when you call the server you could pass some sort of
>         parameter specifying whether you want the full object or if
>         you want a trimmed down version.  Is this what you're talking
>         about?  What immediately jumps to mind is providing a
>         configuration where you could define "skeletons" that could be
>         named, and when you make a call to the server side, specify
>         which "skeleton" you want to use.
>
>         Kyle Pinette
>
>
>         On Wed, Jul 8, 2009 at 9:29 PM, David Marginian
>         <david@... <mailto:david@...>
>         <mailto:david@... <mailto:david@...>>> wrote:
>
>            Thanks Kyle.  Perhaps I am complicating things here but I think
>            any solution needs to not just account for nested
>            inclusion/exlusions but also some way to specify converters for
>            for the same class that can be used in situations.  For
>         example a
>            common issue I have encountered is displaying summary data
>         in some
>            instances and the full object in others.  Currently there is no
>            way to do this without creating a wrapper and specifying
>         another
>            converter for the wrapper.
>            Kyle Pinette wrote:
>
>                Hey Everyone,
>
>                I've been using DWR for an intranet site I'm building
>         for my
>                company.  One thing I've run into that would be nice to
>         have
>                is the idea of nested inclusions / exclusions.  See
>                http://bugs.directwebremoting.org/bugs/browse/DWR-398.
>                 Essentially, depending on where the object is nested,
>         allow
>                certain inclusions / exclusions.  This will allow the
>                developer to choose what level of detail they want for the
>                objects returned from the server, depending on where they
>                exist in the object tree.  This would be especially helpful
>                with Hibernate.  Hibernate makes it so easy to create
>                relationships between all of your objects.  Depending
>         on what
>                operations you are performing, you may want only a certain
>                level of detail.  There is no way to control this directly
>                currently.  I am digging through the DWR source now, to
>                re-familiarize myself (I was familiar with 2.0).  I'd
>         like to
>                implement a solution for this problem, but wanted to
>         get some
>                opinions first.
>
>                Thanks!
>
>                Kyle Pinette
>
>
>
>          
>          ---------------------------------------------------------------------
>            To unsubscribe, e-mail: dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>            <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>
>            For additional commands, e-mail: dev-help@...
>         <mailto:dev-help@...>
>            <mailto:dev-help@...
>         <mailto:dev-help@...>>
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@...
>     <mailto:dev-unsubscribe@...>
>     For additional commands, e-mail: dev-help@...
>     <mailto:dev-help@...>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kyle Pinette]

I completely understand that there are other configuration mechanisms.  I was just using dwr.xml as an example.  Yeah, it probably would be best to keep the configuration as similar as possible to what exists today.  I am going to take a look at the underlying configuration, and figure out how we would implement this.  Once I have a better understanding of how the configuration works, I'll present my ideas.

Kyle Pinette

On Wed, Jul 8, 2009 at 11:00 PM, David Marginian <david@...> wrote:

As Mike mentioned on the Jira issue, we have to be careful here - dwr.xml is not the only game in town when it comes to configuration (Spring, annotations, guice, etc. etc.).  On the surface this seems to be a pretty large change which involve a lot of work.  How do you plan on specifying which layout to use?  Couldn't the same thing be accomplished by simply giving the converter a name - e.g.:

<convert converter="h3" name="full" match="some.package.User"/>
<convert converter="h3" name="summary" match="some.package.User"/>

Of course we would have to add the nested inclusion (per your original email - include="field.nestedField") but this would allow us to keep a configuration that is very close to what we have now.

Kyle Pinette wrote:

After having thought through your idea, I think it would be pretty useful.  For instance, suppose we built it so that you could define different "skeletons", and also define a default.  Most people would probably only define a default, but there is the option of defining others.  I envision being able to do something like this:

<convert converter="h3" match="some.package.User">
<layout default="true">
<property name="login" />
<property name="fullName" />
</layout>
<layout name="full">
<property name="login" />
<property name="fullName" />
<property name="addresses">
<property name="address1" />
<property name="city" />
<property name="state" />
</property>
</layout>
</convert>

Something like that would be pretty useful I think.  It takes care of nested inclusions / exclusions (although my example shows inclusions), and allows you to define different layouts for the object.

Kyle Pinette

On Wed, Jul 8, 2009 at 10:00 PM, David Marginian <david@... <mailto:david@...>> wrote:

   Yes, I think you are following me, and I think I am being thick
   :).  This is probably not as common of a problem as I originally
   thought, and I am not sure if we need to support it (as I it will
   most likely complicate things a great deal).  I encounter it
   because I work with a framework at work (I'll spare you the
   details) that can at times generate classes with a ton of fields.
    In most cases I only want to serialize a few of the fields, in
   others I need to display everything.  I think the nested
   inclusion/exlusion feature will solve most of the problems.

   Kyle Pinette wrote:

       Could you provide some sort of example case?  Are you saying
       not just depending on where the object is nested?  For
       instance, when you call the server you could pass some sort of
       parameter specifying whether you want the full object or if
       you want a trimmed down version.  Is this what you're talking
       about?  What immediately jumps to mind is providing a
       configuration where you could define "skeletons" that could be
       named, and when you make a call to the server side, specify
       which "skeleton" you want to use.

       Kyle Pinette


       On Wed, Jul 8, 2009 at 9:29 PM, David Marginian
       <david@... <mailto:david@...>

       <mailto:david@... <mailto:david@...>>> wrote:

          Thanks Kyle.  Perhaps I am complicating things here but I think
          any solution needs to not just account for nested
          inclusion/exlusions but also some way to specify converters for
          for the same class that can be used in situations.  For
       example a
          common issue I have encountered is displaying summary data
       in some
          instances and the full object in others.  Currently there is no
          way to do this without creating a wrapper and specifying
       another
          converter for the wrapper.
          Kyle Pinette wrote:

              Hey Everyone,

              I've been using DWR for an intranet site I'm building
       for my
              company.  One thing I've run into that would be nice to
       have
              is the idea of nested inclusions / exclusions.  See
              http://bugs.directwebremoting.org/bugs/browse/DWR-398.
               Essentially, depending on where the object is nested,
       allow
              certain inclusions / exclusions.  This will allow the
              developer to choose what level of detail they want for the
              objects returned from the server, depending on where they
              exist in the object tree.  This would be especially helpful
              with Hibernate.  Hibernate makes it so easy to create
              relationships between all of your objects.  Depending
       on what
              operations you are performing, you may want only a certain
              level of detail.  There is no way to control this directly
              currently.  I am digging through the DWR source now, to
              re-familiarize myself (I was familiar with 2.0).  I'd
       like to
              implement a solution for this problem, but wanted to
       get some
              opinions first.

              Thanks!

              Kyle Pinette



                ---------------------------------------------------------------------
          To unsubscribe, e-mail: dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
          <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>

          For additional commands, e-mail: dev-help@...
       <mailto:dev-help@...>
          <mailto:dev-help@...
       <mailto:dev-help@...>>




   ---------------------------------------------------------------------
   To unsubscribe, e-mail: dev-unsubscribe@...
   <mailto:dev-unsubscribe@...>
   For additional commands, e-mail: dev-help@...
   <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mikewse]

There may be some previous thinking done in this area. Lance or Randy: didn't one of you suggest some mechanism for specifying a different set of included data properties when a class is sent through a specific method? And Jose: I remember some suggestion of yours about controlling the set of included data properties in class hierarchies?

 

Anyway Kyle, I think your suggestion should include the following:

• a data structure for how to store converters setups and overrides
• an algorithm for how to navigate and make decisions from the data structure
• handling of cases where a creator wants specific control (override) over a certain converted class
• handling of cases where a converter wants specific control (override) over a certain member's converted class (possibly several levels down in the member graph)

Best regards

Mike

---

From: Kyle Pinette [mailto:sowelie@...]
Sent: den 9 juli 2009 14:26
To: dev@...
Subject: Re: [dwr-dev] Changes to Exclusions / Inclusions

I completely understand that there are other configuration mechanisms.  I was just using dwr.xml as an example.  Yeah, it probably would be best to keep the configuration as similar as possible to what exists today.  I am going to take a look at the underlying configuration, and figure out how we would implement this.  Once I have a better understanding of how the configuration works, I'll present my ideas.

Kyle Pinette

On Wed, Jul 8, 2009 at 11:00 PM, David Marginian <david@...> wrote:

As Mike mentioned on the Jira issue, we have to be careful here - dwr.xml is not the only game in town when it comes to configuration (Spring, annotations, guice, etc. etc.).  On the surface this seems to be a pretty large change which involve a lot of work.  How do you plan on specifying which layout to use?  Couldn't the same thing be accomplished by simply giving the converter a name - e.g.:

<convert converter="h3" name="full" match="some.package.User"/>
<convert converter="h3" name="summary" match="some.package.User"/>

Of course we would have to add the nested inclusion (per your original email - include="field.nestedField") but this would allow us to keep a configuration that is very close to what we have now.

Kyle Pinette wrote:

After having thought through your idea, I think it would be pretty useful.  For instance, suppose we built it so that you could define different "skeletons", and also define a default.  Most people would probably only define a default, but there is the option of defining others.  I envision being able to do something like this:

<convert converter="h3" match="some.package.User">
<layout default="true">
<property name="login" />
<property name="fullName" />
</layout>
<layout name="full">
<property name="login" />
<property name="fullName" />
<property name="addresses">
<property name="address1" />
<property name="city" />
<property name="state" />
</property>
</layout>
</convert>

Something like that would be pretty useful I think.  It takes care of nested inclusions / exclusions (although my example shows inclusions), and allows you to define different layouts for the object.

Kyle Pinette

On Wed, Jul 8, 2009 at 10:00 PM, David Marginian <david@... <mailto:david@...>> wrote:

   Yes, I think you are following me, and I think I am being thick
   :).  This is probably not as common of a problem as I originally
   thought, and I am not sure if we need to support it (as I it will
   most likely complicate things a great deal).  I encounter it
   because I work with a framework at work (I'll spare you the
   details) that can at times generate classes with a ton of fields.
    In most cases I only want to serialize a few of the fields, in
   others I need to display everything.  I think the nested
   inclusion/exlusion feature will solve most of the problems.

   Kyle Pinette wrote:

       Could you provide some sort of example case?  Are you saying
       not just depending on where the object is nested?  For
       instance, when you call the server you could pass some sort of
       parameter specifying whether you want the full object or if
       you want a trimmed down version.  Is this what you're talking
       about?  What immediately jumps to mind is providing a
       configuration where you could define "skeletons" that could be
       named, and when you make a call to the server side, specify
       which "skeleton" you want to use.

       Kyle Pinette


       On Wed, Jul 8, 2009 at 9:29 PM, David Marginian
       <david@... <mailto:david@...>

       <mailto:david@... <mailto:david@...>>> wrote:

          Thanks Kyle.  Perhaps I am complicating things here but I think
          any solution needs to not just account for nested
          inclusion/exlusions but also some way to specify converters for
          for the same class that can be used in situations.  For
       example a
          common issue I have encountered is displaying summary data
       in some
          instances and the full object in others.  Currently there is no
          way to do this without creating a wrapper and specifying
       another
          converter for the wrapper.
          Kyle Pinette wrote:

              Hey Everyone,

              I've been using DWR for an intranet site I'm building
       for my
              company.  One thing I've run into that would be nice to
       have
              is the idea of nested inclusions / exclusions.  See
              http://bugs.directwebremoting.org/bugs/browse/DWR-398.
               Essentially, depending on where the object is nested,
       allow
              certain inclusions / exclusions.  This will allow the
              developer to choose what level of detail they want for the
              objects returned from the server, depending on where they
              exist in the object tree.  This would be especially helpful
              with Hibernate.  Hibernate makes it so easy to create
              relationships between all of your objects.  Depending
       on what
              operations you are performing, you may want only a certain
              level of detail.  There is no way to control this directly
              currently.  I am digging through the DWR source now, to
              re-familiarize myself (I was familiar with 2.0).  I'd
       like to
              implement a solution for this problem, but wanted to
       get some
              opinions first.

              Thanks!

              Kyle Pinette



                ---------------------------------------------------------------------
          To unsubscribe, e-mail: dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
          <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>

          For additional commands, e-mail: dev-help@...
       <mailto:dev-help@...>
          <mailto:dev-help@...
       <mailto:dev-help@...>>




   ---------------------------------------------------------------------
   To unsubscribe, e-mail: dev-unsubscribe@...
   <mailto:dev-unsubscribe@...>
   For additional commands, e-mail: dev-help@...
   <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kyle Pinette]

That sounds good.  I am going to be looking at the current code and coming up with some ideas tonight.

Kyle Pinette

---------- Forwarded message ----------
From: Mike Wilson <mikewse@...>
Date: Tue, Jul 21, 2009 at 8:23 PM
Subject: RE: [dwr-dev] Changes to Exclusions / Inclusions
To: dev@...

There may be some previous thinking done in this area. Lance or Randy: didn't one of you suggest some mechanism for specifying a different set of included data properties when a class is sent through a specific method? And Jose: I remember some suggestion of yours about controlling the set of included data properties in class hierarchies?

 

Anyway Kyle, I think your suggestion should include the following:

• a data structure for how to store converters setups and overrides
• an algorithm for how to navigate and make decisions from the data structure
• handling of cases where a creator wants specific control (override) over a certain converted class
• handling of cases where a converter wants specific control (override) over a certain member's converted class (possibly several levels down in the member graph)

Best regards

Mike

---

From: Kyle Pinette [mailto:sowelie@...]
Sent: den 9 juli 2009 14:26
To: dev@...
Subject: Re: [dwr-dev] Changes to Exclusions / Inclusions

I completely understand that there are other configuration mechanisms.  I was just using dwr.xml as an example.  Yeah, it probably would be best to keep the configuration as similar as possible to what exists today.  I am going to take a look at the underlying configuration, and figure out how we would implement this.  Once I have a better understanding of how the configuration works, I'll present my ideas.

Kyle Pinette

On Wed, Jul 8, 2009 at 11:00 PM, David Marginian <david@...> wrote:

As Mike mentioned on the Jira issue, we have to be careful here - dwr.xml is not the only game in town when it comes to configuration (Spring, annotations, guice, etc. etc.).  On the surface this seems to be a pretty large change which involve a lot of work.  How do you plan on specifying which layout to use?  Couldn't the same thing be accomplished by simply giving the converter a name - e.g.:

<convert converter="h3" name="full" match="some.package.User"/>
<convert converter="h3" name="summary" match="some.package.User"/>

Of course we would have to add the nested inclusion (per your original email - include="field.nestedField") but this would allow us to keep a configuration that is very close to what we have now.

Kyle Pinette wrote:

After having thought through your idea, I think it would be pretty useful.  For instance, suppose we built it so that you could define different "skeletons", and also define a default.  Most people would probably only define a default, but there is the option of defining others.  I envision being able to do something like this:

<convert converter="h3" match="some.package.User">
<layout default="true">
<property name="login" />
<property name="fullName" />
</layout>
<layout name="full">
<property name="login" />
<property name="fullName" />
<property name="addresses">
<property name="address1" />
<property name="city" />
<property name="state" />
</property>
</layout>
</convert>

Something like that would be pretty useful I think.  It takes care of nested inclusions / exclusions (although my example shows inclusions), and allows you to define different layouts for the object.

Kyle Pinette

On Wed, Jul 8, 2009 at 10:00 PM, David Marginian <david@... <mailto:david@...>> wrote:

   Yes, I think you are following me, and I think I am being thick
   :).  This is probably not as common of a problem as I originally
   thought, and I am not sure if we need to support it (as I it will
   most likely complicate things a great deal).  I encounter it
   because I work with a framework at work (I'll spare you the
   details) that can at times generate classes with a ton of fields.
    In most cases I only want to serialize a few of the fields, in
   others I need to display everything.  I think the nested
   inclusion/exlusion feature will solve most of the problems.

   Kyle Pinette wrote:

       Could you provide some sort of example case?  Are you saying
       not just depending on where the object is nested?  For
       instance, when you call the server you could pass some sort of
       parameter specifying whether you want the full object or if
       you want a trimmed down version.  Is this what you're talking
       about?  What immediately jumps to mind is providing a
       configuration where you could define "skeletons" that could be
       named, and when you make a call to the server side, specify
       which "skeleton" you want to use.

       Kyle Pinette


       On Wed, Jul 8, 2009 at 9:29 PM, David Marginian
       <david@... <mailto:david@...>

       <mailto:david@... <mailto:david@...>>> wrote:

          Thanks Kyle.  Perhaps I am complicating things here but I think
          any solution needs to not just account for nested
          inclusion/exlusions but also some way to specify converters for
          for the same class that can be used in situations.  For
       example a
          common issue I have encountered is displaying summary data
       in some
          instances and the full object in others.  Currently there is no
          way to do this without creating a wrapper and specifying
       another
          converter for the wrapper.
          Kyle Pinette wrote:

              Hey Everyone,

              I've been using DWR for an intranet site I'm building
       for my
              company.  One thing I've run into that would be nice to
       have
              is the idea of nested inclusions / exclusions.  See
              http://bugs.directwebremoting.org/bugs/browse/DWR-398.
               Essentially, depending on where the object is nested,
       allow
              certain inclusions / exclusions.  This will allow the
              developer to choose what level of detail they want for the
              objects returned from the server, depending on where they
              exist in the object tree.  This would be especially helpful
              with Hibernate.  Hibernate makes it so easy to create
              relationships between all of your objects.  Depending
       on what
              operations you are performing, you may want only a certain
              level of detail.  There is no way to control this directly
              currently.  I am digging through the DWR source now, to
              re-familiarize myself (I was familiar with 2.0).  I'd
       like to
              implement a solution for this problem, but wanted to
       get some
              opinions first.

              Thanks!

              Kyle Pinette



                ---------------------------------------------------------------------
          To unsubscribe, e-mail: dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
          <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>

          For additional commands, e-mail: dev-help@...
       <mailto:dev-help@...>
          <mailto:dev-help@...
       <mailto:dev-help@...>>




   ---------------------------------------------------------------------
   To unsubscribe, e-mail: dev-unsubscribe@...
   <mailto:dev-unsubscribe@...>
   For additional commands, e-mail: dev-help@...
   <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kyle Pinette]

My Ideas:

- For the creator, what if we allow a user to specify a convertInbound / convertOutbound method for their creator.  The convertOutbound method could simply return a JsonObject which would then be converted to its final JSON state by the converter.  Obviously the convertInbound (which I think would be used far less than convertOutbound) would just return an Object, given the specified JsonObject.

- Create a type which represents the structure of the object that is to be created by the convertOutbound method for the converter.  Something like this:

public class ObjectMap
{

Map<String, ObjectMap> properties = new HashMap<String, ObjectMap>();

}

The object map could be passed along (in the outboundContext) to each convertOutbound call for each level of the hierarchy.  The object map could represent inclusions or exclusions.  This means, there wouldn't need to be huges changes made to the current logic.  We would just need to change the way the getPropertyMapFromObject works. We would need an overload where we could pass in our object map for the current level in the hierarchy.  That would mean the inclusions / exclusions for the class would be ignored, and the inclusions / exclusions passed in would be used.

As far as the specific configuration mechanisms are concerned, I will have to get more familiar with how configuration is managed.

Kyle Pinette

On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette <sowelie@...> wrote:

That sounds good.  I am going to be looking at the current code and coming up with some ideas tonight.

Kyle Pinette

---------- Forwarded message ----------
From: Mike Wilson <mikewse@...>
Date: Tue, Jul 21, 2009 at 8:23 PM
Subject: RE: [dwr-dev] Changes to Exclusions / Inclusions
To: dev@...

There may be some previous thinking done in this area. Lance or Randy: didn't one of you suggest some mechanism for specifying a different set of included data properties when a class is sent through a specific method? And Jose: I remember some suggestion of yours about controlling the set of included data properties in class hierarchies?

 

Anyway Kyle, I think your suggestion should include the following:

• a data structure for how to store converters setups and overrides
• an algorithm for how to navigate and make decisions from the data structure
• handling of cases where a creator wants specific control (override) over a certain converted class
• handling of cases where a converter wants specific control (override) over a certain member's converted class (possibly several levels down in the member graph)

Best regards

Mike

---

From: Kyle Pinette [mailto:sowelie@...]
Sent: den 9 juli 2009 14:26
To: dev@...
Subject: Re: [dwr-dev] Changes to Exclusions / Inclusions

I completely understand that there are other configuration mechanisms.  I was just using dwr.xml as an example.  Yeah, it probably would be best to keep the configuration as similar as possible to what exists today.  I am going to take a look at the underlying configuration, and figure out how we would implement this.  Once I have a better understanding of how the configuration works, I'll present my ideas.

Kyle Pinette

On Wed, Jul 8, 2009 at 11:00 PM, David Marginian <david@...> wrote:

As Mike mentioned on the Jira issue, we have to be careful here - dwr.xml is not the only game in town when it comes to configuration (Spring, annotations, guice, etc. etc.).  On the surface this seems to be a pretty large change which involve a lot of work.  How do you plan on specifying which layout to use?  Couldn't the same thing be accomplished by simply giving the converter a name - e.g.:

<convert converter="h3" name="full" match="some.package.User"/>
<convert converter="h3" name="summary" match="some.package.User"/>

Of course we would have to add the nested inclusion (per your original email - include="field.nestedField") but this would allow us to keep a configuration that is very close to what we have now.

Kyle Pinette wrote:

After having thought through your idea, I think it would be pretty useful.  For instance, suppose we built it so that you could define different "skeletons", and also define a default.  Most people would probably only define a default, but there is the option of defining others.  I envision being able to do something like this:

<convert converter="h3" match="some.package.User">
<layout default="true">
<property name="login" />
<property name="fullName" />
</layout>
<layout name="full">
<property name="login" />
<property name="fullName" />
<property name="addresses">
<property name="address1" />
<property name="city" />
<property name="state" />
</property>
</layout>
</convert>

Something like that would be pretty useful I think.  It takes care of nested inclusions / exclusions (although my example shows inclusions), and allows you to define different layouts for the object.

Kyle Pinette

On Wed, Jul 8, 2009 at 10:00 PM, David Marginian <david@... <mailto:david@...>> wrote:

   Yes, I think you are following me, and I think I am being thick
   :).  This is probably not as common of a problem as I originally
   thought, and I am not sure if we need to support it (as I it will
   most likely complicate things a great deal).  I encounter it
   because I work with a framework at work (I'll spare you the
   details) that can at times generate classes with a ton of fields.
    In most cases I only want to serialize a few of the fields, in
   others I need to display everything.  I think the nested
   inclusion/exlusion feature will solve most of the problems.

   Kyle Pinette wrote:

       Could you provide some sort of example case?  Are you saying
       not just depending on where the object is nested?  For
       instance, when you call the server you could pass some sort of
       parameter specifying whether you want the full object or if
       you want a trimmed down version.  Is this what you're talking
       about?  What immediately jumps to mind is providing a
       configuration where you could define "skeletons" that could be
       named, and when you make a call to the server side, specify
       which "skeleton" you want to use.

       Kyle Pinette


       On Wed, Jul 8, 2009 at 9:29 PM, David Marginian
       <david@... <mailto:david@...>

       <mailto:david@... <mailto:david@...>>> wrote:

          Thanks Kyle.  Perhaps I am complicating things here but I think
          any solution needs to not just account for nested
          inclusion/exlusions but also some way to specify converters for
          for the same class that can be used in situations.  For
       example a
          common issue I have encountered is displaying summary data
       in some
          instances and the full object in others.  Currently there is no
          way to do this without creating a wrapper and specifying
       another
          converter for the wrapper.
          Kyle Pinette wrote:

              Hey Everyone,

              I've been using DWR for an intranet site I'm building
       for my
              company.  One thing I've run into that would be nice to
       have
              is the idea of nested inclusions / exclusions.  See
              http://bugs.directwebremoting.org/bugs/browse/DWR-398.
               Essentially, depending on where the object is nested,
       allow
              certain inclusions / exclusions.  This will allow the
              developer to choose what level of detail they want for the
              objects returned from the server, depending on where they
              exist in the object tree.  This would be especially helpful
              with Hibernate.  Hibernate makes it so easy to create
              relationships between all of your objects.  Depending
       on what
              operations you are performing, you may want only a certain
              level of detail.  There is no way to control this directly
              currently.  I am digging through the DWR source now, to
              re-familiarize myself (I was familiar with 2.0).  I'd
       like to
              implement a solution for this problem, but wanted to
       get some
              opinions first.

              Thanks!

              Kyle Pinette



                ---------------------------------------------------------------------
          To unsubscribe, e-mail: dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
          <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>

          For additional commands, e-mail: dev-help@...
       <mailto:dev-help@...>
          <mailto:dev-help@...
       <mailto:dev-help@...>>




   ---------------------------------------------------------------------
   To unsubscribe, e-mail: dev-unsubscribe@...
   <mailto:dev-unsubscribe@...>
   For additional commands, e-mail: dev-help@...
   <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[davidmarginian]

A creator exposes a class, the converters would have to be attached on
the methods exposed not the class itself.  So a user would have to
configure all of the exposed methods (which is not required now) and
specify both an inbound and an outbound converter for each method
(sounds like a lot of configuration). We need to ensure our solution is
backwards compatible and won't in the long run require more
configuration than we have now just to handle a few edge cases.  I will
start putting more thought into this but most of my effort now has been
trying to get a solid release out.

Kyle Pinette wrote:

> My Ideas:
>
> - For the creator, what if we allow a user to specify a convertInbound
> / convertOutbound method for their creator.  The convertOutbound
> method could simply return a JsonObject which would then be converted
> to its final JSON state by the converter.  Obviously the
> convertInbound (which I think would be used far less than
> convertOutbound) would just return an Object, given the specified
> JsonObject.
>
> - Create a type which represents the structure of the object that is
> to be created by the convertOutbound method for the converter.  
> Something like this:
>
> public class ObjectMap
> {
> Map<String, ObjectMap> properties = new HashMap<String, ObjectMap>();
> }
>
> The object map could be passed along (in the outboundContext) to each
> convertOutbound call for each level of the hierarchy.  The object map
> could represent inclusions or exclusions.  This means, there wouldn't
> need to be huges changes made to the current logic.  We would just
> need to change the way the getPropertyMapFromObject works. We would
> need an overload where we could pass in our object map for the current
> level in the hierarchy.  That would mean the inclusions / exclusions
> for the class would be ignored, and the inclusions / exclusions passed
> in would be used.
>
> As far as the specific configuration mechanisms are concerned, I will
> have to get more familiar with how configuration is managed.
>
> Kyle Pinette
>
>
> On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette <sowelie@...
> <mailto:sowelie@...>> wrote:
>
>     That sounds good.  I am going to be looking at the current code
>     and coming up with some ideas tonight.
>
>     Kyle Pinette
>
>
>
>     ---------- Forwarded message ----------
>     From: *Mike Wilson* <mikewse@... <mailto:mikewse@...>>
>     Date: Tue, Jul 21, 2009 at 8:23 PM
>     Subject: RE: [dwr-dev] Changes to Exclusions / Inclusions
>     To: dev@... <mailto:dev@...>
>
>
>     There may be some previous thinking done in this area. Lance or
>     Randy: didn't one of you suggest some mechanism for specifying a
>     different set of included data properties when a class is sent
>     through a specific method? And Jose: I remember some suggestion of
>     yours about controlling the set of included data properties in
>     class hierarchies?
>      
>     Anyway Kyle, I think your suggestion should include the following:
>
>        *
>           a data structure for how to store converters setups
>           and overrides
>        *
>           an algorithm for how to navigate and make decisions from the
>           data structure
>        *
>           handling of cases where a creator wants specific control
>           (override) over a certain converted class
>        *
>           handling of cases where a converter wants specific
>           control (override) over a certain member's converted class
>           (possibly several levels down in the member graph)
>
>     Best regards
>     Mike
>
>         ------------------------------------------------------------------------
>         *From:* Kyle Pinette [mailto:sowelie@...
>         <mailto:sowelie@...>]
>         *Sent:* den 9 juli 2009 14:26
>         *To:* dev@... <mailto:dev@...>
>         *Subject:* Re: [dwr-dev] Changes to Exclusions / Inclusions
>
>         I completely understand that there are other configuration
>         mechanisms.  I was just using dwr.xml as an example.  Yeah, it
>         probably would be best to keep the configuration as similar as
>         possible to what exists today.  I am going to take a look at
>         the underlying configuration, and figure out how we would
>         implement this.  Once I have a better understanding of how the
>         configuration works, I'll present my ideas.
>
>         Kyle Pinette
>
>
>         On Wed, Jul 8, 2009 at 11:00 PM, David Marginian
>         <david@... <mailto:david@...>> wrote:
>
>             As Mike mentioned on the Jira issue, we have to be careful
>             here - dwr.xml is not the only game in town when it comes
>             to configuration (Spring, annotations, guice, etc. etc.).
>              On the surface this seems to be a pretty large change
>             which involve a lot of work.  How do you plan on
>             specifying which layout to use?  Couldn't the same thing
>             be accomplished by simply giving the converter a name - e.g.:
>
>             <convert converter="h3" name="full"
>             match="some.package.User"/>
>             <convert converter="h3" name="summary"
>             match="some.package.User"/>
>
>             Of course we would have to add the nested inclusion (per
>             your original email - include="field.nestedField") but
>             this would allow us to keep a configuration that is very
>             close to what we have now.
>
>             Kyle Pinette wrote:
>
>                 After having thought through your idea, I think it
>                 would be pretty useful.  For instance, suppose we
>                 built it so that you could define different
>                 "skeletons", and also define a default.  Most people
>                 would probably only define a default, but there is the
>                 option of defining others.  I envision being able to
>                 do something like this:
>
>                 <convert converter="h3" match="some.package.User">
>                 <layout default="true">
>                 <property name="login" />
>                 <property name="fullName" />
>                 </layout>
>                 <layout name="full">
>                 <property name="login" />
>                 <property name="fullName" />
>                 <property name="addresses">
>                 <property name="address1" />
>                 <property name="city" />
>                 <property name="state" />
>                 </property>
>                 </layout>
>                 </convert>
>
>                 Something like that would be pretty useful I think.
>                  It takes care of nested inclusions / exclusions
>                 (although my example shows inclusions), and allows you
>                 to define different layouts for the object.
>
>                 Kyle Pinette
>
>
>                 On Wed, Jul 8, 2009 at 10:00 PM, David Marginian
>                 <david@... <mailto:david@...>
>                 <mailto:david@...
>                 <mailto:david@...>>> wrote:
>
>                    Yes, I think you are following me, and I think I am
>                 being thick
>                    :).  This is probably not as common of a problem as
>                 I originally
>                    thought, and I am not sure if we need to support it
>                 (as I it will
>                    most likely complicate things a great deal).  I
>                 encounter it
>                    because I work with a framework at work (I'll spare
>                 you the
>                    details) that can at times generate classes with a
>                 ton of fields.
>                     In most cases I only want to serialize a few of
>                 the fields, in
>                    others I need to display everything.  I think the
>                 nested
>                    inclusion/exlusion feature will solve most of the
>                 problems.
>
>                    Kyle Pinette wrote:
>
>                        Could you provide some sort of example case?
>                  Are you saying
>                        not just depending on where the object is
>                 nested?  For
>                        instance, when you call the server you could
>                 pass some sort of
>                        parameter specifying whether you want the full
>                 object or if
>                        you want a trimmed down version.  Is this what
>                 you're talking
>                        about?  What immediately jumps to mind is
>                 providing a
>                        configuration where you could define
>                 "skeletons" that could be
>                        named, and when you make a call to the server
>                 side, specify
>                        which "skeleton" you want to use.
>
>                        Kyle Pinette
>
>
>                        On Wed, Jul 8, 2009 at 9:29 PM, David Marginian
>                        <david@...
>                 <mailto:david@...>
>                 <mailto:david@... <mailto:david@...>>
>                        <mailto:david@...
>                 <mailto:david@...>
>                 <mailto:david@...
>                 <mailto:david@...>>>> wrote:
>
>                           Thanks Kyle.  Perhaps I am complicating
>                 things here but I think
>                           any solution needs to not just account for
>                 nested
>                           inclusion/exlusions but also some way to
>                 specify converters for
>                           for the same class that can be used in
>                 situations.  For
>                        example a
>                           common issue I have encountered is
>                 displaying summary data
>                        in some
>                           instances and the full object in others.
>                  Currently there is no
>                           way to do this without creating a wrapper
>                 and specifying
>                        another
>                           converter for the wrapper.
>                           Kyle Pinette wrote:
>
>                               Hey Everyone,
>
>                               I've been using DWR for an intranet site
>                 I'm building
>                        for my
>                               company.  One thing I've run into that
>                 would be nice to
>                        have
>                               is the idea of nested inclusions /
>                 exclusions.  See
>                              
>                 http://bugs.directwebremoting.org/bugs/browse/DWR-398.
>                                Essentially, depending on where the
>                 object is nested,
>                        allow
>                               certain inclusions / exclusions.  This
>                 will allow the
>                               developer to choose what level of detail
>                 they want for the
>                               objects returned from the server,
>                 depending on where they
>                               exist in the object tree.  This would be
>                 especially helpful
>                               with Hibernate.  Hibernate makes it so
>                 easy to create
>                               relationships between all of your
>                 objects.  Depending
>                        on what
>                               operations you are performing, you may
>                 want only a certain
>                               level of detail.  There is no way to
>                 control this directly
>                               currently.  I am digging through the DWR
>                 source now, to
>                               re-familiarize myself (I was familiar
>                 with 2.0).  I'd
>                        like to
>                               implement a solution for this problem,
>                 but wanted to
>                        get some
>                               opinions first.
>
>                               Thanks!
>
>                               Kyle Pinette
>
>
>
>                                
>                 ---------------------------------------------------------------------
>                           To unsubscribe, e-mail:
>                 dev-unsubscribe@...
>                 <mailto:dev-unsubscribe@...>
>                        <mailto:dev-unsubscribe@...
>                 <mailto:dev-unsubscribe@...>>
>                           <mailto:dev-unsubscribe@...
>                 <mailto:dev-unsubscribe@...>
>                        <mailto:dev-unsubscribe@...
>                 <mailto:dev-unsubscribe@...>>>
>
>                           For additional commands, e-mail:
>                 dev-help@...
>                 <mailto:dev-help@...>
>                        <mailto:dev-help@...
>                 <mailto:dev-help@...>>
>                           <mailto:dev-help@...
>                 <mailto:dev-help@...>
>                        <mailto:dev-help@...
>                 <mailto:dev-help@...>>>
>
>
>
>
>                  
>                  ---------------------------------------------------------------------
>                    To unsubscribe, e-mail:
>                 dev-unsubscribe@...
>                 <mailto:dev-unsubscribe@...>
>                    <mailto:dev-unsubscribe@...
>                 <mailto:dev-unsubscribe@...>>
>                    For additional commands, e-mail:
>                 dev-help@...
>                 <mailto:dev-help@...>
>                    <mailto:dev-help@...
>                 <mailto:dev-help@...>>
>
>
>
>
>             ---------------------------------------------------------------------
>             To unsubscribe, e-mail: dev-unsubscribe@...
>             <mailto:dev-unsubscribe@...>
>             For additional commands, e-mail: dev-help@...
>             <mailto:dev-help@...>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kyle Pinette]

Gotcha.  So, this would be in addition to the already existing inclusion / exclusions?  I think we could certainly build it that way, we would just need to create a separate way to configure the new inclusions / exclusions.  Wouldn't it be enough to just allow them to specify more advanced inclusions / exclusions for the converters?  Do we need to involve the creators at all?  Do you have google talk or anything like that?  We should have a meeting some time to figure out exactly what needs to be done.

Kyle Pinette

On Fri, Jul 24, 2009 at 11:41 PM, David Marginian <david@...> wrote:

A creator exposes a class, the converters would have to be attached on the methods exposed not the class itself.  So a user would have to configure all of the exposed methods (which is not required now) and specify both an inbound and an outbound converter for each method (sounds like a lot of configuration). We need to ensure our solution is backwards compatible and won't in the long run require more configuration than we have now just to handle a few edge cases.  I will start putting more thought into this but most of my effort now has been trying to get a solid release out.
Kyle Pinette wrote:

My Ideas:

- For the creator, what if we allow a user to specify a convertInbound / convertOutbound method for their creator.  The convertOutbound method could simply return a JsonObject which would then be converted to its final JSON state by the converter.  Obviously the convertInbound (which I think would be used far less than convertOutbound) would just return an Object, given the specified JsonObject.

- Create a type which represents the structure of the object that is to be created by the convertOutbound method for the converter.  Something like this:

public class ObjectMap
{
Map<String, ObjectMap> properties = new HashMap<String, ObjectMap>();
}

The object map could be passed along (in the outboundContext) to each convertOutbound call for each level of the hierarchy.  The object map could represent inclusions or exclusions.  This means, there wouldn't need to be huges changes made to the current logic.  We would just need to change the way the getPropertyMapFromObject works. We would need an overload where we could pass in our object map for the current level in the hierarchy.  That would mean the inclusions / exclusions for the class would be ignored, and the inclusions / exclusions passed in would be used.

As far as the specific configuration mechanisms are concerned, I will have to get more familiar with how configuration is managed.

Kyle Pinette

On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette <sowelie@... <mailto:sowelie@...>> wrote:

   That sounds good.  I am going to be looking at the current code
   and coming up with some ideas tonight.

   Kyle Pinette



   ---------- Forwarded message ----------

   From: *Mike Wilson* <mikewse@... <mailto:mikewse@...>>
   Date: Tue, Jul 21, 2009 at 8:23 PM
   Subject: RE: [dwr-dev] Changes to Exclusions / Inclusions

   To: dev@... <mailto:dev@...>


   There may be some previous thinking done in this area. Lance or
   Randy: didn't one of you suggest some mechanism for specifying a
   different set of included data properties when a class is sent
   through a specific method? And Jose: I remember some suggestion of
   yours about controlling the set of included data properties in
   class hierarchies?
       Anyway Kyle, I think your suggestion should include the following:

      *
         a data structure for how to store converters setups
         and overrides
      *
         an algorithm for how to navigate and make decisions from the
         data structure
      *
         handling of cases where a creator wants specific control
         (override) over a certain converted class
      *
         handling of cases where a converter wants specific
         control (override) over a certain member's converted class
         (possibly several levels down in the member graph)

   Best regards
   Mike

       ------------------------------------------------------------------------
       *From:* Kyle Pinette [mailto:sowelie@...
       <mailto:sowelie@...>]
       *Sent:* den 9 juli 2009 14:26

       *To:* dev@... <mailto:dev@...>

       *Subject:* Re: [dwr-dev] Changes to Exclusions / Inclusions

       I completely understand that there are other configuration
       mechanisms.  I was just using dwr.xml as an example.  Yeah, it
       probably would be best to keep the configuration as similar as
       possible to what exists today.  I am going to take a look at
       the underlying configuration, and figure out how we would
       implement this.  Once I have a better understanding of how the
       configuration works, I'll present my ideas.

       Kyle Pinette


       On Wed, Jul 8, 2009 at 11:00 PM, David Marginian

       <david@... <mailto:david@...>> wrote:

           As Mike mentioned on the Jira issue, we have to be careful
           here - dwr.xml is not the only game in town when it comes
           to configuration (Spring, annotations, guice, etc. etc.).
            On the surface this seems to be a pretty large change
           which involve a lot of work.  How do you plan on
           specifying which layout to use?  Couldn't the same thing
           be accomplished by simply giving the converter a name - e.g.:

           <convert converter="h3" name="full"
           match="some.package.User"/>
           <convert converter="h3" name="summary"
           match="some.package.User"/>

           Of course we would have to add the nested inclusion (per
           your original email - include="field.nestedField") but
           this would allow us to keep a configuration that is very
           close to what we have now.

           Kyle Pinette wrote:

               After having thought through your idea, I think it
               would be pretty useful.  For instance, suppose we
               built it so that you could define different
               "skeletons", and also define a default.  Most people
               would probably only define a default, but there is the
               option of defining others.  I envision being able to
               do something like this:

               <convert converter="h3" match="some.package.User">
               <layout default="true">
               <property name="login" />
               <property name="fullName" />
               </layout>
               <layout name="full">
               <property name="login" />
               <property name="fullName" />
               <property name="addresses">
               <property name="address1" />
               <property name="city" />
               <property name="state" />
               </property>
               </layout>
               </convert>

               Something like that would be pretty useful I think.
                It takes care of nested inclusions / exclusions
               (although my example shows inclusions), and allows you
               to define different layouts for the object.

               Kyle Pinette


               On Wed, Jul 8, 2009 at 10:00 PM, David Marginian
               <david@... <mailto:david@...>

               <mailto:david@...
               <mailto:david@...>>> wrote:

                  Yes, I think you are following me, and I think I am
               being thick
                  :).  This is probably not as common of a problem as
               I originally
                  thought, and I am not sure if we need to support it
               (as I it will
                  most likely complicate things a great deal).  I
               encounter it
                  because I work with a framework at work (I'll spare
               you the
                  details) that can at times generate classes with a
               ton of fields.
                   In most cases I only want to serialize a few of
               the fields, in
                  others I need to display everything.  I think the
               nested
                  inclusion/exlusion feature will solve most of the
               problems.

                  Kyle Pinette wrote:

                      Could you provide some sort of example case?
                Are you saying
                      not just depending on where the object is
               nested?  For
                      instance, when you call the server you could
               pass some sort of
                      parameter specifying whether you want the full
               object or if
                      you want a trimmed down version.  Is this what
               you're talking
                      about?  What immediately jumps to mind is
               providing a
                      configuration where you could define
               "skeletons" that could be
                      named, and when you make a call to the server
               side, specify
                      which "skeleton" you want to use.

                      Kyle Pinette


                      On Wed, Jul 8, 2009 at 9:29 PM, David Marginian
                      <david@...
               <mailto:david@...>
               <mailto:david@... <mailto:david@...>>
                      <mailto:david@...
               <mailto:david@...>
               <mailto:david@...
               <mailto:david@...>>>> wrote:

                         Thanks Kyle.  Perhaps I am complicating
               things here but I think
                         any solution needs to not just account for
               nested
                         inclusion/exlusions but also some way to
               specify converters for
                         for the same class that can be used in
               situations.  For
                      example a
                         common issue I have encountered is
               displaying summary data
                      in some
                         instances and the full object in others.
                Currently there is no
                         way to do this without creating a wrapper
               and specifying
                      another
                         converter for the wrapper.
                         Kyle Pinette wrote:

                             Hey Everyone,

                             I've been using DWR for an intranet site
               I'm building
                      for my
                             company.  One thing I've run into that
               would be nice to
                      have
                             is the idea of nested inclusions /
               exclusions.  See
                                           http://bugs.directwebremoting.org/bugs/browse/DWR-398.
                              Essentially, depending on where the
               object is nested,
                      allow
                             certain inclusions / exclusions.  This
               will allow the
                             developer to choose what level of detail
               they want for the
                             objects returned from the server,
               depending on where they
                             exist in the object tree.  This would be
               especially helpful
                             with Hibernate.  Hibernate makes it so
               easy to create
                             relationships between all of your
               objects.  Depending
                      on what
                             operations you are performing, you may
               want only a certain
                             level of detail.  There is no way to
               control this directly
                             currently.  I am digging through the DWR
               source now, to
                             re-familiarize myself (I was familiar
               with 2.0).  I'd
                      like to
                             implement a solution for this problem,
               but wanted to
                      get some
                             opinions first.

                             Thanks!

                             Kyle Pinette



                                             ---------------------------------------------------------------------
                         To unsubscribe, e-mail:
               dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>>
                         <mailto:dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>>>

                         For additional commands, e-mail:
               dev-help@...
               <mailto:dev-help@...>
                      <mailto:dev-help@...
               <mailto:dev-help@...>>
                         <mailto:dev-help@...
               <mailto:dev-help@...>
                      <mailto:dev-help@...
               <mailto:dev-help@...>>>




                                ---------------------------------------------------------------------
                  To unsubscribe, e-mail:
               dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>
                  <mailto:dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>>
                  For additional commands, e-mail:
               dev-help@...
               <mailto:dev-help@...>
                  <mailto:dev-help@...
               <mailto:dev-help@...>>




           ---------------------------------------------------------------------
           To unsubscribe, e-mail: dev-unsubscribe@...
           <mailto:dev-unsubscribe@...>
           For additional commands, e-mail: dev-help@...
           <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[davidmarginian]

Kyle,
  Although not essential being able to specify a converter (this would
only apply to outbound) for an exposed method may be a nice feature.  
For the situation I wrote about earlier (and decided is probably not
that big of a deal), when you have an object with many fields and in
some cases you only need a few of those fields and in others you want
all of them. I do not use google talk but I have skype and would be
happy to use google talk as well.  But, I would like to keep this on the
back burner until we get a 3.0 release out.  Lets keep the thought
process going here though.

Kyle Pinette wrote:

> Gotcha.  So, this would be in addition to the already existing
> inclusion / exclusions?  I think we could certainly build it that way,
> we would just need to create a separate way to configure the new
> inclusions / exclusions.  Wouldn't it be enough to just allow them to
> specify more advanced inclusions / exclusions for the converters?  Do
> we need to involve the creators at all?  Do you have google talk or
> anything like that?  We should have a meeting some time to figure out
> exactly what needs to be done.
>
> Kyle Pinette
>
>
> On Fri, Jul 24, 2009 at 11:41 PM, David Marginian <david@...
> <mailto:david@...>> wrote:
>
>     A creator exposes a class, the converters would have to be
>     attached on the methods exposed not the class itself.  So a user
>     would have to configure all of the exposed methods (which is not
>     required now) and specify both an inbound and an outbound
>     converter for each method (sounds like a lot of configuration). We
>     need to ensure our solution is backwards compatible and won't in
>     the long run require more configuration than we have now just to
>     handle a few edge cases.  I will start putting more thought into
>     this but most of my effort now has been trying to get a solid
>     release out.
>     Kyle Pinette wrote:
>
>         My Ideas:
>
>         - For the creator, what if we allow a user to specify a
>         convertInbound / convertOutbound method for their creator.
>          The convertOutbound method could simply return a JsonObject
>         which would then be converted to its final JSON state by the
>         converter.  Obviously the convertInbound (which I think would
>         be used far less than convertOutbound) would just return an
>         Object, given the specified JsonObject.
>
>         - Create a type which represents the structure of the object
>         that is to be created by the convertOutbound method for the
>         converter.  Something like this:
>
>         public class ObjectMap
>         {
>         Map<String, ObjectMap> properties = new HashMap<String,
>         ObjectMap>();
>         }
>
>         The object map could be passed along (in the outboundContext)
>         to each convertOutbound call for each level of the hierarchy.
>          The object map could represent inclusions or exclusions.
>          This means, there wouldn't need to be huges changes made to
>         the current logic.  We would just need to change the way the
>         getPropertyMapFromObject works. We would need an overload
>         where we could pass in our object map for the current level in
>         the hierarchy.  That would mean the inclusions / exclusions
>         for the class would be ignored, and the inclusions /
>         exclusions passed in would be used.
>
>         As far as the specific configuration mechanisms are concerned,
>         I will have to get more familiar with how configuration is
>         managed.
>
>         Kyle Pinette
>
>
>         On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette
>         <sowelie@... <mailto:sowelie@...>
>         <mailto:sowelie@... <mailto:sowelie@...>>> wrote:
>
>            That sounds good.  I am going to be looking at the current code
>            and coming up with some ideas tonight.
>
>            Kyle Pinette
>
>
>
>            ---------- Forwarded message ----------
>            From: *Mike Wilson* <mikewse@...
>         <mailto:mikewse@...> <mailto:mikewse@...
>         <mailto:mikewse@...>>>
>            Date: Tue, Jul 21, 2009 at 8:23 PM
>            Subject: RE: [dwr-dev] Changes to Exclusions / Inclusions
>            To: dev@... <mailto:dev@...>
>         <mailto:dev@... <mailto:dev@...>>
>
>
>            There may be some previous thinking done in this area. Lance or
>            Randy: didn't one of you suggest some mechanism for
>         specifying a
>            different set of included data properties when a class is sent
>            through a specific method? And Jose: I remember some
>         suggestion of
>            yours about controlling the set of included data properties in
>            class hierarchies?
>                Anyway Kyle, I think your suggestion should include the
>         following:
>
>               *
>                  a data structure for how to store converters setups
>                  and overrides
>               *
>                  an algorithm for how to navigate and make decisions
>         from the
>                  data structure
>               *
>                  handling of cases where a creator wants specific control
>                  (override) over a certain converted class
>               *
>                  handling of cases where a converter wants specific
>                  control (override) over a certain member's converted
>         class
>                  (possibly several levels down in the member graph)
>
>            Best regards
>            Mike
>
>              
>          ------------------------------------------------------------------------
>                *From:* Kyle Pinette [mailto:sowelie@...
>         <mailto:sowelie@...>
>                <mailto:sowelie@... <mailto:sowelie@...>>]
>                *Sent:* den 9 juli 2009 14:26
>                *To:* dev@...
>         <mailto:dev@...> <mailto:dev@...
>         <mailto:dev@...>>
>
>                *Subject:* Re: [dwr-dev] Changes to Exclusions / Inclusions
>
>                I completely understand that there are other configuration
>                mechanisms.  I was just using dwr.xml as an example.
>          Yeah, it
>                probably would be best to keep the configuration as
>         similar as
>                possible to what exists today.  I am going to take a
>         look at
>                the underlying configuration, and figure out how we would
>                implement this.  Once I have a better understanding of
>         how the
>                configuration works, I'll present my ideas.
>
>                Kyle Pinette
>
>
>                On Wed, Jul 8, 2009 at 11:00 PM, David Marginian
>                <david@... <mailto:david@...>
>         <mailto:david@... <mailto:david@...>>> wrote:
>
>                    As Mike mentioned on the Jira issue, we have to be
>         careful
>                    here - dwr.xml is not the only game in town when it
>         comes
>                    to configuration (Spring, annotations, guice, etc.
>         etc.).
>                     On the surface this seems to be a pretty large change
>                    which involve a lot of work.  How do you plan on
>                    specifying which layout to use?  Couldn't the same
>         thing
>                    be accomplished by simply giving the converter a
>         name - e.g.:
>
>                    <convert converter="h3" name="full"
>                    match="some.package.User"/>
>                    <convert converter="h3" name="summary"
>                    match="some.package.User"/>
>
>                    Of course we would have to add the nested inclusion
>         (per
>                    your original email - include="field.nestedField") but
>                    this would allow us to keep a configuration that is
>         very
>                    close to what we have now.
>
>                    Kyle Pinette wrote:
>
>                        After having thought through your idea, I think it
>                        would be pretty useful.  For instance, suppose we
>                        built it so that you could define different
>                        "skeletons", and also define a default.  Most
>         people
>                        would probably only define a default, but there
>         is the
>                        option of defining others.  I envision being
>         able to
>                        do something like this:
>
>                        <convert converter="h3" match="some.package.User">
>                        <layout default="true">
>                        <property name="login" />
>                        <property name="fullName" />
>                        </layout>
>                        <layout name="full">
>                        <property name="login" />
>                        <property name="fullName" />
>                        <property name="addresses">
>                        <property name="address1" />
>                        <property name="city" />
>                        <property name="state" />
>                        </property>
>                        </layout>
>                        </convert>
>
>                        Something like that would be pretty useful I think.
>                         It takes care of nested inclusions / exclusions
>                        (although my example shows inclusions), and
>         allows you
>                        to define different layouts for the object.
>
>                        Kyle Pinette
>
>
>                        On Wed, Jul 8, 2009 at 10:00 PM, David Marginian
>                        <david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>
>                        <mailto:david@...
>         <mailto:david@...>
>                        <mailto:david@...
>         <mailto:david@...>>>> wrote:
>
>                           Yes, I think you are following me, and I
>         think I am
>                        being thick
>                           :).  This is probably not as common of a
>         problem as
>                        I originally
>                           thought, and I am not sure if we need to
>         support it
>                        (as I it will
>                           most likely complicate things a great deal).  I
>                        encounter it
>                           because I work with a framework at work
>         (I'll spare
>                        you the
>                           details) that can at times generate classes
>         with a
>                        ton of fields.
>                            In most cases I only want to serialize a few of
>                        the fields, in
>                           others I need to display everything.  I
>         think the
>                        nested
>                           inclusion/exlusion feature will solve most
>         of the
>                        problems.
>
>                           Kyle Pinette wrote:
>
>                               Could you provide some sort of example case?
>                         Are you saying
>                               not just depending on where the object is
>                        nested?  For
>                               instance, when you call the server you could
>                        pass some sort of
>                               parameter specifying whether you want
>         the full
>                        object or if
>                               you want a trimmed down version.  Is
>         this what
>                        you're talking
>                               about?  What immediately jumps to mind is
>                        providing a
>                               configuration where you could define
>                        "skeletons" that could be
>                               named, and when you make a call to the
>         server
>                        side, specify
>                               which "skeleton" you want to use.
>
>                               Kyle Pinette
>
>
>                               On Wed, Jul 8, 2009 at 9:29 PM, David
>         Marginian
>                               <david@...
>         <mailto:david@...>
>                        <mailto:david@...
>         <mailto:david@...>>
>                        <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>
>                               <mailto:david@...
>         <mailto:david@...>
>                        <mailto:david@...
>         <mailto:david@...>>
>                        <mailto:david@...
>         <mailto:david@...>
>                        <mailto:david@...
>         <mailto:david@...>>>>> wrote:
>
>                                  Thanks Kyle.  Perhaps I am complicating
>                        things here but I think
>                                  any solution needs to not just
>         account for
>                        nested
>                                  inclusion/exlusions but also some way to
>                        specify converters for
>                                  for the same class that can be used in
>                        situations.  For
>                               example a
>                                  common issue I have encountered is
>                        displaying summary data
>                               in some
>                                  instances and the full object in others.
>                         Currently there is no
>                                  way to do this without creating a wrapper
>                        and specifying
>                               another
>                                  converter for the wrapper.
>                                  Kyle Pinette wrote:
>
>                                      Hey Everyone,
>
>                                      I've been using DWR for an
>         intranet site
>                        I'm building
>                               for my
>                                      company.  One thing I've run into
>         that
>                        would be nice to
>                               have
>                                      is the idea of nested inclusions /
>                        exclusions.  See
>                                                  
>          http://bugs.directwebremoting.org/bugs/browse/DWR-398.
>                                       Essentially, depending on where the
>                        object is nested,
>                               allow
>                                      certain inclusions / exclusions.
>          This
>                        will allow the
>                                      developer to choose what level of
>         detail
>                        they want for the
>                                      objects returned from the server,
>                        depending on where they
>                                      exist in the object tree.  This
>         would be
>                        especially helpful
>                                      with Hibernate.  Hibernate makes
>         it so
>                        easy to create
>                                      relationships between all of your
>                        objects.  Depending
>                               on what
>                                      operations you are performing,
>         you may
>                        want only a certain
>                                      level of detail.  There is no way to
>                        control this directly
>                                      currently.  I am digging through
>         the DWR
>                        source now, to
>                                      re-familiarize myself (I was familiar
>                        with 2.0).  I'd
>                               like to
>                                      implement a solution for this
>         problem,
>                        but wanted to
>                               get some
>                                      opinions first.
>
>                                      Thanks!
>
>                                      Kyle Pinette
>
>
>
>                                                    
>          ---------------------------------------------------------------------
>                                  To unsubscribe, e-mail:
>                        dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                        <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                               <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                        <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                        <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                               <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                        <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>
>
>                                  For additional commands, e-mail:
>                        dev-help@...
>         <mailto:dev-help@...>
>                        <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                               <mailto:dev-help@...
>         <mailto:dev-help@...>
>                        <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                  <mailto:dev-help@...
>         <mailto:dev-help@...>
>                        <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                               <mailto:dev-help@...
>         <mailto:dev-help@...>
>                        <mailto:dev-help@...
>         <mailto:dev-help@...>>>>
>
>
>
>
>                                        
>         ---------------------------------------------------------------------
>                           To unsubscribe, e-mail:
>                        dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                        <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                           <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                        <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                           For additional commands, e-mail:
>                        dev-help@...
>         <mailto:dev-help@...>
>                        <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                           <mailto:dev-help@...
>         <mailto:dev-help@...>
>                        <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>
>
>
>
>                  
>          ---------------------------------------------------------------------
>                    To unsubscribe, e-mail:
>         dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                    <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                    For additional commands, e-mail:
>         dev-help@... <mailto:dev-help@...>
>                    <mailto:dev-help@...
>         <mailto:dev-help@...>>
>
>
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@...
>     <mailto:dev-unsubscribe@...>
>     For additional commands, e-mail: dev-help@...
>     <mailto:dev-help@...>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kyle Pinette]

Cool, sounds good.  I will keep brainstorming.  Do you need any help with bugs for 3.0?

Kyle Pinette

On Sun, Jul 26, 2009 at 11:22 AM, David Marginian <david@...> wrote:

Kyle,
 Although not essential being able to specify a converter (this would only apply to outbound) for an exposed method may be a nice feature.  For the situation I wrote about earlier (and decided is probably not that big of a deal), when you have an object with many fields and in some cases you only need a few of those fields and in others you want all of them. I do not use google talk but I have skype and would be happy to use google talk as well.  But, I would like to keep this on the back burner until we get a 3.0 release out.  Lets keep the thought process going here though.

Kyle Pinette wrote:

Gotcha.  So, this would be in addition to the already existing inclusion / exclusions?  I think we could certainly build it that way, we would just need to create a separate way to configure the new inclusions / exclusions.  Wouldn't it be enough to just allow them to specify more advanced inclusions / exclusions for the converters?  Do we need to involve the creators at all?  Do you have google talk or anything like that?  We should have a meeting some time to figure out exactly what needs to be done.

Kyle Pinette

On Fri, Jul 24, 2009 at 11:41 PM, David Marginian <david@... <mailto:david@...>> wrote:

   A creator exposes a class, the converters would have to be
   attached on the methods exposed not the class itself.  So a user
   would have to configure all of the exposed methods (which is not
   required now) and specify both an inbound and an outbound
   converter for each method (sounds like a lot of configuration). We
   need to ensure our solution is backwards compatible and won't in
   the long run require more configuration than we have now just to
   handle a few edge cases.  I will start putting more thought into
   this but most of my effort now has been trying to get a solid
   release out.
   Kyle Pinette wrote:

       My Ideas:

       - For the creator, what if we allow a user to specify a
       convertInbound / convertOutbound method for their creator.
        The convertOutbound method could simply return a JsonObject
       which would then be converted to its final JSON state by the
       converter.  Obviously the convertInbound (which I think would
       be used far less than convertOutbound) would just return an
       Object, given the specified JsonObject.

       - Create a type which represents the structure of the object
       that is to be created by the convertOutbound method for the
       converter.  Something like this:

       public class ObjectMap
       {
       Map<String, ObjectMap> properties = new HashMap<String,
       ObjectMap>();
       }

       The object map could be passed along (in the outboundContext)
       to each convertOutbound call for each level of the hierarchy.
        The object map could represent inclusions or exclusions.
        This means, there wouldn't need to be huges changes made to
       the current logic.  We would just need to change the way the
       getPropertyMapFromObject works. We would need an overload
       where we could pass in our object map for the current level in
       the hierarchy.  That would mean the inclusions / exclusions
       for the class would be ignored, and the inclusions /
       exclusions passed in would be used.

       As far as the specific configuration mechanisms are concerned,
       I will have to get more familiar with how configuration is
       managed.

       Kyle Pinette


       On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette
       <sowelie@... <mailto:sowelie@...>

       <mailto:sowelie@... <mailto:sowelie@...>>> wrote:

          That sounds good.  I am going to be looking at the current code
          and coming up with some ideas tonight.

          Kyle Pinette



          ---------- Forwarded message ----------
          From: *Mike Wilson* <mikewse@...

       <mailto:mikewse@...> <mailto:mikewse@...
       <mailto:mikewse@...>>>
          Date: Tue, Jul 21, 2009 at 8:23 PM
          Subject: RE: [dwr-dev] Changes to Exclusions / Inclusions
          To: dev@... <mailto:dev@...>

       <mailto:dev@... <mailto:dev@...>>


          There may be some previous thinking done in this area. Lance or
          Randy: didn't one of you suggest some mechanism for
       specifying a
          different set of included data properties when a class is sent
          through a specific method? And Jose: I remember some
       suggestion of
          yours about controlling the set of included data properties in
          class hierarchies?
              Anyway Kyle, I think your suggestion should include the
       following:

             *
                a data structure for how to store converters setups
                and overrides
             *
                an algorithm for how to navigate and make decisions
       from the
                data structure
             *
                handling of cases where a creator wants specific control
                (override) over a certain converted class
             *
                handling of cases where a converter wants specific
                control (override) over a certain member's converted
       class
                (possibly several levels down in the member graph)

          Best regards
          Mike

                    ------------------------------------------------------------------------
              *From:* Kyle Pinette [mailto:sowelie@...
       <mailto:sowelie@...>
              <mailto:sowelie@... <mailto:sowelie@...>>]
              *Sent:* den 9 juli 2009 14:26
              *To:* dev@...

       <mailto:dev@...> <mailto:dev@...

       <mailto:dev@...>>

              *Subject:* Re: [dwr-dev] Changes to Exclusions / Inclusions

              I completely understand that there are other configuration
              mechanisms.  I was just using dwr.xml as an example.
        Yeah, it
              probably would be best to keep the configuration as
       similar as
              possible to what exists today.  I am going to take a
       look at
              the underlying configuration, and figure out how we would
              implement this.  Once I have a better understanding of
       how the
              configuration works, I'll present my ideas.

              Kyle Pinette


              On Wed, Jul 8, 2009 at 11:00 PM, David Marginian
              <david@... <mailto:david@...>

       <mailto:david@... <mailto:david@...>>> wrote:

                  As Mike mentioned on the Jira issue, we have to be
       careful
                  here - dwr.xml is not the only game in town when it
       comes
                  to configuration (Spring, annotations, guice, etc.
       etc.).
                   On the surface this seems to be a pretty large change
                  which involve a lot of work.  How do you plan on
                  specifying which layout to use?  Couldn't the same
       thing
                  be accomplished by simply giving the converter a
       name - e.g.:

                  <convert converter="h3" name="full"
                  match="some.package.User"/>
                  <convert converter="h3" name="summary"
                  match="some.package.User"/>

                  Of course we would have to add the nested inclusion
       (per
                  your original email - include="field.nestedField") but
                  this would allow us to keep a configuration that is
       very
                  close to what we have now.

                  Kyle Pinette wrote:

                      After having thought through your idea, I think it
                      would be pretty useful.  For instance, suppose we
                      built it so that you could define different
                      "skeletons", and also define a default.  Most
       people
                      would probably only define a default, but there
       is the
                      option of defining others.  I envision being
       able to
                      do something like this:

                      <convert converter="h3" match="some.package.User">
                      <layout default="true">
                      <property name="login" />
                      <property name="fullName" />
                      </layout>
                      <layout name="full">
                      <property name="login" />
                      <property name="fullName" />
                      <property name="addresses">
                      <property name="address1" />
                      <property name="city" />
                      <property name="state" />
                      </property>
                      </layout>
                      </convert>

                      Something like that would be pretty useful I think.
                       It takes care of nested inclusions / exclusions
                      (although my example shows inclusions), and
       allows you
                      to define different layouts for the object.

                      Kyle Pinette


                      On Wed, Jul 8, 2009 at 10:00 PM, David Marginian
                      <david@...
       <mailto:david@...> <mailto:david@...
       <mailto:david@...>>

                      <mailto:david@...
       <mailto:david@...>
                      <mailto:david@...
       <mailto:david@...>>>> wrote:

                         Yes, I think you are following me, and I
       think I am
                      being thick
                         :).  This is probably not as common of a
       problem as
                      I originally
                         thought, and I am not sure if we need to
       support it
                      (as I it will
                         most likely complicate things a great deal).  I
                      encounter it
                         because I work with a framework at work
       (I'll spare
                      you the
                         details) that can at times generate classes
       with a
                      ton of fields.
                          In most cases I only want to serialize a few of
                      the fields, in
                         others I need to display everything.  I
       think the
                      nested
                         inclusion/exlusion feature will solve most
       of the
                      problems.

                         Kyle Pinette wrote:

                             Could you provide some sort of example case?
                       Are you saying
                             not just depending on where the object is
                      nested?  For
                             instance, when you call the server you could
                      pass some sort of
                             parameter specifying whether you want
       the full
                      object or if
                             you want a trimmed down version.  Is
       this what
                      you're talking
                             about?  What immediately jumps to mind is
                      providing a
                             configuration where you could define
                      "skeletons" that could be
                             named, and when you make a call to the
       server
                      side, specify
                             which "skeleton" you want to use.

                             Kyle Pinette


                             On Wed, Jul 8, 2009 at 9:29 PM, David
       Marginian
                             <david@...
       <mailto:david@...>
                      <mailto:david@...
       <mailto:david@...>>
                      <mailto:david@...
       <mailto:david@...> <mailto:david@...
       <mailto:david@...>>>
                             <mailto:david@...
       <mailto:david@...>
                      <mailto:david@...
       <mailto:david@...>>
                      <mailto:david@...
       <mailto:david@...>
                      <mailto:david@...
       <mailto:david@...>>>>> wrote:

                                Thanks Kyle.  Perhaps I am complicating
                      things here but I think
                                any solution needs to not just
       account for
                      nested
                                inclusion/exlusions but also some way to
                      specify converters for
                                for the same class that can be used in
                      situations.  For
                             example a
                                common issue I have encountered is
                      displaying summary data
                             in some
                                instances and the full object in others.
                       Currently there is no
                                way to do this without creating a wrapper
                      and specifying
                             another
                                converter for the wrapper.
                                Kyle Pinette wrote:

                                    Hey Everyone,

                                    I've been using DWR for an
       intranet site
                      I'm building
                             for my
                                    company.  One thing I've run into
       that
                      would be nice to
                             have
                                    is the idea of nested inclusions /
                      exclusions.  See
                                                        http://bugs.directwebremoting.org/bugs/browse/DWR-398.
                                     Essentially, depending on where the
                      object is nested,
                             allow
                                    certain inclusions / exclusions.
        This
                      will allow the
                                    developer to choose what level of
       detail
                      they want for the
                                    objects returned from the server,
                      depending on where they
                                    exist in the object tree.  This
       would be
                      especially helpful
                                    with Hibernate.  Hibernate makes
       it so
                      easy to create
                                    relationships between all of your
                      objects.  Depending
                             on what
                                    operations you are performing,
       you may
                      want only a certain
                                    level of detail.  There is no way to
                      control this directly
                                    currently.  I am digging through
       the DWR
                      source now, to
                                    re-familiarize myself (I was familiar
                      with 2.0).  I'd
                             like to
                                    implement a solution for this
       problem,
                      but wanted to
                             get some
                                    opinions first.

                                    Thanks!

                                    Kyle Pinette



                                                          ---------------------------------------------------------------------
                                To unsubscribe, e-mail:
                      dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                             <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>
                                      <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                             <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>>

                                For additional commands, e-mail:
                      dev-help@...
       <mailto:dev-help@...>
                      <mailto:dev-help@...
       <mailto:dev-help@...>>
                             <mailto:dev-help@...
       <mailto:dev-help@...>
                      <mailto:dev-help@...
       <mailto:dev-help@...>>>
                                <mailto:dev-help@...
       <mailto:dev-help@...>
                      <mailto:dev-help@...
       <mailto:dev-help@...>>
                             <mailto:dev-help@...
       <mailto:dev-help@...>
                      <mailto:dev-help@...
       <mailto:dev-help@...>>>>




                                             ---------------------------------------------------------------------
                         To unsubscribe, e-mail:
                      dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                         <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>
                         For additional commands, e-mail:
                      dev-help@...
       <mailto:dev-help@...>
                      <mailto:dev-help@...
       <mailto:dev-help@...>>
                         <mailto:dev-help@...
       <mailto:dev-help@...>
                      <mailto:dev-help@...
       <mailto:dev-help@...>>>




                        ---------------------------------------------------------------------
                  To unsubscribe, e-mail:
       dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
                  <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                  For additional commands, e-mail:
       dev-help@... <mailto:dev-help@...>
                  <mailto:dev-help@...
       <mailto:dev-help@...>>






   ---------------------------------------------------------------------
   To unsubscribe, e-mail: dev-unsubscribe@...
   <mailto:dev-unsubscribe@...>
   For additional commands, e-mail: dev-help@...
   <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[davidmarginian]

Yes, we could use some help.  Take a look at the issue queue and if you
see anything you are comfortable working let the assignee know.

Kyle Pinette wrote:

> Cool, sounds good.  I will keep brainstorming.  Do you need any help
> with bugs for 3.0?
>
> Kyle Pinette
>
>
> On Sun, Jul 26, 2009 at 11:22 AM, David Marginian <david@...
> <mailto:david@...>> wrote:
>
>     Kyle,
>      Although not essential being able to specify a converter (this
>     would only apply to outbound) for an exposed method may be a nice
>     feature.  For the situation I wrote about earlier (and decided is
>     probably not that big of a deal), when you have an object with
>     many fields and in some cases you only need a few of those fields
>     and in others you want all of them. I do not use google talk but I
>     have skype and would be happy to use google talk as well.  But, I
>     would like to keep this on the back burner until we get a 3.0
>     release out.  Lets keep the thought process going here though.
>
>     Kyle Pinette wrote:
>
>         Gotcha.  So, this would be in addition to the already existing
>         inclusion / exclusions?  I think we could certainly build it
>         that way, we would just need to create a separate way to
>         configure the new inclusions / exclusions.  Wouldn't it be
>         enough to just allow them to specify more advanced inclusions
>         / exclusions for the converters?  Do we need to involve the
>         creators at all?  Do you have google talk or anything like
>         that?  We should have a meeting some time to figure out
>         exactly what needs to be done.
>
>         Kyle Pinette
>
>
>         On Fri, Jul 24, 2009 at 11:41 PM, David Marginian
>         <david@... <mailto:david@...>
>         <mailto:david@... <mailto:david@...>>> wrote:
>
>            A creator exposes a class, the converters would have to be
>            attached on the methods exposed not the class itself.  So a
>         user
>            would have to configure all of the exposed methods (which
>         is not
>            required now) and specify both an inbound and an outbound
>            converter for each method (sounds like a lot of
>         configuration). We
>            need to ensure our solution is backwards compatible and
>         won't in
>            the long run require more configuration than we have now
>         just to
>            handle a few edge cases.  I will start putting more thought
>         into
>            this but most of my effort now has been trying to get a solid
>            release out.
>            Kyle Pinette wrote:
>
>                My Ideas:
>
>                - For the creator, what if we allow a user to specify a
>                convertInbound / convertOutbound method for their creator.
>                 The convertOutbound method could simply return a
>         JsonObject
>                which would then be converted to its final JSON state
>         by the
>                converter.  Obviously the convertInbound (which I think
>         would
>                be used far less than convertOutbound) would just return an
>                Object, given the specified JsonObject.
>
>                - Create a type which represents the structure of the
>         object
>                that is to be created by the convertOutbound method for the
>                converter.  Something like this:
>
>                public class ObjectMap
>                {
>                Map<String, ObjectMap> properties = new HashMap<String,
>                ObjectMap>();
>                }
>
>                The object map could be passed along (in the
>         outboundContext)
>                to each convertOutbound call for each level of the
>         hierarchy.
>                 The object map could represent inclusions or exclusions.
>                 This means, there wouldn't need to be huges changes
>         made to
>                the current logic.  We would just need to change the
>         way the
>                getPropertyMapFromObject works. We would need an overload
>                where we could pass in our object map for the current
>         level in
>                the hierarchy.  That would mean the inclusions / exclusions
>                for the class would be ignored, and the inclusions /
>                exclusions passed in would be used.
>
>                As far as the specific configuration mechanisms are
>         concerned,
>                I will have to get more familiar with how configuration is
>                managed.
>
>                Kyle Pinette
>
>
>                On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette
>                <sowelie@... <mailto:sowelie@...>
>         <mailto:sowelie@... <mailto:sowelie@...>>
>                <mailto:sowelie@... <mailto:sowelie@...>
>         <mailto:sowelie@... <mailto:sowelie@...>>>> wrote:
>
>                   That sounds good.  I am going to be looking at the
>         current code
>                   and coming up with some ideas tonight.
>
>                   Kyle Pinette
>
>
>
>                   ---------- Forwarded message ----------
>                   From: *Mike Wilson* <mikewse@...
>         <mailto:mikewse@...>
>                <mailto:mikewse@...
>         <mailto:mikewse@...>> <mailto:mikewse@...
>         <mailto:mikewse@...>
>                <mailto:mikewse@... <mailto:mikewse@...>>>>
>                   Date: Tue, Jul 21, 2009 at 8:23 PM
>                   Subject: RE: [dwr-dev] Changes to Exclusions /
>         Inclusions
>                   To: dev@...
>         <mailto:dev@...> <mailto:dev@...
>         <mailto:dev@...>>
>                <mailto:dev@...
>         <mailto:dev@...> <mailto:dev@...
>         <mailto:dev@...>>>
>
>
>                   There may be some previous thinking done in this
>         area. Lance or
>                   Randy: didn't one of you suggest some mechanism for
>                specifying a
>                   different set of included data properties when a
>         class is sent
>                   through a specific method? And Jose: I remember some
>                suggestion of
>                   yours about controlling the set of included data
>         properties in
>                   class hierarchies?
>                       Anyway Kyle, I think your suggestion should
>         include the
>                following:
>
>                      *
>                         a data structure for how to store converters
>         setups
>                         and overrides
>                      *
>                         an algorithm for how to navigate and make
>         decisions
>                from the
>                         data structure
>                      *
>                         handling of cases where a creator wants
>         specific control
>                         (override) over a certain converted class
>                      *
>                         handling of cases where a converter wants specific
>                         control (override) over a certain member's
>         converted
>                class
>                         (possibly several levels down in the member graph)
>
>                   Best regards
>                   Mike
>
>                            
>         ------------------------------------------------------------------------
>                       *From:* Kyle Pinette [mailto:sowelie@...
>         <mailto:sowelie@...>
>                <mailto:sowelie@... <mailto:sowelie@...>>
>                       <mailto:sowelie@...
>         <mailto:sowelie@...> <mailto:sowelie@...
>         <mailto:sowelie@...>>>]
>                       *Sent:* den 9 juli 2009 14:26
>                       *To:* dev@...
>         <mailto:dev@...>
>                <mailto:dev@...
>         <mailto:dev@...>> <mailto:dev@...
>         <mailto:dev@...>
>
>                <mailto:dev@...
>         <mailto:dev@...>>>
>
>                       *Subject:* Re: [dwr-dev] Changes to Exclusions /
>         Inclusions
>
>                       I completely understand that there are other
>         configuration
>                       mechanisms.  I was just using dwr.xml as an example.
>                 Yeah, it
>                       probably would be best to keep the configuration as
>                similar as
>                       possible to what exists today.  I am going to take a
>                look at
>                       the underlying configuration, and figure out how
>         we would
>                       implement this.  Once I have a better
>         understanding of
>                how the
>                       configuration works, I'll present my ideas.
>
>                       Kyle Pinette
>
>
>                       On Wed, Jul 8, 2009 at 11:00 PM, David Marginian
>                       <david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>
>                <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>> wrote:
>
>                           As Mike mentioned on the Jira issue, we have
>         to be
>                careful
>                           here - dwr.xml is not the only game in town
>         when it
>                comes
>                           to configuration (Spring, annotations,
>         guice, etc.
>                etc.).
>                            On the surface this seems to be a pretty
>         large change
>                           which involve a lot of work.  How do you plan on
>                           specifying which layout to use?  Couldn't
>         the same
>                thing
>                           be accomplished by simply giving the converter a
>                name - e.g.:
>
>                           <convert converter="h3" name="full"
>                           match="some.package.User"/>
>                           <convert converter="h3" name="summary"
>                           match="some.package.User"/>
>
>                           Of course we would have to add the nested
>         inclusion
>                (per
>                           your original email -
>         include="field.nestedField") but
>                           this would allow us to keep a configuration
>         that is
>                very
>                           close to what we have now.
>
>                           Kyle Pinette wrote:
>
>                               After having thought through your idea,
>         I think it
>                               would be pretty useful.  For instance,
>         suppose we
>                               built it so that you could define different
>                               "skeletons", and also define a default.
>          Most
>                people
>                               would probably only define a default,
>         but there
>                is the
>                               option of defining others.  I envision being
>                able to
>                               do something like this:
>
>                               <convert converter="h3"
>         match="some.package.User">
>                               <layout default="true">
>                               <property name="login" />
>                               <property name="fullName" />
>                               </layout>
>                               <layout name="full">
>                               <property name="login" />
>                               <property name="fullName" />
>                               <property name="addresses">
>                               <property name="address1" />
>                               <property name="city" />
>                               <property name="state" />
>                               </property>
>                               </layout>
>                               </convert>
>
>                               Something like that would be pretty
>         useful I think.
>                                It takes care of nested inclusions /
>         exclusions
>                               (although my example shows inclusions), and
>                allows you
>                               to define different layouts for the object.
>
>                               Kyle Pinette
>
>
>                               On Wed, Jul 8, 2009 at 10:00 PM, David
>         Marginian
>                               <david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>> <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>>
>                               <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                               <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>>>>> wrote:
>
>                                  Yes, I think you are following me, and I
>                think I am
>                               being thick
>                                  :).  This is probably not as common of a
>                problem as
>                               I originally
>                                  thought, and I am not sure if we need to
>                support it
>                               (as I it will
>                                  most likely complicate things a great
>         deal).  I
>                               encounter it
>                                  because I work with a framework at work
>                (I'll spare
>                               you the
>                                  details) that can at times generate
>         classes
>                with a
>                               ton of fields.
>                                   In most cases I only want to
>         serialize a few of
>                               the fields, in
>                                  others I need to display everything.  I
>                think the
>                               nested
>                                  inclusion/exlusion feature will solve
>         most
>                of the
>                               problems.
>
>                                  Kyle Pinette wrote:
>
>                                      Could you provide some sort of
>         example case?
>                                Are you saying
>                                      not just depending on where the
>         object is
>                               nested?  For
>                                      instance, when you call the
>         server you could
>                               pass some sort of
>                                      parameter specifying whether you want
>                the full
>                               object or if
>                                      you want a trimmed down version.  Is
>                this what
>                               you're talking
>                                      about?  What immediately jumps to
>         mind is
>                               providing a
>                                      configuration where you could define
>                               "skeletons" that could be
>                                      named, and when you make a call
>         to the
>                server
>                               side, specify
>                                      which "skeleton" you want to use.
>
>                                      Kyle Pinette
>
>
>                                      On Wed, Jul 8, 2009 at 9:29 PM, David
>                Marginian
>                                      <david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                               <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>>
>                               <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>> <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>>>
>                                      <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                               <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>>
>                               <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                               <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>>>>>> wrote:
>
>                                         Thanks Kyle.  Perhaps I am
>         complicating
>                               things here but I think
>                                         any solution needs to not just
>                account for
>                               nested
>                                         inclusion/exlusions but also
>         some way to
>                               specify converters for
>                                         for the same class that can be
>         used in
>                               situations.  For
>                                      example a
>                                         common issue I have encountered is
>                               displaying summary data
>                                      in some
>                                         instances and the full object
>         in others.
>                                Currently there is no
>                                         way to do this without
>         creating a wrapper
>                               and specifying
>                                      another
>                                         converter for the wrapper.
>                                         Kyle Pinette wrote:
>
>                                             Hey Everyone,
>
>                                             I've been using DWR for an
>                intranet site
>                               I'm building
>                                      for my
>                                             company.  One thing I've
>         run into
>                that
>                               would be nice to
>                                      have
>                                             is the idea of nested
>         inclusions /
>                               exclusions.  See
>                                                                
>         http://bugs.directwebremoting.org/bugs/browse/DWR-398.
>                                              Essentially, depending on
>         where the
>                               object is nested,
>                                      allow
>                                             certain inclusions /
>         exclusions.
>                 This
>                               will allow the
>                                             developer to choose what
>         level of
>                detail
>                               they want for the
>                                             objects returned from the
>         server,
>                               depending on where they
>                                             exist in the object tree.
>          This
>                would be
>                               especially helpful
>                                             with Hibernate.  Hibernate
>         makes
>                it so
>                               easy to create
>                                             relationships between all
>         of your
>                               objects.  Depending
>                                      on what
>                                             operations you are performing,
>                you may
>                               want only a certain
>                                             level of detail.  There is
>         no way to
>                               control this directly
>                                             currently.  I am digging
>         through
>                the DWR
>                               source now, to
>                                             re-familiarize myself (I
>         was familiar
>                               with 2.0).  I'd
>                                      like to
>                                             implement a solution for this
>                problem,
>                               but wanted to
>                                      get some
>                                             opinions first.
>
>                                             Thanks!
>
>                                             Kyle Pinette
>
>
>
>                                                                  
>         ---------------------------------------------------------------------
>                                         To unsubscribe, e-mail:
>                               dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                               <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                    
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                               <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>
>                                              
>         <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                               <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                    
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                               <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>>
>
>                                         For additional commands, e-mail:
>                               dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                               <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                      <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                               <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>
>                                        
>         <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                               <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                      <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                               <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>>
>
>
>
>
>                                                    
>          ---------------------------------------------------------------------
>                                  To unsubscribe, e-mail:
>                               dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                               <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                               <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>
>                                  For additional commands, e-mail:
>                               dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                               <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                  <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                               <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>
>
>
>
>
>                                
>         ---------------------------------------------------------------------
>                           To unsubscribe, e-mail:
>                dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                           <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                           For additional commands, e-mail:
>                dev-help@...
>         <mailto:dev-help@...>
>         <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                           <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>
>
>
>
>
>
>          
>          ---------------------------------------------------------------------
>            To unsubscribe, e-mail: dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>            <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>            For additional commands, e-mail: dev-help@...
>         <mailto:dev-help@...>
>            <mailto:dev-help@...
>         <mailto:dev-help@...>>
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@...
>     <mailto:dev-unsubscribe@...>
>     For additional commands, e-mail: dev-help@...
>     <mailto:dev-help@...>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kyle Pinette]

David,

What area should I focus on? What release are you guys working on? 3.0 RC2?

Kyle Pinette

On Sun, Jul 26, 2009 at 5:49 PM, David Marginian <david@...> wrote:

Yes, we could use some help.  Take a look at the issue queue and if you see anything you are comfortable working let the assignee know.

Kyle Pinette wrote:

Cool, sounds good.  I will keep brainstorming.  Do you need any help with bugs for 3.0?

Kyle Pinette

On Sun, Jul 26, 2009 at 11:22 AM, David Marginian <david@... <mailto:david@...>> wrote:

   Kyle,
    Although not essential being able to specify a converter (this
   would only apply to outbound) for an exposed method may be a nice
   feature.  For the situation I wrote about earlier (and decided is
   probably not that big of a deal), when you have an object with
   many fields and in some cases you only need a few of those fields
   and in others you want all of them. I do not use google talk but I
   have skype and would be happy to use google talk as well.  But, I
   would like to keep this on the back burner until we get a 3.0
   release out.  Lets keep the thought process going here though.

   Kyle Pinette wrote:

       Gotcha.  So, this would be in addition to the already existing
       inclusion / exclusions?  I think we could certainly build it
       that way, we would just need to create a separate way to
       configure the new inclusions / exclusions.  Wouldn't it be
       enough to just allow them to specify more advanced inclusions
       / exclusions for the converters?  Do we need to involve the
       creators at all?  Do you have google talk or anything like
       that?  We should have a meeting some time to figure out
       exactly what needs to be done.

       Kyle Pinette


       On Fri, Jul 24, 2009 at 11:41 PM, David Marginian
       <david@... <mailto:david@...>

       <mailto:david@... <mailto:david@...>>> wrote:

          A creator exposes a class, the converters would have to be
          attached on the methods exposed not the class itself.  So a
       user
          would have to configure all of the exposed methods (which
       is not
          required now) and specify both an inbound and an outbound
          converter for each method (sounds like a lot of
       configuration). We
          need to ensure our solution is backwards compatible and
       won't in
          the long run require more configuration than we have now
       just to
          handle a few edge cases.  I will start putting more thought
       into
          this but most of my effort now has been trying to get a solid
          release out.
          Kyle Pinette wrote:

              My Ideas:

              - For the creator, what if we allow a user to specify a
              convertInbound / convertOutbound method for their creator.
               The convertOutbound method could simply return a
       JsonObject
              which would then be converted to its final JSON state
       by the
              converter.  Obviously the convertInbound (which I think
       would
              be used far less than convertOutbound) would just return an
              Object, given the specified JsonObject.

              - Create a type which represents the structure of the
       object
              that is to be created by the convertOutbound method for the
              converter.  Something like this:

              public class ObjectMap
              {
              Map<String, ObjectMap> properties = new HashMap<String,
              ObjectMap>();
              }

              The object map could be passed along (in the
       outboundContext)
              to each convertOutbound call for each level of the
       hierarchy.
               The object map could represent inclusions or exclusions.
               This means, there wouldn't need to be huges changes
       made to
              the current logic.  We would just need to change the
       way the
              getPropertyMapFromObject works. We would need an overload
              where we could pass in our object map for the current
       level in
              the hierarchy.  That would mean the inclusions / exclusions
              for the class would be ignored, and the inclusions /
              exclusions passed in would be used.

              As far as the specific configuration mechanisms are
       concerned,
              I will have to get more familiar with how configuration is
              managed.

              Kyle Pinette


              On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette
              <sowelie@... <mailto:sowelie@...>
       <mailto:sowelie@... <mailto:sowelie@...>>

              <mailto:sowelie@... <mailto:sowelie@...>

       <mailto:sowelie@... <mailto:sowelie@...>>>> wrote:

                 That sounds good.  I am going to be looking at the
       current code
                 and coming up with some ideas tonight.

                 Kyle Pinette



                 ---------- Forwarded message ----------
                 From: *Mike Wilson* <mikewse@...
       <mailto:mikewse@...>
              <mailto:mikewse@...

       <mailto:mikewse@...>> <mailto:mikewse@...
       <mailto:mikewse@...>

              <mailto:mikewse@... <mailto:mikewse@...>>>>
                 Date: Tue, Jul 21, 2009 at 8:23 PM
                 Subject: RE: [dwr-dev] Changes to Exclusions /
       Inclusions
                 To: dev@...
       <mailto:dev@...> <mailto:dev@...
       <mailto:dev@...>>
              <mailto:dev@...
       <mailto:dev@...> <mailto:dev@...
       <mailto:dev@...>>>


                 There may be some previous thinking done in this
       area. Lance or
                 Randy: didn't one of you suggest some mechanism for
              specifying a
                 different set of included data properties when a
       class is sent
                 through a specific method? And Jose: I remember some
              suggestion of
                 yours about controlling the set of included data
       properties in
                 class hierarchies?
                     Anyway Kyle, I think your suggestion should
       include the
              following:

                    *
                       a data structure for how to store converters
       setups
                       and overrides
                    *
                       an algorithm for how to navigate and make
       decisions
              from the
                       data structure
                    *
                       handling of cases where a creator wants
       specific control
                       (override) over a certain converted class
                    *
                       handling of cases where a converter wants specific
                       control (override) over a certain member's
       converted
              class
                       (possibly several levels down in the member graph)

                 Best regards
                 Mike

                                 ------------------------------------------------------------------------
                     *From:* Kyle Pinette [mailto:sowelie@...
       <mailto:sowelie@...>
              <mailto:sowelie@... <mailto:sowelie@...>>
                     <mailto:sowelie@...
       <mailto:sowelie@...> <mailto:sowelie@...
       <mailto:sowelie@...>>>]
                     *Sent:* den 9 juli 2009 14:26
                     *To:* dev@...
       <mailto:dev@...>
              <mailto:dev@...

       <mailto:dev@...>> <mailto:dev@...

       <mailto:dev@...>

              <mailto:dev@...

       <mailto:dev@...>>>

                     *Subject:* Re: [dwr-dev] Changes to Exclusions /
       Inclusions

                     I completely understand that there are other
       configuration
                     mechanisms.  I was just using dwr.xml as an example.
               Yeah, it
                     probably would be best to keep the configuration as
              similar as
                     possible to what exists today.  I am going to take a
              look at
                     the underlying configuration, and figure out how
       we would
                     implement this.  Once I have a better
       understanding of
              how the
                     configuration works, I'll present my ideas.

                     Kyle Pinette


                     On Wed, Jul 8, 2009 at 11:00 PM, David Marginian
                     <david@...
       <mailto:david@...> <mailto:david@...
       <mailto:david@...>>

              <mailto:david@...
       <mailto:david@...> <mailto:david@...
       <mailto:david@...>>>> wrote:

                         As Mike mentioned on the Jira issue, we have
       to be
              careful
                         here - dwr.xml is not the only game in town
       when it
              comes
                         to configuration (Spring, annotations,
       guice, etc.
              etc.).
                          On the surface this seems to be a pretty
       large change
                         which involve a lot of work.  How do you plan on
                         specifying which layout to use?  Couldn't
       the same
              thing
                         be accomplished by simply giving the converter a
              name - e.g.:

                         <convert converter="h3" name="full"
                         match="some.package.User"/>
                         <convert converter="h3" name="summary"
                         match="some.package.User"/>

                         Of course we would have to add the nested
       inclusion
              (per
                         your original email -
       include="field.nestedField") but
                         this would allow us to keep a configuration
       that is
              very
                         close to what we have now.

                         Kyle Pinette wrote:

                             After having thought through your idea,
       I think it
                             would be pretty useful.  For instance,
       suppose we
                             built it so that you could define different
                             "skeletons", and also define a default.
        Most
              people
                             would probably only define a default,
       but there
              is the
                             option of defining others.  I envision being
              able to
                             do something like this:

                             <convert converter="h3"
       match="some.package.User">
                             <layout default="true">
                             <property name="login" />
                             <property name="fullName" />
                             </layout>
                             <layout name="full">
                             <property name="login" />
                             <property name="fullName" />
                             <property name="addresses">
                             <property name="address1" />
                             <property name="city" />
                             <property name="state" />
                             </property>
                             </layout>
                             </convert>

                             Something like that would be pretty
       useful I think.
                              It takes care of nested inclusions /
       exclusions
                             (although my example shows inclusions), and
              allows you
                             to define different layouts for the object.

                             Kyle Pinette


                             On Wed, Jul 8, 2009 at 10:00 PM, David
       Marginian
                             <david@...
       <mailto:david@...>
              <mailto:david@...
       <mailto:david@...>> <mailto:david@...
       <mailto:david@...>
              <mailto:david@... <mailto:david@...>>>

                             <mailto:david@...
       <mailto:david@...>
              <mailto:david@... <mailto:david@...>>
                             <mailto:david@...
       <mailto:david@...>
              <mailto:david@...
       <mailto:david@...>>>>> wrote:

                                Yes, I think you are following me, and I
              think I am
                             being thick
                                :).  This is probably not as common of a
              problem as
                             I originally
                                thought, and I am not sure if we need to
              support it
                             (as I it will
                                most likely complicate things a great
       deal).  I
                             encounter it
                                because I work with a framework at work
              (I'll spare
                             you the
                                details) that can at times generate
       classes
              with a
                             ton of fields.
                                 In most cases I only want to
       serialize a few of
                             the fields, in
                                others I need to display everything.  I
              think the
                             nested
                                inclusion/exlusion feature will solve
       most
              of the
                             problems.

                                Kyle Pinette wrote:

                                    Could you provide some sort of
       example case?
                              Are you saying
                                    not just depending on where the
       object is
                             nested?  For
                                    instance, when you call the
       server you could
                             pass some sort of
                                    parameter specifying whether you want
              the full
                             object or if
                                    you want a trimmed down version.  Is
              this what
                             you're talking
                                    about?  What immediately jumps to
       mind is
                             providing a
                                    configuration where you could define
                             "skeletons" that could be
                                    named, and when you make a call
       to the
              server
                             side, specify
                                    which "skeleton" you want to use.

                                    Kyle Pinette


                                    On Wed, Jul 8, 2009 at 9:29 PM, David
              Marginian
                                    <david@...
       <mailto:david@...>
              <mailto:david@... <mailto:david@...>>
                             <mailto:david@...
       <mailto:david@...>
              <mailto:david@... <mailto:david@...>>>
                             <mailto:david@...
       <mailto:david@...>
              <mailto:david@...
       <mailto:david@...>> <mailto:david@...
       <mailto:david@...>
              <mailto:david@... <mailto:david@...>>>>
                                    <mailto:david@...
       <mailto:david@...>
              <mailto:david@... <mailto:david@...>>
                             <mailto:david@...
       <mailto:david@...>
              <mailto:david@... <mailto:david@...>>>
                             <mailto:david@...
       <mailto:david@...>
              <mailto:david@... <mailto:david@...>>
                             <mailto:david@...
       <mailto:david@...>
              <mailto:david@...
       <mailto:david@...>>>>>> wrote:

                                       Thanks Kyle.  Perhaps I am
       complicating
                             things here but I think
                                       any solution needs to not just
              account for
                             nested
                                       inclusion/exlusions but also
       some way to
                             specify converters for
                                       for the same class that can be
       used in
                             situations.  For
                                    example a
                                       common issue I have encountered is
                             displaying summary data
                                    in some
                                       instances and the full object
       in others.
                              Currently there is no
                                       way to do this without
       creating a wrapper
                             and specifying
                                    another
                                       converter for the wrapper.
                                       Kyle Pinette wrote:

                                           Hey Everyone,

                                           I've been using DWR for an
              intranet site
                             I'm building
                                    for my
                                           company.  One thing I've
       run into
              that
                             would be nice to
                                    have
                                           is the idea of nested
       inclusions /
                             exclusions.  See
                                                                     http://bugs.directwebremoting.org/bugs/browse/DWR-398.
                                            Essentially, depending on
       where the
                             object is nested,
                                    allow
                                           certain inclusions /
       exclusions.
               This
                             will allow the
                                           developer to choose what
       level of
              detail
                             they want for the
                                           objects returned from the
       server,
                             depending on where they
                                           exist in the object tree.
        This
              would be
                             especially helpful
                                           with Hibernate.  Hibernate
       makes
              it so
                             easy to create
                                           relationships between all
       of your
                             objects.  Depending
                                    on what
                                           operations you are performing,
              you may
                             want only a certain
                                           level of detail.  There is
       no way to
                             control this directly
                                           currently.  I am digging
       through
              the DWR
                             source now, to
                                           re-familiarize myself (I
       was familiar
                             with 2.0).  I'd
                                    like to
                                           implement a solution for this
              problem,
                             but wanted to
                                    get some
                                           opinions first.

                                           Thanks!

                                           Kyle Pinette



                                                                       ---------------------------------------------------------------------
                                       To unsubscribe, e-mail:
                             dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                             <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>
                                          <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                             <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>>
                                                   <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                             <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>
                                          <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                             <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>>>

                                       For additional commands, e-mail:
                             dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>
                             <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>>
                                    <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>
                             <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>>>
                                             <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>
                             <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>>
                                    <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>
                             <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>>>>




                                                          ---------------------------------------------------------------------
                                To unsubscribe, e-mail:
                             dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                             <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>
                                      <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                             <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>>
                                For additional commands, e-mail:
                             dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>
                             <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>>
                                <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>
                             <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>>>




                                     ---------------------------------------------------------------------
                         To unsubscribe, e-mail:
              dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
                         <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
              <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>>
                         For additional commands, e-mail:
              dev-help@...
       <mailto:dev-help@...>
       <mailto:dev-help@...
       <mailto:dev-help@...>>
                         <mailto:dev-help@...
       <mailto:dev-help@...>
              <mailto:dev-help@...
       <mailto:dev-help@...>>>






                ---------------------------------------------------------------------
          To unsubscribe, e-mail: dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>
          <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>
          For additional commands, e-mail: dev-help@...
       <mailto:dev-help@...>
          <mailto:dev-help@...
       <mailto:dev-help@...>>




   ---------------------------------------------------------------------
   To unsubscribe, e-mail: dev-unsubscribe@...
   <mailto:dev-unsubscribe@...>
   For additional commands, e-mail: dev-help@...
   <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[davidmarginian]

3.0 RC2.  But there is only one issue for that release and it is
something that I wanted some feedback from Joe on.  Focus on 3.0 issues.

Kyle Pinette wrote:

> David,
>
> What area should I focus on? What release are you guys working on? 3.0
> RC2?
>
> Kyle Pinette
>
>
> On Sun, Jul 26, 2009 at 5:49 PM, David Marginian <david@...
> <mailto:david@...>> wrote:
>
>     Yes, we could use some help.  Take a look at the issue queue and
>     if you see anything you are comfortable working let the assignee know.
>
>     Kyle Pinette wrote:
>
>         Cool, sounds good.  I will keep brainstorming.  Do you need
>         any help with bugs for 3.0?
>
>         Kyle Pinette
>
>
>         On Sun, Jul 26, 2009 at 11:22 AM, David Marginian
>         <david@... <mailto:david@...>
>         <mailto:david@... <mailto:david@...>>> wrote:
>
>            Kyle,
>             Although not essential being able to specify a converter (this
>            would only apply to outbound) for an exposed method may be
>         a nice
>            feature.  For the situation I wrote about earlier (and
>         decided is
>            probably not that big of a deal), when you have an object with
>            many fields and in some cases you only need a few of those
>         fields
>            and in others you want all of them. I do not use google
>         talk but I
>            have skype and would be happy to use google talk as well.
>          But, I
>            would like to keep this on the back burner until we get a 3.0
>            release out.  Lets keep the thought process going here though.
>
>            Kyle Pinette wrote:
>
>                Gotcha.  So, this would be in addition to the already
>         existing
>                inclusion / exclusions?  I think we could certainly
>         build it
>                that way, we would just need to create a separate way to
>                configure the new inclusions / exclusions.  Wouldn't it be
>                enough to just allow them to specify more advanced
>         inclusions
>                / exclusions for the converters?  Do we need to involve the
>                creators at all?  Do you have google talk or anything like
>                that?  We should have a meeting some time to figure out
>                exactly what needs to be done.
>
>                Kyle Pinette
>
>
>                On Fri, Jul 24, 2009 at 11:41 PM, David Marginian
>                <david@... <mailto:david@...>
>         <mailto:david@... <mailto:david@...>>
>                <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>> wrote:
>
>                   A creator exposes a class, the converters would have
>         to be
>                   attached on the methods exposed not the class
>         itself.  So a
>                user
>                   would have to configure all of the exposed methods
>         (which
>                is not
>                   required now) and specify both an inbound and an
>         outbound
>                   converter for each method (sounds like a lot of
>                configuration). We
>                   need to ensure our solution is backwards compatible and
>                won't in
>                   the long run require more configuration than we have now
>                just to
>                   handle a few edge cases.  I will start putting more
>         thought
>                into
>                   this but most of my effort now has been trying to
>         get a solid
>                   release out.
>                   Kyle Pinette wrote:
>
>                       My Ideas:
>
>                       - For the creator, what if we allow a user to
>         specify a
>                       convertInbound / convertOutbound method for
>         their creator.
>                        The convertOutbound method could simply return a
>                JsonObject
>                       which would then be converted to its final JSON
>         state
>                by the
>                       converter.  Obviously the convertInbound (which
>         I think
>                would
>                       be used far less than convertOutbound) would
>         just return an
>                       Object, given the specified JsonObject.
>
>                       - Create a type which represents the structure
>         of the
>                object
>                       that is to be created by the convertOutbound
>         method for the
>                       converter.  Something like this:
>
>                       public class ObjectMap
>                       {
>                       Map<String, ObjectMap> properties = new
>         HashMap<String,
>                       ObjectMap>();
>                       }
>
>                       The object map could be passed along (in the
>                outboundContext)
>                       to each convertOutbound call for each level of the
>                hierarchy.
>                        The object map could represent inclusions or
>         exclusions.
>                        This means, there wouldn't need to be huges changes
>                made to
>                       the current logic.  We would just need to change the
>                way the
>                       getPropertyMapFromObject works. We would need an
>         overload
>                       where we could pass in our object map for the
>         current
>                level in
>                       the hierarchy.  That would mean the inclusions /
>         exclusions
>                       for the class would be ignored, and the inclusions /
>                       exclusions passed in would be used.
>
>                       As far as the specific configuration mechanisms are
>                concerned,
>                       I will have to get more familiar with how
>         configuration is
>                       managed.
>
>                       Kyle Pinette
>
>
>                       On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette
>                       <sowelie@... <mailto:sowelie@...>
>         <mailto:sowelie@... <mailto:sowelie@...>>
>                <mailto:sowelie@... <mailto:sowelie@...>
>         <mailto:sowelie@... <mailto:sowelie@...>>>
>                       <mailto:sowelie@...
>         <mailto:sowelie@...> <mailto:sowelie@...
>         <mailto:sowelie@...>>
>                <mailto:sowelie@... <mailto:sowelie@...>
>         <mailto:sowelie@... <mailto:sowelie@...>>>>> wrote:
>
>                          That sounds good.  I am going to be looking
>         at the
>                current code
>                          and coming up with some ideas tonight.
>
>                          Kyle Pinette
>
>
>
>                          ---------- Forwarded message ----------
>                          From: *Mike Wilson* <mikewse@...
>         <mailto:mikewse@...>
>                <mailto:mikewse@... <mailto:mikewse@...>>
>                       <mailto:mikewse@...
>         <mailto:mikewse@...>
>                <mailto:mikewse@...
>         <mailto:mikewse@...>>> <mailto:mikewse@...
>         <mailto:mikewse@...>
>                <mailto:mikewse@... <mailto:mikewse@...>>
>                       <mailto:mikewse@...
>         <mailto:mikewse@...> <mailto:mikewse@...
>         <mailto:mikewse@...>>>>>
>                          Date: Tue, Jul 21, 2009 at 8:23 PM
>                          Subject: RE: [dwr-dev] Changes to Exclusions /
>                Inclusions
>                          To: dev@...
>         <mailto:dev@...>
>                <mailto:dev@...
>         <mailto:dev@...>> <mailto:dev@...
>         <mailto:dev@...>
>                <mailto:dev@...
>         <mailto:dev@...>>>
>                       <mailto:dev@...
>         <mailto:dev@...>
>                <mailto:dev@...
>         <mailto:dev@...>> <mailto:dev@...
>         <mailto:dev@...>
>                <mailto:dev@...
>         <mailto:dev@...>>>>
>
>
>                          There may be some previous thinking done in this
>                area. Lance or
>                          Randy: didn't one of you suggest some
>         mechanism for
>                       specifying a
>                          different set of included data properties when a
>                class is sent
>                          through a specific method? And Jose: I
>         remember some
>                       suggestion of
>                          yours about controlling the set of included data
>                properties in
>                          class hierarchies?
>                              Anyway Kyle, I think your suggestion should
>                include the
>                       following:
>
>                             *
>                                a data structure for how to store
>         converters
>                setups
>                                and overrides
>                             *
>                                an algorithm for how to navigate and make
>                decisions
>                       from the
>                                data structure
>                             *
>                                handling of cases where a creator wants
>                specific control
>                                (override) over a certain converted class
>                             *
>                                handling of cases where a converter
>         wants specific
>                                control (override) over a certain member's
>                converted
>                       class
>                                (possibly several levels down in the
>         member graph)
>
>                          Best regards
>                          Mike
>
>                                        
>          ------------------------------------------------------------------------
>                              *From:* Kyle Pinette
>         [mailto:sowelie@... <mailto:sowelie@...>
>                <mailto:sowelie@... <mailto:sowelie@...>>
>                       <mailto:sowelie@...
>         <mailto:sowelie@...> <mailto:sowelie@...
>         <mailto:sowelie@...>>>
>                              <mailto:sowelie@...
>         <mailto:sowelie@...>
>                <mailto:sowelie@... <mailto:sowelie@...>>
>         <mailto:sowelie@... <mailto:sowelie@...>
>                <mailto:sowelie@... <mailto:sowelie@...>>>>]
>                              *Sent:* den 9 juli 2009 14:26
>                              *To:* dev@...
>         <mailto:dev@...>
>                <mailto:dev@... <mailto:dev@...>>
>                       <mailto:dev@...
>         <mailto:dev@...>
>                <mailto:dev@...
>         <mailto:dev@...>>> <mailto:dev@...
>         <mailto:dev@...>
>
>                <mailto:dev@... <mailto:dev@...>>
>
>                       <mailto:dev@...
>         <mailto:dev@...>
>                <mailto:dev@...
>         <mailto:dev@...>>>>
>
>                              *Subject:* Re: [dwr-dev] Changes to
>         Exclusions /
>                Inclusions
>
>                              I completely understand that there are other
>                configuration
>                              mechanisms.  I was just using dwr.xml as
>         an example.
>                        Yeah, it
>                              probably would be best to keep the
>         configuration as
>                       similar as
>                              possible to what exists today.  I am
>         going to take a
>                       look at
>                              the underlying configuration, and figure
>         out how
>                we would
>                              implement this.  Once I have a better
>                understanding of
>                       how the
>                              configuration works, I'll present my ideas.
>
>                              Kyle Pinette
>
>
>                              On Wed, Jul 8, 2009 at 11:00 PM, David
>         Marginian
>                              <david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>> <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>>
>                       <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>> <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>>>>> wrote:
>
>                                  As Mike mentioned on the Jira issue,
>         we have
>                to be
>                       careful
>                                  here - dwr.xml is not the only game
>         in town
>                when it
>                       comes
>                                  to configuration (Spring, annotations,
>                guice, etc.
>                       etc.).
>                                   On the surface this seems to be a pretty
>                large change
>                                  which involve a lot of work.  How do
>         you plan on
>                                  specifying which layout to use?  Couldn't
>                the same
>                       thing
>                                  be accomplished by simply giving the
>         converter a
>                       name - e.g.:
>
>                                  <convert converter="h3" name="full"
>                                  match="some.package.User"/>
>                                  <convert converter="h3" name="summary"
>                                  match="some.package.User"/>
>
>                                  Of course we would have to add the nested
>                inclusion
>                       (per
>                                  your original email -
>                include="field.nestedField") but
>                                  this would allow us to keep a
>         configuration
>                that is
>                       very
>                                  close to what we have now.
>
>                                  Kyle Pinette wrote:
>
>                                      After having thought through your
>         idea,
>                I think it
>                                      would be pretty useful.  For
>         instance,
>                suppose we
>                                      built it so that you could define
>         different
>                                      "skeletons", and also define a
>         default.
>                 Most
>                       people
>                                      would probably only define a default,
>                but there
>                       is the
>                                      option of defining others.  I
>         envision being
>                       able to
>                                      do something like this:
>
>                                      <convert converter="h3"
>                match="some.package.User">
>                                      <layout default="true">
>                                      <property name="login" />
>                                      <property name="fullName" />
>                                      </layout>
>                                      <layout name="full">
>                                      <property name="login" />
>                                      <property name="fullName" />
>                                      <property name="addresses">
>                                      <property name="address1" />
>                                      <property name="city" />
>                                      <property name="state" />
>                                      </property>
>                                      </layout>
>                                      </convert>
>
>                                      Something like that would be pretty
>                useful I think.
>                                       It takes care of nested inclusions /
>                exclusions
>                                      (although my example shows
>         inclusions), and
>                       allows you
>                                      to define different layouts for
>         the object.
>
>                                      Kyle Pinette
>
>
>                                      On Wed, Jul 8, 2009 at 10:00 PM,
>         David
>                Marginian
>                                      <david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>>> <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>>
>                                      <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>
>                                      <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>>>>>> wrote:
>
>                                         Yes, I think you are following
>         me, and I
>                       think I am
>                                      being thick
>                                         :).  This is probably not as
>         common of a
>                       problem as
>                                      I originally
>                                         thought, and I am not sure if
>         we need to
>                       support it
>                                      (as I it will
>                                         most likely complicate things
>         a great
>                deal).  I
>                                      encounter it
>                                         because I work with a
>         framework at work
>                       (I'll spare
>                                      you the
>                                         details) that can at times
>         generate
>                classes
>                       with a
>                                      ton of fields.
>                                          In most cases I only want to
>                serialize a few of
>                                      the fields, in
>                                         others I need to display
>         everything.  I
>                       think the
>                                      nested
>                                         inclusion/exlusion feature
>         will solve
>                most
>                       of the
>                                      problems.
>
>                                         Kyle Pinette wrote:
>
>                                             Could you provide some sort of
>                example case?
>                                       Are you saying
>                                             not just depending on
>         where the
>                object is
>                                      nested?  For
>                                             instance, when you call the
>                server you could
>                                      pass some sort of
>                                             parameter specifying
>         whether you want
>                       the full
>                                      object or if
>                                             you want a trimmed down
>         version.  Is
>                       this what
>                                      you're talking
>                                             about?  What immediately
>         jumps to
>                mind is
>                                      providing a
>                                             configuration where you
>         could define
>                                      "skeletons" that could be
>                                             named, and when you make a
>         call
>                to the
>                       server
>                                      side, specify
>                                             which "skeleton" you want
>         to use.
>
>                                             Kyle Pinette
>
>
>                                             On Wed, Jul 8, 2009 at
>         9:29 PM, David
>                       Marginian
>                                             <david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>
>                                      <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>>
>                                      <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>>> <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>>>
>                                            
>         <mailto:david@... <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>
>                                      <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>>
>                                      <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...> <mailto:david@...
>         <mailto:david@...>>>
>                                      <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@... <mailto:david@...>>
>                       <mailto:david@...
>         <mailto:david@...>
>                <mailto:david@...
>         <mailto:david@...>>>>>>> wrote:
>
>                                                Thanks Kyle.  Perhaps I am
>                complicating
>                                      things here but I think
>                                                any solution needs to
>         not just
>                       account for
>                                      nested
>                                                inclusion/exlusions but
>         also
>                some way to
>                                      specify converters for
>                                                for the same class that
>         can be
>                used in
>                                      situations.  For
>                                             example a
>                                                common issue I have
>         encountered is
>                                      displaying summary data
>                                             in some
>                                                instances and the full
>         object
>                in others.
>                                       Currently there is no
>                                                way to do this without
>                creating a wrapper
>                                      and specifying
>                                             another
>                                                converter for the wrapper.
>                                                Kyle Pinette wrote:
>
>                                                    Hey Everyone,
>
>                                                    I've been using DWR
>         for an
>                       intranet site
>                                      I'm building
>                                             for my
>                                                    company.  One thing
>         I've
>                run into
>                       that
>                                      would be nice to
>                                             have
>                                                    is the idea of nested
>                inclusions /
>                                      exclusions.  See
>                                                                      
>                http://bugs.directwebremoting.org/bugs/browse/DWR-398.
>                                                     Essentially,
>         depending on
>                where the
>                                      object is nested,
>                                             allow
>                                                    certain inclusions /
>                exclusions.
>                        This
>                                      will allow the
>                                                    developer to choose
>         what
>                level of
>                       detail
>                                      they want for the
>                                                    objects returned
>         from the
>                server,
>                                      depending on where they
>                                                    exist in the object
>         tree.
>                 This
>                       would be
>                                      especially helpful
>                                                    with Hibernate.
>          Hibernate
>                makes
>                       it so
>                                      easy to create
>                                                    relationships
>         between all
>                of your
>                                      objects.  Depending
>                                             on what
>                                                    operations you are
>         performing,
>                       you may
>                                      want only a certain
>                                                    level of detail.
>          There is
>                no way to
>                                      control this directly
>                                                    currently.  I am
>         digging
>                through
>                       the DWR
>                                      source now, to
>                                                    re-familiarize
>         myself (I
>                was familiar
>                                      with 2.0).  I'd
>                                             like to
>                                                    implement a
>         solution for this
>                       problem,
>                                      but wanted to
>                                             get some
>                                                    opinions first.
>
>                                                    Thanks!
>
>                                                    Kyle Pinette
>
>
>
>                                                                      
>                
>          ---------------------------------------------------------------------
>                                                To unsubscribe, e-mail:
>                                      dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                    
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>
>                                                  
>         <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                    
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>>
>                                                          
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                    
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>
>                                                  
>         <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                    
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>>>
>
>                                                For additional
>         commands, e-mail:
>                                      dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                      <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>
>                                            
>         <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                      <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>>
>                                                    
>          <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                      <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>
>                                            
>         <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                      <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>>>
>
>
>
>
>                                                                  
>         ---------------------------------------------------------------------
>                                         To unsubscribe, e-mail:
>                                      dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                    
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>
>                                              
>         <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                    
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>>
>                                         For additional commands, e-mail:
>                                      dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                      <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>
>                                        
>         <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                      <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>>
>
>
>
>
>                                            
>          ---------------------------------------------------------------------
>                                  To unsubscribe, e-mail:
>                       dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                                
>          <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                       <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>>
>                                  For additional commands, e-mail:
>                       dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>                                  <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                       <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>>
>
>
>
>
>
>
>                        
>         ---------------------------------------------------------------------
>                   To unsubscribe, e-mail:
>         dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                   <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>                   For additional commands, e-mail:
>         dev-help@... <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                   <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>
>
>
>
>          
>          ---------------------------------------------------------------------
>            To unsubscribe, e-mail: dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>            <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>            For additional commands, e-mail: dev-help@...
>         <mailto:dev-help@...>
>            <mailto:dev-help@...
>         <mailto:dev-help@...>>
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@...
>     <mailto:dev-unsubscribe@...>
>     For additional commands, e-mail: dev-help@...
>     <mailto:dev-help@...>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mikewse]

[sorry for the late reply, but vacation and the following full mailboxes take their toll]

 

Yes, I agree with David that we should stay more on the way things are done in the current code wrt how creators and converters delegate work between them, at least for 3.x. That means not introducing a new way of converting data, but rather an updated way of how creators select which converter should handle their data, and what sub-converters should convert another converter's "members".

 

Given that we want to get 3.0 out the door it sounds really great if you'd like to work on other 3.0 issues for the moment. The nested converters thing probably suits better for a post 3.0 version anyway.

 

Best regards

Mike

---

From: Kyle Pinette [mailto:sowelie@...]
Sent: den 25 juli 2009 23:09
To: dev@...
Subject: Re: [dwr-dev] Changes to Exclusions / Inclusions

Gotcha.  So, this would be in addition to the already existing inclusion / exclusions?  I think we could certainly build it that way, we would just need to create a separate way to configure the new inclusions / exclusions.  Wouldn't it be enough to just allow them to specify more advanced inclusions / exclusions for the converters?  Do we need to involve the creators at all?  Do you have google talk or anything like that?  We should have a meeting some time to figure out exactly what needs to be done.

Kyle Pinette

On Fri, Jul 24, 2009 at 11:41 PM, David Marginian <david@...> wrote:

A creator exposes a class, the converters would have to be attached on the methods exposed not the class itself.  So a user would have to configure all of the exposed methods (which is not required now) and specify both an inbound and an outbound converter for each method (sounds like a lot of configuration). We need to ensure our solution is backwards compatible and won't in the long run require more configuration than we have now just to handle a few edge cases.  I will start putting more thought into this but most of my effort now has been trying to get a solid release out.
Kyle Pinette wrote:

My Ideas:

- For the creator, what if we allow a user to specify a convertInbound / convertOutbound method for their creator.  The convertOutbound method could simply return a JsonObject which would then be converted to its final JSON state by the converter.  Obviously the convertInbound (which I think would be used far less than convertOutbound) would just return an Object, given the specified JsonObject.

- Create a type which represents the structure of the object that is to be created by the convertOutbound method for the converter.  Something like this:

public class ObjectMap
{
Map<String, ObjectMap> properties = new HashMap<String, ObjectMap>();
}

The object map could be passed along (in the outboundContext) to each convertOutbound call for each level of the hierarchy.  The object map could represent inclusions or exclusions.  This means, there wouldn't need to be huges changes made to the current logic.  We would just need to change the way the getPropertyMapFromObject works. We would need an overload where we could pass in our object map for the current level in the hierarchy.  That would mean the inclusions / exclusions for the class would be ignored, and the inclusions / exclusions passed in would be used.

As far as the specific configuration mechanisms are concerned, I will have to get more familiar with how configuration is managed.

Kyle Pinette

On Fri, Jul 24, 2009 at 9:30 PM, Kyle Pinette <sowelie@... <mailto:sowelie@...>> wrote:

   That sounds good.  I am going to be looking at the current code
   and coming up with some ideas tonight.

   Kyle Pinette



   ---------- Forwarded message ----------

   From: *Mike Wilson* <mikewse@... <mailto:mikewse@...>>
   Date: Tue, Jul 21, 2009 at 8:23 PM
   Subject: RE: [dwr-dev] Changes to Exclusions / Inclusions

   To: dev@... <mailto:dev@...>


   There may be some previous thinking done in this area. Lance or
   Randy: didn't one of you suggest some mechanism for specifying a
   different set of included data properties when a class is sent
   through a specific method? And Jose: I remember some suggestion of
   yours about controlling the set of included data properties in
   class hierarchies?
       Anyway Kyle, I think your suggestion should include the following:

      *
         a data structure for how to store converters setups
         and overrides
      *
         an algorithm for how to navigate and make decisions from the
         data structure
      *
         handling of cases where a creator wants specific control
         (override) over a certain converted class
      *
         handling of cases where a converter wants specific
         control (override) over a certain member's converted class
         (possibly several levels down in the member graph)

   Best regards
   Mike

       ------------------------------------------------------------------------
       *From:* Kyle Pinette [mailto:sowelie@...
       <mailto:sowelie@...>]
       *Sent:* den 9 juli 2009 14:26

       *To:* dev@... <mailto:dev@...>

       *Subject:* Re: [dwr-dev] Changes to Exclusions / Inclusions

       I completely understand that there are other configuration
       mechanisms.  I was just using dwr.xml as an example.  Yeah, it
       probably would be best to keep the configuration as similar as
       possible to what exists today.  I am going to take a look at
       the underlying configuration, and figure out how we would
       implement this.  Once I have a better understanding of how the
       configuration works, I'll present my ideas.

       Kyle Pinette


       On Wed, Jul 8, 2009 at 11:00 PM, David Marginian

       <david@... <mailto:david@...>> wrote:

           As Mike mentioned on the Jira issue, we have to be careful
           here - dwr.xml is not the only game in town when it comes
           to configuration (Spring, annotations, guice, etc. etc.).
            On the surface this seems to be a pretty large change
           which involve a lot of work.  How do you plan on
           specifying which layout to use?  Couldn't the same thing
           be accomplished by simply giving the converter a name - e.g.:

           <convert converter="h3" name="full"
           match="some.package.User"/>
           <convert converter="h3" name="summary"
           match="some.package.User"/>

           Of course we would have to add the nested inclusion (per
           your original email - include="field.nestedField") but
           this would allow us to keep a configuration that is very
           close to what we have now.

           Kyle Pinette wrote:

               After having thought through your idea, I think it
               would be pretty useful.  For instance, suppose we
               built it so that you could define different
               "skeletons", and also define a default.  Most people
               would probably only define a default, but there is the
               option of defining others.  I envision being able to
               do something like this:

               <convert converter="h3" match="some.package.User">
               <layout default="true">
               <property name="login" />
               <property name="fullName" />
               </layout>
               <layout name="full">
               <property name="login" />
               <property name="fullName" />
               <property name="addresses">
               <property name="address1" />
               <property name="city" />
               <property name="state" />
               </property>
               </layout>
               </convert>

               Something like that would be pretty useful I think.
                It takes care of nested inclusions / exclusions
               (although my example shows inclusions), and allows you
               to define different layouts for the object.

               Kyle Pinette


               On Wed, Jul 8, 2009 at 10:00 PM, David Marginian
               <david@... <mailto:david@...>

               <mailto:david@...
               <mailto:david@...>>> wrote:

                  Yes, I think you are following me, and I think I am
               being thick
                  :).  This is probably not as common of a problem as
               I originally
                  thought, and I am not sure if we need to support it
               (as I it will
                  most likely complicate things a great deal).  I
               encounter it
                  because I work with a framework at work (I'll spare
               you the
                  details) that can at times generate classes with a
               ton of fields.
                   In most cases I only want to serialize a few of
               the fields, in
                  others I need to display everything.  I think the
               nested
                  inclusion/exlusion feature will solve most of the
               problems.

                  Kyle Pinette wrote:

                      Could you provide some sort of example case?
                Are you saying
                      not just depending on where the object is
               nested?  For
                      instance, when you call the server you could
               pass some sort of
                      parameter specifying whether you want the full
               object or if
                      you want a trimmed down version.  Is this what
               you're talking
                      about?  What immediately jumps to mind is
               providing a
                      configuration where you could define
               "skeletons" that could be
                      named, and when you make a call to the server
               side, specify
                      which "skeleton" you want to use.

                      Kyle Pinette


                      On Wed, Jul 8, 2009 at 9:29 PM, David Marginian
                      <david@...
               <mailto:david@...>
               <mailto:david@... <mailto:david@...>>
                      <mailto:david@...
               <mailto:david@...>
               <mailto:david@...
               <mailto:david@...>>>> wrote:

                         Thanks Kyle.  Perhaps I am complicating
               things here but I think
                         any solution needs to not just account for
               nested
                         inclusion/exlusions but also some way to
               specify converters for
                         for the same class that can be used in
               situations.  For
                      example a
                         common issue I have encountered is
               displaying summary data
                      in some
                         instances and the full object in others.
                Currently there is no
                         way to do this without creating a wrapper
               and specifying
                      another
                         converter for the wrapper.
                         Kyle Pinette wrote:

                             Hey Everyone,

                             I've been using DWR for an intranet site
               I'm building
                      for my
                             company.  One thing I've run into that
               would be nice to
                      have
                             is the idea of nested inclusions /
               exclusions.  See
                                           http://bugs.directwebremoting.org/bugs/browse/DWR-398.
                              Essentially, depending on where the
               object is nested,
                      allow
                             certain inclusions / exclusions.  This
               will allow the
                             developer to choose what level of detail
               they want for the
                             objects returned from the server,
               depending on where they
                             exist in the object tree.  This would be
               especially helpful
                             with Hibernate.  Hibernate makes it so
               easy to create
                             relationships between all of your
               objects.  Depending
                      on what
                             operations you are performing, you may
               want only a certain
                             level of detail.  There is no way to
               control this directly
                             currently.  I am digging through the DWR
               source now, to
                             re-familiarize myself (I was familiar
               with 2.0).  I'd
                      like to
                             implement a solution for this problem,
               but wanted to
                      get some
                             opinions first.

                             Thanks!

                             Kyle Pinette



                                             ---------------------------------------------------------------------
                         To unsubscribe, e-mail:
               dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>>
                         <mailto:dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>
                      <mailto:dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>>>

                         For additional commands, e-mail:
               dev-help@...
               <mailto:dev-help@...>
                      <mailto:dev-help@...
               <mailto:dev-help@...>>
                         <mailto:dev-help@...
               <mailto:dev-help@...>
                      <mailto:dev-help@...
               <mailto:dev-help@...>>>




                                ---------------------------------------------------------------------
                  To unsubscribe, e-mail:
               dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>
                  <mailto:dev-unsubscribe@...
               <mailto:dev-unsubscribe@...>>
                  For additional commands, e-mail:
               dev-help@...
               <mailto:dev-help@...>
                  <mailto:dev-help@...
               <mailto:dev-help@...>>




           ---------------------------------------------------------------------
           To unsubscribe, e-mail: dev-unsubscribe@...
           <mailto:dev-unsubscribe@...>
           For additional commands, e-mail: dev-help@...
           <mailto:dev-help@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...