Community
Participate
Working Groups
Jim: > Not a problem, but you can’t use "Application" or "Service" as a resource names as they conflict on import with the generated servlet name Application.java and Service.java. The boiler plate class names should use some prefix to avoid class name collisions like that - allowing the modeler to use the good names. Jad: > The domain prefix can be used. I do similar thing if a resource has 2 properties with the same name (from different Domains). There are 2 parts: (1) avoid Java keywords which we can list out for all adaptors (2) avoid application-specific terms that might turn out in the code of the adaptor. For the latter, I need to give the modeller a way to give such a list. Andrew: > The clash will happen with any class name you have imported in the template. E.g. ApplicationDSR (DSR for Domain Spec Resource). Also, if you have defined an RDF prefix, we can add a prefix to the class as well. ‘oslc_rm:Application’ can become OslcRmApplicationDSR. I know it’s ugly but will certainly help. We can then allow resources with the strangest names like Object and Class.
Eclipse has wrapping problems: Jim: > Not a problem, but you can’t use "Application" or "Service" as a resource > names as they conflict on import with the generated servlet name > Application.java and Service.java. The boiler plate class names should use some > prefix to avoid class name collisions like that - allowing the modeler to use > the good names. Jad: > The domain prefix can be used. I do similar thing if a resource has 2 > properties with the same name (from different Domains). There are 2 parts: (1) > avoid Java keywords which we can list out for all adaptors (2) avoid > application-specific terms that might turn out in the code of the adaptor. For > the latter, I need to give the modeller a way to give such a list. Andrew: > The clash will happen with any class name you have imported in the template. > E.g. ApplicationDSR (DSR for Domain Spec Resource). Also, if you have defined an > RDF prefix, we can add a prefix to the class as well. ‘oslc_rm:Application’ can > become OslcRmApplicationDSR. I know it’s ugly but will certainly help. We can > then allow resources with the strangest names like Object and Class.
We should only add prefixes to the boiler plate class names if there is a conflict. Reason: In most cases, the models do not contain "Application" terms, and it would be a pity to make the class names cumbersome.
I'm happy enough to put the prefix on the resource names in the domain specification.
(In reply to Jim Amsden from comment #3) > I'm happy enough to put the prefix on the resource names in the domain > specification. Then it means you would be comfortable with a stop-list of resource names in the modelling tool?
If by stop-list you mean a list of reserved names that should not be used for domain specification resource names, then yes.
But I would recommend avoiding using good names like Application and Service for class names in generated code. That is avoid, reserving good names by adding your own prefix: TcgApplication, TcgService (for Toolchain Generator). This leave the good names available for users models and reduces the possibility of collisions.
(In reply to Jim Amsden from comment #6) > But I would recommend avoiding using good names like Application and Service > for class names in generated code. That is avoid, reserving good names by > adding your own prefix: TcgApplication, TcgService (for Toolchain > Generator). This leave the good names available for users models and reduces > the possibility of collisions. I actually like the idea because once accustomed, developers will easily distinguish the custom code from the generated one. And it will leave the nice names available to the developer, as you have pointed out.
(In reply to Jim Amsden from comment #6) > But I would recommend avoiding using good names like Application and Service > for class names in generated code. That is avoid, reserving good names by > adding your own prefix: TcgApplication, TcgService (for Toolchain > Generator). This leave the good names available for users models and reduces > the possibility of collisions. Good idea actually. i now get your main point Jim! Luckily, the only "bad" names we have to fix is Application (might as well avoid "ServletListener"). All other class names are quite specific.
New Gerrit change created: https://git.eclipse.org/r/100861
Gerrit change https://git.eclipse.org/r/100861 was merged to [master]. Commit: http://git.eclipse.org/c/lyo/org.eclipse.lyo.tools.git/commit/?id=d0e5c10928eca097c6421e82954c1bc0b7cf62ab
