On Feb 8, 2008, at 11:43 AM, Mike Schrag wrote:
>> Is the Velocity engine in WOLips accessible, possibly via Ant?
>>
>> Here's what I'm trying to do: I am working on a Java Client
>> project where the client-side classes have several methods that
>> are exactly the same as the server-side version (Validation,
>> Defaults, etc) and I don't want to maintain them in two places,
>> and using a common subclass for both is not viable because I have
>> to have the client-side and server-side classes need to extend
>> different superclasses.
>>
>> So that leaves me with either duplicating code (and bugs) and
>> dealing with keeping them in sync, or figuring out a way to have
>> the methods automatically synced. This is where velocity comes in.
>>
>> I'd like to flag each "common" method as needing to be copied to
>> the client-side class and then have a Velocity template that would
>> read them out of the server-side and copy them into the client-
>> side _Entity class. I would want to execute this step following
>> any EOGeneration of my client-side .eotemplate files.
>>
>> Again, the end goal is to maintain "common" methods in one
>> location and have them automatically propagated as part of a build.
> It's not accessible from ant, you'd have to wrap it in an ant task
> or something if you want to do that.
>
> However, you can have multiple .eogen files for a single model --
> you could maybe create a server.eogen and a client.eogen that use
> different templates to do what it is you're trying to do (which I'm
> not sure I exactly follow). Are these common things you're copying
> generated, or are you writing common methods that they share? Do
> server and client share a single _Parent? Can you set this up with
> inheritance hierarchy like the current eogen files do, just
> introducing a third inheritance level with your own custom templates?
These are not generated methods that I want to copy down to the
client classes, They are ones that I write containing specific
validation code, or setting defaults. Potentially I could set
validation rules and defaults in the UserInfo dictionary and then
generate the validation and defaults methods off that, I'll look into
it.
I already have server-side and client-side EOGen files for my project
and they work well for most typical EOGenerator-type functions.
A common class that they both inherit from won't work as the client
classes have to inherit from the JBND EOGenericRecord class. Besides,
I posted questions regarding this in a different thread (Possible
Feature Request...) a couple days ago with no response from anyone,
so I took that as "Nobody's ever done it before. You're on your
own." I since figured out that a common class really won't work in
the first place.
Dave
This archive was generated by hypermail 2.0.0 : Fri Feb 08 2008 - 12:38:22 EST