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)" <[email protected]> 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. --
