On 8/25/05, Dan Diephouse <[EMAIL PROTECTED]> wrote: > Sorry for the delayed response. Been a busy week.
<snip> > robert burrell donkin wrote: > >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. i think that this can be addressed by using binding points (http://people.apache.org/~rdonkin/tool/tune.html). one logical binding point could trigger any number of operations on the instance but hides the power and complexity for common use cases. supporting scripting for this would be cool. > >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? +1 the import would have lots of options useful when developing the initial mapping but these wouldn't clutter up the later phases. > >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. +1 that's the way i see things too :) import for quick prototyping then the mapping for detailed work against a schema. a lot of features that i'd want to provide for import shouldn't be needed for the mapping. conversely, there's quite a lot that we'd want to provide in the mapper that would IMHO just get in the way for import. >> 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." very powerful and very cool :) would want to be able to run the components as a standard alone tool but there's no reason why this couldn't be done by stripping down. - robert
