Re: Code Generation

From: Kevin J. Menard, Jr. (nirvdru..egativetwenty.net)
Date: Mon Dec 13 2004 - 10:14:26 EST

  • Next message: Tore Halset: "Re: Code Generation"

    On Dec 13, 2004, at 12:06 AM, Andrus Adamchik wrote:

    >
    > On Dec 12, 2004, at 9:22 PM, Kevin Menard wrote:
    >> Now, I have a question about the code generation stuff. I've been
    >> playing with the superclass template, and it'll set up an
    >> encodeAsXML() that works pretty.
    >
    > Hmm, I thought you were planning a dynamic encoder/decoder for
    > DataObjects based on Cayenne mapping? I guess adding this as a
    > generated code has its benefits (i.e. no need for a DataContext). But
    > a DataContext (or maybe EntityResolver which is probably a cleaner
    > solution) can be passed around in encoder/decoder (or in a subclass of
    > coder)... So any other reason we might need a generated method instead
    > of a generic one in CayenneDataObject?

    Hmm . . . guess there was a bit of misunderstanding there. What you
    propose seems sound, I'll just have to look into it more now. I guess
    I didn't need to spend that that mucking around with velocity templates
    then :-P

    >
    >> The problem is that I need to know the package of the subclass
    >> created, and before I go modifying
    >> org.objectstyle.cayenne.gen.ClassGenerator, I figured I'd ask if it
    >> was already available somehow.
    >
    > Full name of the lowest subclass is available as
    > ClassGenerator.getEntity().getClassName(). Is this what you are
    > looking for?

    Sounds like it, although this may no longer be necessary.

    >> In particular, in setRoot(), I'm feeding in a class name for the XML
    >> encoding, which is needed for decoding. Generally speaking though,
    >> people work with their subclass. As such, two problems are at hand.
    >> I'd like to auto-create the decode code (which is being done in a
    >> constructor that takes a single arg of type XMLDecoder), but then the
    >> subclass needs to provide a new constructor that just calls super(),
    >> which seems like a waste. But putting the auto-generated code in the
    >> subclass is a no go too.
    >
    > How about a two-step decoding? A noarg constructor, and then calling a
    > decodeFromXML(..)?

    It's not clear to me how that would work, since something needs to
    define the notion of decoding. What I have now works as follows:

    XMLDecoder decoder = new XMLDecoder();
    decoder.decode(xml);
    Test t = new Test(decoder);

    and then in Test, calls such as:

    public Test(XMLDecoder decoder)
    {
            setSomeInt(decoder.getInt(xmlTag));
    }

    Unless of course, you were thinking of a generic decode method too,
    which would seem to make sense if I have a generic encode. Guess I'll
    have to tinker with this a bit some more later today.

    -- 
    Kevin
    



    This archive was generated by hypermail 2.0.0 : Mon Dec 13 2004 - 10:15:39 EST