Re: Velocity Generator & FetchSpecs Bindings

From: Mike Schrag (mschra..dimension.com)
Date: Tue Mar 04 2008 - 14:57:53 EST

  • Next message: Mike Schrag: "Re: java.lang.NoClassDefFoundError: JDBCPlugIn"

    > let me get this straight. With the new Entity Modeler, you can have
    > more Contexts than just Server and Client?!? If so, this is exactly
    > what I've been dreaming of but figured it would be too much to ask
    > and I'm nowhere nearly competent enough yet to take a stab at it
    > myself. My issue is that for my D2JC app (which, amazingly enough
    > _does work_ under 5.4.1!) I have some extra D2JC-specific code in
    > the client _entity.java files, and when I move to Flor's JBND
    > framework eventually, I'll need a completely different set of Client
    > classes. I'm not sure how I'm going to deal with that, but if your
    > talking about what I think you are, then you've built another bridge
    > before I even came to it.
    Well, not EXACTLY ... This is a "render context", where "rendering" in
    this case means "to generate source code," so the EOModel itself is
    unchanged, and your view inside of Entity Modeler is the same. But you
    CAN create two sets of eogen files that have different generation
    parameters, which would allow you to have different templates for
    client and server files, for instance. The render context thing gets
    attached to the thread by VelocityEOGenerator and changes the behavior
    of various methods that are called on the model. The concept is in
    place, though, so we could do other things with it, potentially. I
    don't know that it fulfills all your hopes and dreams, but file bugs
    for the things you need it to do so at least I'm aware of what you're
    looking for in case I run up against something else that might be
    solvable generically.

    > This would also help build "common" classes that both the server and
    > client-side classes inherit from as I could generate ".common."
    > classes as well as ".server." and ".client."
    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.

    >>> There is also some UI ugliness to the EOGen Editor in that the
    >>> header for check-boxes is mislabeled as being for the templates,
    >>> which is set in the section above. BUT I have just grabbed the
    >>> WOLips source via SVN and was going to look into fixing that
    >>> myself, as changing some text is a good place to start as a
    >>> contributor (at least for THIS contributor). :) Race ya!
    >> I was in there, so i went ahead and fixed this ... Sorry to ruin
    >> your fun :)
    >
    > How's a guy to learn when there's no low-hanging fruit?
    EOGeneratorFormPage in the org.objectstyle.wolips.eogenerator.ui.
    Eclipse needs click-to-open :) I have NO suggestion as to how to find
    this on your own, though. You can Show View=>PDE=>Plugin Registry
    View and then search for "EOGenerator" That might narrow down things
    some. This is one of Eclipse's biggest problems (same complaint
    people have about Wonder) -- it's huge and does tons of stuff, but it
    can be hard to find what you're looking for (especially when sometimes
    you don't exactly know what question you're trying to ask).

    ms



    This archive was generated by hypermail 2.0.0 : Tue Mar 04 2008 - 14:59:15 EST