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

Reply via email to