Re: WOLips Velocity Engine

From: David Avendasora (webobject..vendasora.com)
Date: Fri Feb 08 2008 - 12:37:23 EST

  • Next message: Chuck Hill: "Re: WOLips Velocity Engine"

    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