[Cayenne-dev] [JIRA] Created: (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:all-tabpanel ]

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

Assignee: Kevin Menard (was: Andrus Adamchik)

[ 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.

[ 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:
-------------------------------------
Why not just a field with full interface name?

[ 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.

[ 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.

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

[ 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?

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 :-)

Sure, and for many other people as well.

Sure, that could be a check box for each attribute, but isn't that
different to what is being discussed here?
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

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.

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.