Re: Velocity Generator & FetchSpecs Bindings

From: David Avendasora (webobject..vendasora.com)
Date: Tue Mar 04 2008 - 15:30:17 EST

  • Next message: Mike Schrag: "Re: Velocity Generator & FetchSpecs Bindings"

    On Mar 4, 2008, at 2:57 PM, Mike Schrag wrote:
    > Yeah ,you could probably make a common.eogen that generates the
    > common stuff, then in your templates for the client and server
    > eogen, you would need to change the superclass of the _File to be
    > the name of the common non-_File or something like that.

    The thing I ran into before when I tried using a common class in the
    past is that the common class almost always has relationships to other
    entities, and because the model only knows about the Server and Client
    classes, the fully qualified package name would always point to one or
    the other depending on if you used className or clientClassName in the
    template.

    The Client-Side information is stored within the .plist file inside
    another "internalInfo" construct:

         internalInfo = {
             "_clientClassPropertyNames" = (
                 billsOfMaterial,
                 componentOfBillsOfMaterial,
                 hasNutritional,
                 labels,
                 lotCodes,
                 nutritionBlocks,
                 partDescription,
                 partName,
                 partNumber,
                 partStatus,
                 partType,
                 statementBlocks,
                 unitOfMeasure,
                 workCentersUsedIn
             );
             "_javaClientClassName" =
    "com.bestmaid.bakeryManagement.client.part.Part";
             uniqueID = 198115528;
         };

    Now, if I could add

    "_commonClassPropertyNames" = (list, of, common, attributes)

    and a

    "_commonClassName" = "com.bestmaid.bakeryManagement.common.part.Part"

    to the internalInfo construct, then have EOGenerator be able to pick
    them up at the correct time, and Entity Modeler be able to set them,
    that would be my dream.

    Java Client applications can have many methods that are the same on
    the client and server and right now, to use EOGenerator, you are stuck
    duplicating them in both the Server and Client versions of the Class,
    or making the client go back to the server and execute the method
    there and then return the results (if any) back to the client. The
    problem is that when you remotely invoke a method from the client, WO
    copies the entire EditingContext back to the server side also
    (obviously), which triggers validation on all the objects so suddenly
    if you haven't set a relationship required by the model, you can't
    call a function that may be completely unrelated. The solution is to
    have a common class that is copied to both the client and the server,
    but right now there's no efficient way to do generate that common
    class, and therefor keep it in sync with model changes.

    This would be a HUGE help to WO Java Client developers. Both of us! ;-)

    Dave



    This archive was generated by hypermail 2.0.0 : Tue Mar 04 2008 - 15:32:03 EST