Kevin,
This is really progressing along nicely.
I have a question about the map file though. Is the plan to make that
customizable? Meaning that I might make several maps for a given type of
object, to either go to a different end result, or one may have more
information than the other. For example I might have two maps for a Item,
one has only the top level information (Start/end date, description), the
other might contain all of the related information as well (such as related
items, Assigned users, etc.). I would do this because it would be quicker
to pull the non-related information, which I would use more often.
In another case I might use a two maps for the same Object one to write it
to Excel, the other to write it to a custom app.
-John
On 12/15/04 2:16 PM, "Kevin Menard" <nirvdru..egativetwenty.net> wrote:
> Hi everyone,
>
> I've changed quite a few things since the last beta and there really
> should be no copyright issues any more. It took me a bit to get where
> I am at with this now (particularly as Andrus pointed me to different
> things in Cayenne, I found better ways to do things), but I'm pretty
> happy with it. There's still some work to be done, but I wanted to get
> impressions about usability. Also, since I was doing this as a project
> for school, it'll be good for me to have some sort of release, even if
> it's this beta. Don't worry though, I plan on seeing this through to
> the end.
>
> Interesting classes are:
>
> org.objectstyle.cayenne.util.XMLEncoder
> org.objectstyle.cayenne.util.XMLDecoder
> org.objectstyle.cayenne.util.XMLSerializable (to a lesser extent)
>
> CayenneDataObject was modified to provide a default implementation of
> XMLSerializable#encodeAsXML(), so any classes that inherit from
> CayenneDataObject can be encoded without any extra effort. Right now,
> only declared attributes get encoded. I'm debating whether to do
> declared relationships. On the one hand, it would be nice to encode
> everything about an object without doing any extra work, on the other,
> encoding relationships may not be necessary, and I don't want to be
> hammering people's db servers for no reasons. Encoding relationships
> seems like it would be problematic if there are cycles too, so it would
> require a bit of forethought.
>
> XMLEncoder has a convenience method for encoding a collection of
> objects, and conversely, XMLDecoder can decode this XML to a List of
> objects. The decoding methods can take an optional DataContext for
> registering the decoded objects and committing them to the database. I
> register each object as it's decoded and the commit everything at the
> end. There were two ways this could have gone -- the other is to
> commit immediately after each new object is registered. If there's a
> problem with the approach I took, it's pretty trivial to switch to the
> other way. Or maybe a better way is to force the user to perform the
> commit?
>
> I was working on a map encoding/decoding, similar to what already
> exists in XMLEncoder, but I didn't know what the keys were, so Andrus,
> any help there would be nice. I assume these maps are being created by
> Cayenne somewhere?
>
> I still need to add some Javadoc for the encoder, but I don't have the
> time right now. It should be pretty straightforward to use. There is
> one interesting thing though that I need to find a better workaround
> for . . . my new encoding stuff doesn't immediately update the
> PrintWriter passed into the constructor of XMLEncoder -- an explicit
> call to getPrintWriter() is necessary. E.g.,
>
> final ByteArrayOutputStream out = new ByteArrayOutputStream();
> final XMLEncoder encoder = new XMLEncoder(new PrintWriter(out,
> true));
> encoder.encodeCollection("Bookmarks", bookmarks);
> encoder.getPrintWriter(); // If this is not here,
> out.toString() will return "".
> System.out.println(out.toString());
>
> Anyway, the download is available at
> http://www.negativetwenty.net/projects/cayenne.tar.gz. This is still
> the modified 1.2 code I checked of HEAD a month or so ago.
>
> Any feedback would be appreciated.
>
> Thanks,
> Kevin
>
This archive was generated by hypermail 2.0.0 : Wed Dec 15 2004 - 16:19:32 EST