axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: [Axis2] Better Java-XML mapping
Date Thu, 25 Aug 2005 19:49:54 GMT
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


Mime
View raw message