Re: [JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
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" <[EMAIL PROTECTED]> 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
Re: [JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
On 11/6/07 5:11 PM, "Aristedes Maniatis" <[EMAIL PROTECTED]> 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
Re: [JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
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
Re: [JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
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. --
[JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
[ 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.
Re: [JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
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. --
[JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
[ 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.
[JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
[ 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.
[JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
[ 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.
[JIRA] Commented: (CAY-915) Add ability to generate a common interface for client and server classes
[ 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.
