Sorry for the delayed response. Been a busy week.
robert burrell donkin wrote:
i've been playing around with some code for a day or two
(http://people.apache.org/~rdonkin/tool.html). it's just hacked
together but hopefully it'll serve as an illustration and act as a
lightning rod for ideas. (it'll try to explain where i see it fitting
into the bigger picture later.) so please criticise the concepts not
the coding :)
Cool :-)
java classes and primitives have a natural correspondence to types.
primitives naturally correspond to simple types whereas classes may
correspond to simple or complex types. being able to perform multiple
mappings of the same primitive or class is important (think about the
different semantic meanings that java.util.Date may have).
In addition it would be nice if you could map an xml element to multiple
fields. For instance, if I have a nillable int. I would have an
isIntSet() and getInt() methods. I would want each one of those set
appropriately depending on the xml.
java developers naturally reuse classes. they need to be able to reuse
mappings either precisely or as the basis for tuning against a
particular schema. i see users being able to import mappings into the
tool (in a pluggable fashion), tuning them (by dynamic viewing schema
and example generation) and then saving the mappings into a library. i
see this import process being extensible so that import pluggings can
be created for existing ways of describing bindings.
the mappings in the library would then be available for use in other
tool sections for example, the mapping section (which is the named
i've just coined for dan's cool ideas but feel free to jump in with a
better one). it could also be used for a simple document tool (pure
start-from-java, with no target schema for initial prototyping).
So you're thinking this tool would be a good way to tweak an initial
object mapping? Then import it into the "mapping section" (we need
catchy names ;)) later if you need to tweak?
i see this design element as having advantages for the project as
well. mappings for common objects would be something that would be
easy to contribute. in addition, the numerous standard mappings which
it would be very good to ship with could be developed using the tool.
comments welcomed and cool new ideas even more so :)
dan has posted some very interesting ideas and i'd like to come back
to them later (maybe when i've played about with some visualisation
code).
i also have some ideas about the tuning process (arising out of the
prototype) but i'd prefer to hear comments first before elaborating.
I'd be interested in hearing your further thoughts :-).
As I think about this more, I'm coming to more conclusions. I want to be
able to do schema first, but for my first iteration of nearly any
project I'll be doing Java first and a nice default schema. Your mapper
could be used to come up with that first schema & mapping.
I'll then probably want to tweak and customize it. That would probably
require the mapping editor I described previously.
Also, the more I think about it the more I want it tightly integrated
with my IDE. As I mentioned before we can integrate refactoring. You
could have the IDE warn you if you were creating an incompatabile schema
change (by adding/renaming/removing a field). You could then say "create
a new schema version" or "screw backward compatability" or if possible
"update my mapping appropriately."
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
