Custom Templates

[Michael Gentry <bl...@gmail.com>]

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

Re: Custom Templates

[John Huss <jo...@gmail.com>]

Sounds good to me!

On Fri, Apr 1, 2016 at 9:03 AM Adrian A. <a....@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 <bl...@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
>

Re: Custom Templates

[Mike Kienenberger <mk...@gmail.com>]

I overlooked the part where you said it was a single file.

It is not convenient to edit velocity files inside xml data sections :)

Neither an xml editor nor a velocity editor will work well with those options.

On Fri, Apr 8, 2016 at 12:52 PM, Michael Gentry <bl...@gmail.com> wrote:
> Well, my thought was to have just one XML file with all of the template
> data in it: all custom templates, all JavaDocs, all annotations, and all
> custom imports (mainly to support the annotations).  Basically a bunch of
> CDATA sections to store each piece, plus the surrounding markup to identify
> what it is supporting, of course.
>
> Everything would still be under version control and could still be edited
> with an external tool, just not as conveniently.  Basically, find the CDATA
> section you want to edit and change it.
>
> mrg
>
>
> On Fri, Apr 8, 2016 at 11:22 AM, Mike Kienenberger <mk...@gmail.com>
> wrote:
>
>> More pros:
>>
>> * Templates be edited by an external tool without having to export the
>> original data then import it after making changes.
>>
>> * Individual templates remain under version control.
>>
>>
>> On Fri, Apr 8, 2016 at 11:12 AM, Michael Gentry <bl...@gmail.com>
>> wrote:
>> > So, I've had another thought on this ...
>> >
>> > We could store the custom templates, JavaDoc, etc. in a separate XML
>> file.
>> > This information is really only useful for class generation, either in
>> > Cayenne Modeler or cgen.
>> >
>> >
>> > Pros:
>> >
>> > * Class generation data wouldn't clutter up the current XML mapping file.
>> > * Separate file can be omitted/excluded by the build tool, such as Maven,
>> > so it isn't packaged up in your JAR/WAR for deployment.
>> > * Class generation data wouldn't get loaded at run-time, which is more
>> > memory efficient for your server processes.
>> >
>> > Cons:
>> >
>> > * More difficult to implement/manage since there'd be duplication of
>> > information to tie the two files together.
>> >
>> >
>> > I think the pros outweigh the cons.  Thoughts?
>> >
>> > Thanks,
>> >
>> > mrg
>>

Re: Custom Templates

[Michael Gentry <bl...@gmail.com>]

Well, my thought was to have just one XML file with all of the template
data in it: all custom templates, all JavaDocs, all annotations, and all
custom imports (mainly to support the annotations).  Basically a bunch of
CDATA sections to store each piece, plus the surrounding markup to identify
what it is supporting, of course.

Everything would still be under version control and could still be edited
with an external tool, just not as conveniently.  Basically, find the CDATA
section you want to edit and change it.

mrg


On Fri, Apr 8, 2016 at 11:22 AM, Mike Kienenberger <mk...@gmail.com>
wrote:

> More pros:
>
> * Templates be edited by an external tool without having to export the
> original data then import it after making changes.
>
> * Individual templates remain under version control.
>
>
> On Fri, Apr 8, 2016 at 11:12 AM, Michael Gentry <bl...@gmail.com>
> wrote:
> > So, I've had another thought on this ...
> >
> > We could store the custom templates, JavaDoc, etc. in a separate XML
> file.
> > This information is really only useful for class generation, either in
> > Cayenne Modeler or cgen.
> >
> >
> > Pros:
> >
> > * Class generation data wouldn't clutter up the current XML mapping file.
> > * Separate file can be omitted/excluded by the build tool, such as Maven,
> > so it isn't packaged up in your JAR/WAR for deployment.
> > * Class generation data wouldn't get loaded at run-time, which is more
> > memory efficient for your server processes.
> >
> > Cons:
> >
> > * More difficult to implement/manage since there'd be duplication of
> > information to tie the two files together.
> >
> >
> > I think the pros outweigh the cons.  Thoughts?
> >
> > Thanks,
> >
> > mrg
>

Re: Custom Templates

[Mike Kienenberger <mk...@gmail.com>]

More pros:

* Templates be edited by an external tool without having to export the
original data then import it after making changes.

* Individual templates remain under version control.


On Fri, Apr 8, 2016 at 11:12 AM, Michael Gentry <bl...@gmail.com> wrote:
> So, I've had another thought on this ...
>
> We could store the custom templates, JavaDoc, etc. in a separate XML file.
> This information is really only useful for class generation, either in
> Cayenne Modeler or cgen.
>
>
> Pros:
>
> * Class generation data wouldn't clutter up the current XML mapping file.
> * Separate file can be omitted/excluded by the build tool, such as Maven,
> so it isn't packaged up in your JAR/WAR for deployment.
> * Class generation data wouldn't get loaded at run-time, which is more
> memory efficient for your server processes.
>
> Cons:
>
> * More difficult to implement/manage since there'd be duplication of
> information to tie the two files together.
>
>
> I think the pros outweigh the cons.  Thoughts?
>
> Thanks,
>
> mrg

Re: Custom Templates

[Michael Gentry <bl...@gmail.com>]

So, I've had another thought on this ...

We could store the custom templates, JavaDoc, etc. in a separate XML file.
This information is really only useful for class generation, either in
Cayenne Modeler or cgen.


Pros:

* Class generation data wouldn't clutter up the current XML mapping file.
* Separate file can be omitted/excluded by the build tool, such as Maven,
so it isn't packaged up in your JAR/WAR for deployment.
* Class generation data wouldn't get loaded at run-time, which is more
memory efficient for your server processes.

Cons:

* More difficult to implement/manage since there'd be duplication of
information to tie the two files together.


I think the pros outweigh the cons.  Thoughts?

Thanks,

mrg

Re: Custom Templates

[Michael Gentry <bl...@gmail.com>]

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 <dk...@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....@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....@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 <bl...@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
>>>>
>>>

Re: Custom Templates

[Dzmitry Kazimirchyk <dk...@gmail.com>]

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....@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....@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 <bl...@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

Re: Custom Templates

[Michael Gentry <bl...@gmail.com>]

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....@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 <bl...@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

Re: Custom Templates

["Adrian A." <a....@googlemail.com>]

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 <bl...@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