FAQ
Add ability to generate a common interface for client and server classes
------------------------------------------------------------------------

Key: CAY-915
URL: https://issues.apache.org/cayenne/browse/CAY-915
Project: Cayenne
Issue Type: New Feature
Components: CayenneModeler GUI
Affects Versions: 3.0
Reporter: Kevin Menard
Assignee: Andrus Adamchik
Fix For: 3.0


Currently there is a divide between ROP client and server classes. Ultimately, it'd be nice to see some unification of the two. In some applications, however, there is compelling reason to keep two hierarchies separate. In that case, it may still be beneficial to have a common interface that other code can use to interact with both client and server classes.

Off hand, I'm thinking of two new fields to the class generation panel in the modeler:

1) Check box for indicating that the interfaces should be generated
2) A text field for specifying the package to use

This also implies modifications to both the client and server superclass velocity templates.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Search Discussions

  • Anonymous at Nov 6, 2007 at 4:32 pm
    [ https://issues.apache.org/cayenne/browse/CAY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Kevin Menard reassigned CAY-915:
    --------------------------------

    Assignee: Kevin Menard (was: Andrus Adamchik)
    Add ability to generate a common interface for client and server classes
    ------------------------------------------------------------------------

    Key: CAY-915
    URL: https://issues.apache.org/cayenne/browse/CAY-915
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Kevin Menard
    Assignee: Kevin Menard
    Fix For: 3.0


    Currently there is a divide between ROP client and server classes. Ultimately, it'd be nice to see some unification of the two. In some applications, however, there is compelling reason to keep two hierarchies separate. In that case, it may still be beneficial to have a common interface that other code can use to interact with both client and server classes.
    Off hand, I'm thinking of two new fields to the class generation panel in the modeler:
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    This also implies modifications to both the client and server superclass velocity templates.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Anonymous at Nov 6, 2007 at 4:34 pm
    [ https://issues.apache.org/cayenne/browse/CAY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12588 ]

    Kevin Menard commented on CAY-915:
    ----------------------------------

    Also, this would require additional options to the ant and maven plugins.
    Add ability to generate a common interface for client and server classes
    ------------------------------------------------------------------------

    Key: CAY-915
    URL: https://issues.apache.org/cayenne/browse/CAY-915
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Kevin Menard
    Assignee: Kevin Menard
    Fix For: 3.0


    Currently there is a divide between ROP client and server classes. Ultimately, it'd be nice to see some unification of the two. In some applications, however, there is compelling reason to keep two hierarchies separate. In that case, it may still be beneficial to have a common interface that other code can use to interact with both client and server classes.
    Off hand, I'm thinking of two new fields to the class generation panel in the modeler:
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    This also implies modifications to both the client and server superclass velocity templates.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Anonymous at Nov 6, 2007 at 4:36 pm
    [ https://issues.apache.org/cayenne/browse/CAY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12589 ]

    Andrus Adamchik commented on CAY-915:
    -------------------------------------
    Off hand, I'm thinking of two new fields to the class generation panel in the modeler:
    Wouldn't that be a property of an entity? (i.e. you'd want the same interface to be generated regardless of whether you run cgen Ant task, GUI generator, maven, etc.
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    Why not just a field with full interface name?

    Add ability to generate a common interface for client and server classes
    ------------------------------------------------------------------------

    Key: CAY-915
    URL: https://issues.apache.org/cayenne/browse/CAY-915
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Kevin Menard
    Assignee: Kevin Menard
    Fix For: 3.0


    Currently there is a divide between ROP client and server classes. Ultimately, it'd be nice to see some unification of the two. In some applications, however, there is compelling reason to keep two hierarchies separate. In that case, it may still be beneficial to have a common interface that other code can use to interact with both client and server classes.
    Off hand, I'm thinking of two new fields to the class generation panel in the modeler:
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    This also implies modifications to both the client and server superclass velocity templates.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Anonymous at Nov 6, 2007 at 4:44 pm
    [ https://issues.apache.org/cayenne/browse/CAY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12591 ]

    Kevin Menard commented on CAY-915:
    ----------------------------------

    Correct. The interface would be generated based on the properties defined in the entity.

    Unless I'm mistaken, there's one pass to generate super and subclasses for the server and another pass to generate for super and subclasses for the client. What I'm suggesting is a third pass that generates one set of interfaces that will be implemented by the super classes for both server and client. It would yield something like the following:

    com.example.models.interfaces.IPainting

    com.example.models.auto._Painting implements com.example.models.interfaces.IPainting
    com.example.models.client.auto._Painting implements com.example.models.interfaces.IPainting

    The subclasses would extend from the superclass as usual.

    As per the other generation steps, this should be configurable.

    If this sounds like a bad approach, we can discuss better design options on the dev list.
    Add ability to generate a common interface for client and server classes
    ------------------------------------------------------------------------

    Key: CAY-915
    URL: https://issues.apache.org/cayenne/browse/CAY-915
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Kevin Menard
    Assignee: Kevin Menard
    Fix For: 3.0


    Currently there is a divide between ROP client and server classes. Ultimately, it'd be nice to see some unification of the two. In some applications, however, there is compelling reason to keep two hierarchies separate. In that case, it may still be beneficial to have a common interface that other code can use to interact with both client and server classes.
    Off hand, I'm thinking of two new fields to the class generation panel in the modeler:
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    This also implies modifications to both the client and server superclass velocity templates.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Anonymous at Nov 6, 2007 at 4:56 pm
    [ https://issues.apache.org/cayenne/browse/CAY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12592 ]

    Andrus Adamchik commented on CAY-915:
    -------------------------------------

    Got it now. So the package referred to the "auto" classes, not the interface. makes sense.
    Add ability to generate a common interface for client and server classes
    ------------------------------------------------------------------------

    Key: CAY-915
    URL: https://issues.apache.org/cayenne/browse/CAY-915
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Kevin Menard
    Assignee: Kevin Menard
    Fix For: 3.0


    Currently there is a divide between ROP client and server classes. Ultimately, it'd be nice to see some unification of the two. In some applications, however, there is compelling reason to keep two hierarchies separate. In that case, it may still be beneficial to have a common interface that other code can use to interact with both client and server classes.
    Off hand, I'm thinking of two new fields to the class generation panel in the modeler:
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    This also implies modifications to both the client and server superclass velocity templates.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Kevin Menard at Nov 6, 2007 at 9:39 pm
    Given that my work essentially blocked on this issue, I've dug into it a bit
    this afternoon. It looks like everything works, but requires some invasive
    changes that I wanted to float on the list before committing.

    DataMap:

    * Add new "interfacesSupported" property
    * Add new "defaultInterfacesPackage" property

    ObjEntity:

    * Add new "interfaceName" attribute
    * Add new "noInterface" attribute (although, I think I'm going to remove
    this)

    With that in place, an interface.vm can generate the interface with the
    existing superclass templates conditionally implementing the interface.

    To be really clean, there should probably be some mods to EntityUtils, but
    I've been able to make everything work without changes to it.

    Initially I was allowing ObjEntities to declare that no interface should be
    generated for them, but it really of questionable value. And it becomes a
    bit problematic because the generated interfaces and superclasses really
    need to operate with the other interfaces for relationships. Otherwise, the
    whole process is pretty shallow and only works for the simplest of cases.

    This is my first real work with the datamap and objentity structure and my
    velocity skills are practically non-existent. So, if the overall design is
    "approved" and I check the code in, I would appreciate a set of eyes or two
    to give it a quick review.

    Thanks,
    Kevin

    On 11/6/07 11:55 AM, "Andrus Adamchik (JIRA)" wrote:


    [
    https://issues.apache.org/cayenne/browse/CAY-915?page=com.atlassian.jira.plugi
    n.system.issuetabpanels:comment-tabpanel#action_12592 ]

    Andrus Adamchik commented on CAY-915:
    -------------------------------------

    Got it now. So the package referred to the "auto" classes, not the interface.
    makes sense.
    Add ability to generate a common interface for client and server classes
    ------------------------------------------------------------------------

    Key: CAY-915
    URL: https://issues.apache.org/cayenne/browse/CAY-915
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Kevin Menard
    Assignee: Kevin Menard
    Fix For: 3.0


    Currently there is a divide between ROP client and server classes.
    Ultimately, it'd be nice to see some unification of the two. In some
    applications, however, there is compelling reason to keep two hierarchies
    separate. In that case, it may still be beneficial to have a common
    interface that other code can use to interact with both client and server
    classes.
    Off hand, I'm thinking of two new fields to the class generation panel in the
    modeler:
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    This also implies modifications to both the client and server superclass
    velocity templates.
    --
  • Anonymous at Nov 6, 2007 at 9:48 pm
    [ https://issues.apache.org/cayenne/browse/CAY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12593 ]

    Ari Maniatis commented on CAY-915:
    ----------------------------------

    I'm not seeing the "compelling reason to keep two hierarchies separate". Would it not be always better to have a common superclass for both client and server? I know it would make a huge amount of my code much much easier to deal with (for example, we implement validation on both client and server side since we want real time validation without a trip to the server).

    I know this common superclass approach is lots of work, but shouldn't that be the goal?
    Add ability to generate a common interface for client and server classes
    ------------------------------------------------------------------------

    Key: CAY-915
    URL: https://issues.apache.org/cayenne/browse/CAY-915
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Kevin Menard
    Assignee: Kevin Menard
    Fix For: 3.0


    Currently there is a divide between ROP client and server classes. Ultimately, it'd be nice to see some unification of the two. In some applications, however, there is compelling reason to keep two hierarchies separate. In that case, it may still be beneficial to have a common interface that other code can use to interact with both client and server classes.
    Off hand, I'm thinking of two new fields to the class generation panel in the modeler:
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    This also implies modifications to both the client and server superclass velocity templates.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Kevin Menard at Nov 6, 2007 at 9:57 pm
    I think it's a difference of approach. Largely, I agree with you. The two
    different hierarchies is the root of the problem for me.

    Andrus had mentioned a use case of wanting to keep some methods out of only
    the client class or the server class. My take on it is that obj-attributes
    could be annotated as such and the validation system could handle this. On
    the other hand, I can see a lot of value of not having a setXYZ() method in
    a client class, for example, if calling such would always lead to a
    validation failure.

    So, ultimately, I'm working towards a single hierarchy. There's a lot of
    code there I'm not familiar with though and if the interface approach is
    incremental and still useful after the fact for certain use cases, then
    great for me :-)

    --
    Kevin

    On 11/6/07 4:47 PM, "Ari Maniatis (JIRA)" wrote:


    [
    https://issues.apache.org/cayenne/browse/CAY-915?page=com.atlassian.jira.plugi
    n.system.issuetabpanels:comment-tabpanel#action_12593 ]

    Ari Maniatis commented on CAY-915:
    ----------------------------------

    I'm not seeing the "compelling reason to keep two hierarchies separate". Would
    it not be always better to have a common superclass for both client and
    server? I know it would make a huge amount of my code much much easier to deal
    with (for example, we implement validation on both client and server side
    since we want real time validation without a trip to the server).

    I know this common superclass approach is lots of work, but shouldn't that be
    the goal?
    Add ability to generate a common interface for client and server classes
    ------------------------------------------------------------------------

    Key: CAY-915
    URL: https://issues.apache.org/cayenne/browse/CAY-915
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Kevin Menard
    Assignee: Kevin Menard
    Fix For: 3.0


    Currently there is a divide between ROP client and server classes.
    Ultimately, it'd be nice to see some unification of the two. In some
    applications, however, there is compelling reason to keep two hierarchies
    separate. In that case, it may still be beneficial to have a common
    interface that other code can use to interact with both client and server
    classes.
    Off hand, I'm thinking of two new fields to the class generation panel in the
    modeler:
    1) Check box for indicating that the interfaces should be generated
    2) A text field for specifying the package to use
    This also implies modifications to both the client and server superclass
    velocity templates.
    --
  • Aristedes Maniatis at Nov 6, 2007 at 10:11 pm

    On 07/11/2007, at 8:56 AM, Kevin Menard wrote:

    I think it's a difference of approach. Largely, I agree with you.
    The two
    different hierarchies is the root of the problem for me.
    Sure, and for many other people as well.

    Andrus had mentioned a use case of wanting to keep some methods out
    of only
    the client class or the server class. My take on it is that obj-
    attributes
    could be annotated as such and the validation system could handle
    this. On
    the other hand, I can see a lot of value of not having a setXYZ()
    method in
    a client class, for example, if calling such would always lead to a
    validation failure.
    Sure, that could be a check box for each attribute, but isn't that
    different to what is being discussed here?
    So, ultimately, I'm working towards a single hierarchy. There's a
    lot of
    code there I'm not familiar with though and if the interface
    approach is
    incremental and still useful after the fact for certain use cases,
    then
    great for me :-)
    My concern is that this might be the wrong path to go down if we are
    ultimately aiming for a common superclass PersistentObject. But your
    first comment made it seem like there were reasons to not aim for
    that. For the particular case you need this for now, could you do
    what you want with just changes to the velocity templates and nothing
    else? I know we've hacked ours to provide quite a few extra features.

    Ari Maniatis



    -------------------------->
    Aristedes Maniatis
    phone +61 2 9660 9700
    PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
  • Kevin Menard at Nov 6, 2007 at 10:29 pm

    On 11/6/07 5:11 PM, "Aristedes Maniatis" wrote:

    So, ultimately, I'm working towards a single hierarchy. There's a
    lot of
    code there I'm not familiar with though and if the interface
    approach is
    incremental and still useful after the fact for certain use cases,
    then
    great for me :-)
    My concern is that this might be the wrong path to go down if we are
    ultimately aiming for a common superclass PersistentObject. But your
    first comment made it seem like there were reasons to not aim for
    that. For the particular case you need this for now, could you do
    what you want with just changes to the velocity templates and nothing
    else? I know we've hacked ours to provide quite a few extra features.
    True, but if we are going to keep the option of having different
    hierarchies, then it could still be worthwhile to generate a common set of
    interfaces for them. Maybe not so much to make the effort worthwhile
    though.

    I'm also open to the notion that I may be going about this the wrong way.
    I'm not a velocity expert, so maybe it's possible to do this otherwise.
    What I was shooting for was to have the generator create the interface based
    upon the ObjEntity. The superclasses in each hierarchy would implement the
    interface. Then most code could just work with that interface.

    If it's possible to achieve that without the approach I'm taking, I'm all
    ears.

    --
    Kevin
  • Kevin Menard at Nov 7, 2007 at 12:18 am
    Thinking about things a bit more, I think I'll try my hand at unifying the
    two hierarchies. I have a much better handle on the problem now. Plus,
    unforeseen issues with the interface approach were starting to spring up.

    I'll report back on what I accomplish.

    --
    Kevin

    On 11/6/07 5:11 PM, "Aristedes Maniatis" wrote:


    My concern is that this might be the wrong path to go down if we are
    ultimately aiming for a common superclass PersistentObject. But your
    first comment made it seem like there were reasons to not aim for
    that. For the particular case you need this for now, could you do
    what you want with just changes to the velocity templates and nothing
    else? I know we've hacked ours to provide quite a few extra features.

    Ari Maniatis

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedNov 6, '07 at 4:30p
activeNov 7, '07 at 12:18a
posts12
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase