Re: [morph-developer] SimpleLanguageBeanReflector

[Matt B. <gud...@ya...>]

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Cool idea!  Where are you headed with this?

If I tell you, I'm deprived of my curtain-pulling
ta-da moment... But since you're asking, I'll tell
you:

Dozer is the other OSS object-conversion framework
that anyone knows about that has enough meat to be
viable for real work.  A lot of people probably
wouldn't switch from Dozer to Morph if they perceived
themselves as losing anything in the way of
functionality.  Dozer's primary configuration
interface is an XML resource.  Morph on the other hand
must be configured entirely programmatically or
Spring-wired.  What I have been working on these past
couple of weeks is a means of mapping properties using
a configuration format specific to Morph.  Wow, you
say sarcastically...  But there's more!  :)  I can
already build simple configuration-file driven copiers
composed of PropertyNameMapping/MatchingCopiers, so my
next step was, in true me-too fashion, to be able to
map complex properties (Dozer does this).  I -believe-
the only thing I needed here was to implement a
reflector capable of interpreting complex properties
(done), and set that as the reflector on my generated
PropertyNameMappingCopiers, but I haven't done this
yet.

Is that all?  Of course not!  What's cool about simply
duplicating someone else's functionality?  Only if you
can one-up them in some way do you come out ahead. 
>:)  Example:  ever since I began working with Dozer,
they provided a unidirectional mapping feature. 
However, the one direction was only from "class A" to
"class B"--a limitation (the Dozer team recognizes it
as such).  This was tedious to define in their XML
format so they still, as far as I know, haven't done
it.  XML is clunky anyway.  So what I am working on is
a custom (ANTLR-implemented) DSL for Morph property
mapping.

Example 1:  basic mapping

net.sf.morph.transform.copiers.dsl.test.A :
net.sf.morph.transform.copiers.dsl.test.B {
	*,
	stringA : stringB,
	intA : intB,
	objectA : objectB
}

The above signifies a bidirectional mapping
association between two classes.  The asterisk
signifies that matching property names will be copied,
and that the three paired mappings will be made.

Example 2: mapping some fields leftward only (Dozer
can only do rightward)

net.sf.morph.transform.copiers.dsl.test.A :
net.sf.morph.transform.copiers.dsl.test.B {
	*,
	stringA<=stringB,
	intA<=intB,
	objectA<=objectB
}

As above, the matching properties will be mapped.  The
explicitly defined properties only go from class B to
class A.  To specify all mapping to be leftward only,
the class association can be defined with <= .  As you
would expect, => indicates rightward mappings.

There are other little things but that's the jist of
it, anyway.  I'm hoping this will ease the transition
of hypothetical users from Dozer to Morph.  ;)

> 
> One thing I worry about is that we may be
> introducing circular 
> dependencies.  Languages depend on converters which
> in turn depend on 
> reflectors.  If we make a reflector that is
> dependent on a language I 
> wonder if that could get us into trouble.

I hear you, but composition is such an integral part
of Morph's architecture that I just don't see a lot of
danger here.  As you can see, my intent is to make it
even deeper!  I want to make a delegatingCopier that
depends on propertyCopiers that depend on reflectors
that depend on languages that depend on reflectors...
I think that's right.  :)  Ultimately I think that
yes, if you misconfigure Morph it will fail
spectacularly.  That seems to me more likely than for
it to misbehave subtly.  Anyway, I am doing my
DSLDefinedCopier in the sandbox, so hopefully I'll
have something to check in later this week for your
perusal.  Incidentally, if you have a better name than
DSLDefinedCopier, I'm all ears.  :)

-Matt B
> 
> Matt S
> 
> Matt Benson wrote:
> > I've just implemented a reflector over
> SimpleLanguage,
> > which is of course itself implemented over the
> basic
> > reflectors.  Trust me, this is going somewhere...
> >
> > Incidentally, the tests for
> > SimpleLanguageBeanReflector implement the
> long-overdue
> > testing of SimpleLanguage.set().  :)
> >
> > more later,
> > Matt (B)
> >
> >
> >
> >  
> >
>
____________________________________________________________________________________
> > Need Mail bonding?
> > Go to the Yahoo! Mail Q&A for great tips from
> Yahoo! Answers users.
> >
>
http://answers.yahoo.com/dir/?link=list&sid=396546091
> >
> >
>
-------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of
> IT
> > Join SourceForge.net's Techsay panel and you'll
> get the chance to share your
> > opinions on IT & business topics through brief
> surveys-and earn cash
> >
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >   
> 
> 
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 



 
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html