Hi Dima, It sounds like this feature is moving in a pretty good direction already.
The biggest reason I've had 2+ DataMaps in a project before is when I had to connect to multiple DBs. I admit this is more of a rare case, but does happen at times. I still think storing the template in the DataDomain has a bit more advantage, too. Let's say you have a MySQL and PostgreSQL DB that you are using and have two DataMaps (and DataNodes), one for each DB. If you want a custom template for your entities and you want them to be the same template, having it stored in the DataDomain means you don't have to have two copies of the same template (one copy in each DataMap), which could accidentally become out-of-sync with each other if you edit one and not the other. Thanks! mrg On Sat, Apr 2, 2016 at 3:16 AM, Dzmitry Kazimirchyk <dkazimirc...@gmail.com> wrote: > Just want to note that Github pull request linked to the task contains > many of the changes being discussed in this thread. > > Namely, custom templates can now be added and edited using Modeler GUI. > Template *.vm files are saved with the rest of the Cayenne project files, > so all developers can share same template config without additional effort. > > > On 4/1/16 6:07 AM, Michael Gentry wrote: > >> I'm thinking it might be better to do the following: >> >> * Define custom templates in the DataDomain. >> >> * Specify custom template to use in the DataMap. >> > > I see that the proposed change keeps custom template definitions in > DataMap *.map.xml files. I can see how keeping them in data domain file > instead might be beneficial, but I've never really used multiple data maps > in single project myself, so not sure about any potential issues with this > approach. > > >> * Allow overrides for each ObjEntity (just in case you want a specify a >> given ObjEntity to use a different template). >> > > This is not implemented per the pull request, but might be interesting > idea for the future. > > >> * Save the templates and settings as part of the project files themselves >> instead of individual preferences. >> > > The proposed change does exactly that. > > > On Apr 1, 2016, at 10:03 AM, Adrian A. <a.adrian.t...@googlemail.com> >> wrote: >> >> What about both? I.e. to have "global" templates, that are saved in >> user preferences (so that the user needs to define them only once), >> and when a project is created, copy them in the project files, so that >> they can be shared? >> > > I believe this is exactly how it works with the proposed pull request > changes applied. > > An "Import" button on the DataDomain might be more intuitive or obvious to >> most people. I know I hardly ever go into preferences. A button you see >> more often is more likely to be used and remembered, plus you can still >> have you global file, too. >> > > That might be a good improvement to consider as well. > > > Dima > > > > On 4/1/16 5:04 PM, Michael Gentry wrote: > >> An "Import" button on the DataDomain might be more intuitive or obvious >> to most people. I know I hardly ever go into preferences. A button you see >> more often is more likely to be used and remembered, plus you can still >> have you global file, too. >> >> Thanks, >> >> mrg >> >> >> Sent from my iPad >> >> On Apr 1, 2016, at 10:03 AM, Adrian A. <a.adrian.t...@googlemail.com> >>> wrote: >>> >>> What about both? I.e. to have "global" templates, that are saved in >>> user preferences (so that the user needs to define them only once), >>> and when a project is created, copy them in the project files, so that >>> they can be shared? >>> >>> This way, it will work for other users too that just open the project, >>> but still have the advantage the the user does not need to copy and >>> paste them allot. >>> >>> On Fri, Apr 1, 2016 at 3:07 PM, Michael Gentry <blackn...@gmail.com> >>>> wrote: >>>> This issue talks about custom Velocity templates: >>>> >>>> https://issues.apache.org/jira/browse/CAY-2069 >>>> >>>> From playing around in the Modeler: >>>> >>>> * In Preferences, add a custom template that resides somewhere on your >>>> filesystem and give it a symbolic name. >>>> >>>> * When generating classes, go to the Advanced option and make sure you >>>> select the custom templates (via your local symbolic name) before you >>>> generate. >>>> >>>> Pros: >>>> >>>> * Can specify custom templates in CM's preferences. >>>> >>>> Cons: >>>> >>>> * The custom template preferences are for a given developer only. Other >>>> developers will need to make sure they create custom template >>>> preferences >>>> and make sure they know to use the advanced option on generation, two >>>> steps >>>> easy to overlook. >>>> >>>> * The custom template isn't specified at all in the CM project files. >>>> >>>> >>>> I'm thinking it might be better to do the following: >>>> >>>> * Define custom templates in the DataDomain. >>>> >>>> * Specify custom template to use in the DataMap. >>>> >>>> * Allow overrides for each ObjEntity (just in case you want a specify a >>>> given ObjEntity to use a different template). >>>> >>>> * Save the templates and settings as part of the project files >>>> themselves >>>> instead of individual preferences. >>>> >>>> >>>> Pros: >>>> >>>> * Can still specify custom templates in CM, just not in preferences. >>>> >>>> * Since the custom templates are part of the project, other developers >>>> on >>>> the team don't have to remember to set up their preferences or remember >>>> to >>>> use the advanced code generation and select the proper templates -- that >>>> will be handled in the DataDomain and DataMap and persisted in the >>>> project >>>> files. >>>> >>>> * If using cgen, it should see the templates that are required in the >>>> project for each map/entity and you wouldn't have to specify additional >>>> settings -- it could automatically handle it. >>>> >>>> * If your project has multiple DataMaps, it is easier to specify >>>> different >>>> templates for each map, if desired, and easier to see it visually in CM >>>> and >>>> know what's going on. >>>> >>>> Cons: >>>> >>>> * Will be harder to edit the template data, potentially -- can't just >>>> edit >>>> a plain text file, although you could copy the contents out of CM, paste >>>> into an editor, make changes, then copy/paste back into CM. Or, just >>>> edit >>>> in-place in CM. >>>> >>>> * Template data will be in the project files, which will get deployed to >>>> production. Of course, will face the same issue/concern with adding >>>> JavaDoc, etc, to CM as well. I don't see the extra size of the project >>>> file being a concern, though, and can't think of a security issue with >>>> it >>>> being there, either. >>>> >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> >>>> mrg >>>> >>>
