Menu
▾
▴
morph-developer — For developers of the Morph framework. NOT for questions.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(3) |
Feb
(4) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(6) |
| 2006 |
Jan
(1) |
Feb
(6) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
| 2007 |
Jan
(44) |
Feb
(36) |
Mar
(24) |
Apr
(59) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(3) |
| 2008 |
Jan
(34) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(2) |
Oct
|
Nov
(3) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Matt S. <Mat...@wh...> - 2007-02-22 19:15:46
|
> One thing that might work here is to implement a > Spring 2.0 XML schema, but just use nested text (of > the format I outlined) in a <morph:something> element. > :) Have your cake and eat it too. > Excellent idea. I've been thinking more about the SimpleLanguageBeanReflector and I am still concerned that we could be introducing something dangerous into the API. Is there a reason you can't use the Language API directly to implement what you are working on? This would also free you from the depending on a concrete implementation of the Language interface... Matt |
|
From: Matt S. <Mat...@wh...> - 2007-02-22 14:37:31
|
Awesome, thanks Matt B.
I've given this a lot of thought, and whether or not to wrap exceptions
should be based on whether or not the reflector or transformer delegates
to some other reflector or transformer. If there is no delegation, then
go ahead and wrap the exceptions because that is a Morph class. If
there is delegation, there is a potential that the delegate is a user
defined object rather than a Morph object, so there should not be
runtime exception wrapping.
Matt S
Matt Benson wrote:
> Gotcha--forgot about the RuntimeException wrapping
> issue. Matt, since you've given your blessing here I
> can make time to stuff this in, with the behavior flag
> you had declared it was your intent to use. I'd like
> for Morph to become the indisputably "right" way to do
> Java object conversions. ;)
>
> -Matt
>
> --- Matt Benson <gud...@ya...> wrote:
>
>
>> Did I/we lose track of something? I can't recall
>> that
>> there are any outstanding patches from Ben that
>> haven't been applied to HEAD. And yes, we should
>> probably do a release sometime in the near future
>> IMHO... :|
>>
>> -Matt
>>
>> --- Matt Sgarlata
>> <Mat...@wh...> wrote:
>>
>>
>>> Hi Alan - the patches will either be accepted or
>>> modified and then
>>> accepted. I promise we will do this before the
>>>
>> next
>>
>>> Morph release.
>>>
>>> So when is the next Morph release? Well, as you
>>>
>> can
>>
>>> tell, they aren't
>>> very frequent. The main reason is that I do
>>> software development as a
>>> full time job, so Morph isn't really a hobby in
>>> quite the same way as it
>>> used to be. If Matt B starts to push for a
>>>
>> release,
>>
>>> I will chip in and
>>> make sure the patches are either accepted or
>>> accepted and modified
>>> before the release.
>>>
>>> Matt S
>>>
>>> Alan Stewart wrote:
>>>
>>>> Hi
>>>> I'm a user of Dozer and wanted to know if the
>>>>
>>> changes Ben Alex suggested
>>>
>>>> will be incorporated into Morph and if so, when?
>>>> Regards
>>>> Alan
>>>>
>>>> Matt Benson wrote:
>>>>
>>>>
>>>>> --- 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
>
>>>>>
> -------------------------------------------------------------------------
>
>>>>> 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
>
>>>>
>>>>
> -------------------------------------------------------------------------
>
>>> 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
>
>>
>>
>>
>>
> ____________________________________________________________________________________
>
>> Finding fabulous fares is fun.
>> Let Yahoo! FareChase search your favorite travel
>> sites to find flight and hotel bargains.
>> http://farechase.yahoo.com/promo-generic-14795097
>>
>>
>>
> -------------------------------------------------------------------------
>
>> 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
>
>
>
>
>
> ____________________________________________________________________________________
> Have a burning question?
> Go to www.Answers.yahoo.com and get answers from real people who know.
>
> -------------------------------------------------------------------------
> 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
>
>
|
|
From: Matt B. <gud...@ya...> - 2007-02-22 13:30:44
|
Gotcha--forgot about the RuntimeException wrapping
issue. Matt, since you've given your blessing here I
can make time to stuff this in, with the behavior flag
you had declared it was your intent to use. I'd like
for Morph to become the indisputably "right" way to do
Java object conversions. ;)
-Matt
--- Matt Benson <gud...@ya...> wrote:
> Did I/we lose track of something? I can't recall
> that
> there are any outstanding patches from Ben that
> haven't been applied to HEAD. And yes, we should
> probably do a release sometime in the near future
> IMHO... :|
>
> -Matt
>
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
> > Hi Alan - the patches will either be accepted or
> > modified and then
> > accepted. I promise we will do this before the
> next
> > Morph release.
> >
> > So when is the next Morph release? Well, as you
> can
> > tell, they aren't
> > very frequent. The main reason is that I do
> > software development as a
> > full time job, so Morph isn't really a hobby in
> > quite the same way as it
> > used to be. If Matt B starts to push for a
> release,
> > I will chip in and
> > make sure the patches are either accepted or
> > accepted and modified
> > before the release.
> >
> > Matt S
> >
> > Alan Stewart wrote:
> > > Hi
> > > I'm a user of Dozer and wanted to know if the
> > changes Ben Alex suggested
> > > will be incorporated into Morph and if so, when?
> > > Regards
> > > Alan
> > >
> > > Matt Benson wrote:
> > >
> > >> --- 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
> >
> > >>
> > >>
> >
>
-------------------------------------------------------------------------
> > >> 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
> > >
> > >
> >
> > >
>
-------------------------------------------------------------------------
> > 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
> >
>
>
>
>
>
____________________________________________________________________________________
> Finding fabulous fares is fun.
> Let Yahoo! FareChase search your favorite travel
> sites to find flight and hotel bargains.
> http://farechase.yahoo.com/promo-generic-14795097
>
>
-------------------------------------------------------------------------
> 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
>
____________________________________________________________________________________
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.
|
|
From: Matt B. <gud...@ya...> - 2007-02-22 13:21:28
|
Did I/we lose track of something? I can't recall that
there are any outstanding patches from Ben that
haven't been applied to HEAD. And yes, we should
probably do a release sometime in the near future
IMHO... :|
-Matt
--- Matt Sgarlata
<Mat...@wh...> wrote:
> Hi Alan - the patches will either be accepted or
> modified and then
> accepted. I promise we will do this before the next
> Morph release.
>
> So when is the next Morph release? Well, as you can
> tell, they aren't
> very frequent. The main reason is that I do
> software development as a
> full time job, so Morph isn't really a hobby in
> quite the same way as it
> used to be. If Matt B starts to push for a release,
> I will chip in and
> make sure the patches are either accepted or
> accepted and modified
> before the release.
>
> Matt S
>
> Alan Stewart wrote:
> > Hi
> > I'm a user of Dozer and wanted to know if the
> changes Ben Alex suggested
> > will be incorporated into Morph and if so, when?
> > Regards
> > Alan
> >
> > Matt Benson wrote:
> >
> >> --- 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
>
> >>
> >>
>
-------------------------------------------------------------------------
> >> 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
> >
> >
>
> >
-------------------------------------------------------------------------
> 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
>
____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
|
|
From: Matt S. <Mat...@wh...> - 2007-02-21 14:59:14
|
Hi Alan - the patches will either be accepted or modified and then
accepted. I promise we will do this before the next Morph release.
So when is the next Morph release? Well, as you can tell, they aren't
very frequent. The main reason is that I do software development as a
full time job, so Morph isn't really a hobby in quite the same way as it
used to be. If Matt B starts to push for a release, I will chip in and
make sure the patches are either accepted or accepted and modified
before the release.
Matt S
Alan Stewart wrote:
> Hi
> I'm a user of Dozer and wanted to know if the changes Ben Alex suggested
> will be incorporated into Morph and if so, when?
> Regards
> Alan
>
> Matt Benson wrote:
>
>> --- 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
>>
>> -------------------------------------------------------------------------
>> 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
>
>
|
|
From: Alan S. <ala...@op...> - 2007-02-21 06:25:16
|
Hi
I'm a user of Dozer and wanted to know if the changes Ben Alex suggested
will be incorporated into Morph and if so, when?
Regards
Alan
Matt Benson wrote:
> --- 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
>
> -------------------------------------------------------------------------
> 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
>
>
|
|
From: Matt B. <gud...@ya...> - 2007-02-20 23:31:48
|
--- Matt Sgarlata <Mat...@wh...> wrote: > Wow, that looks fantastic! Morph has the ability to > do very complex > mappings between different types of objects, but it > is a pain in the > neck to set up. This looks like it would be very > friendly towards > people new to Morph and to former Dozer users in > particular. > I'm glad you like it. :) > I've also thought that perhaps it would be possible > to setup some type > of Morph XML Schema that would plug seamlessly into > Spring, but as you > mentioned, XML is rather clunky. > One thing that might work here is to implement a Spring 2.0 XML schema, but just use nested text (of the format I outlined) in a <morph:something> element. :) Have your cake and eat it too. -Matt B > Matt S [SNIP] ____________________________________________________________________________________ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. |
|
From: Matt S. <Mat...@wh...> - 2007-02-20 23:26:40
|
Wow, that looks fantastic! Morph has the ability to do very complex
mappings between different types of objects, but it is a pain in the
neck to set up. This looks like it would be very friendly towards
people new to Morph and to former Dozer users in particular.
I've also thought that perhaps it would be possible to setup some type
of Morph XML Schema that would plug seamlessly into Spring, but as you
mentioned, XML is rather clunky.
Matt S
Matt Benson wrote:
> --- 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
>
> -------------------------------------------------------------------------
> 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
>
>
|
|
From: Matt B. <gud...@ya...> - 2007-02-20 23:09:44
|
--- 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
|
|
From: Matt S. <Mat...@wh...> - 2007-02-20 22:25:35
|
Cool idea! Where are you headed with this? 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. 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 > > |
|
From: Matt B. <gud...@ya...> - 2007-02-20 22:07:02
|
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 |
|
From: Matt B. <gud...@ya...> - 2007-02-16 20:39:31
|
I just dumped a bunch of stuff I've been working on into HEAD. This stuff was blocking some of what I'm REALLY working on in Morph, most notably the fact that nested SimpleDelegatingTransformers did not work. I preserved the status quo, but fixed things so that an SDT proxied to implement NodeCopier _would_ work as a nested transformer of another SDT. See NestedDelegatingCopierTestCase for the starting point of what's happening here... More to come... (mercifully I'll be using the sandbox next time I think) ;) -Matt B ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 |
|
From: Matt S. <Mat...@wh...> - 2007-02-09 17:22:10
|
Oh boy, digging into ancient history here ;) I wrote this in the history portion of the website: "Removed the GraphTransformer interface and renamed the graphTransformer property of BaseTransformer back to nestedTransformer" I am having trouble recalling exactly, but I believe GraphTransformer was an interface I was using to help me when performing graph transformations. I basically was using it as an implementation crutch and I felt it was not appropriate to include in the API so I removed it. Matt Matt Benson wrote: > Matt S: Was this formerly the name for > SimpleDelegatingTransformer? > > br, > Matt B > > > > ____________________________________________________________________________________ > Finding fabulous fares is fun. > Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. > http://farechase.yahoo.com/promo-generic-14795097 > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > morph-developer mailing list > mor...@li... > https://lists.sourceforge.net/lists/listinfo/morph-developer > > |
|
From: Matt B. <gud...@ya...> - 2007-02-09 17:13:31
|
Matt S: Was this formerly the name for SimpleDelegatingTransformer? br, Matt B ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 |
|
From: Matt S. <Mat...@wh...> - 2007-02-08 17:02:28
|
Hi David, I believe the functionality you are asking about would be expressed in Morph's TextToNumberConverter. In the process of writing the converter, it seemed to me that the use of the JDK's built in Format object was limiting for parsing dates, and not as robust as I would like. For example, I want users to be able to type in a variety of different formats when they mean -5000. It might be (5000) or -5000 or (-5,000.00) or even -(5.000,00) if the user is Dutch. I don't want to have to define a half dozen different number formats and the TextToNumberConverter attempts to be more robust than a JDK Format object. I actually was working on this recently and hadn't even checked in my changes yet, but they are ready so I just checked them in. You can access the code through annonymous SVN by connecting to svn://development.spiderstrategies.com/composite svn://development.spiderstrategies.com/morph Please let me know if this meets your needs, or if it doesn't what changes would be required to meet your needs. Also, if you wouldn't mind, please address questions to mor...@li.... There may be someone else on the list that is able to answer your questions faster or better than I. Matt David Putnam wrote: > Message body follows: > > Hello, > > I was looking at your application to replace a home-grown > library to read datafiles. Currently the library uses > SimpleDateFormat to parse dates in a variety of styles. I am > trying to solve, in a generic way, parsing numeric formats > with implied decimal points (think COBOL PIC 99v99). > > I did not see your code use Format to influence style and > conversion, and was wondering if you considered this > functionality and discarded it for a specific reason. > > Thanks for your help, > David > > -- > This message has been sent to you, a registered SourceForge.net user, > by another site user, through the SourceForge.net site. This message > has been delivered to your SourceForge.net mail alias. You may reply > to this message using the "Reply" feature of your email client, or > using the messaging facility of SourceForge.net at: > https://sourceforge.net/sendmessage.php?touser=1607872 > > > |
|
From: Matt B. <gud...@ya...> - 2007-02-06 14:55:30
|
What I meant by saying that the parent converter
concept could be worked into BaseTransformer was that
the additional interface could be avoided and the
parentConverter be an implementation detail of
BaseTransformer's built-in copier-as-converter
support. This is because I ultimately STILL :( cannot
see any effective difference between an
"InstantiatingReflector" that knows how to create a
destination object from a source object (which it may
ignore) and ANY Converter that knows how to create a
destination object from a source object (which,
theoretically, it could ignore as well). But, as I
have other (Morph) things I want to work on at the
moment I will drop the issue, at least for now. :)
br,
Matt B
--- Matt Sgarlata
<Mat...@wh...> wrote:
> To me, "how do we get the destination instance for a
> conversion" could
> be reworded "how do we instantiate the destination
> instance for a
> conversion" to which the answer "write an
> InstantiatingReflector" seems
> a logical answer. If our goal is to "make the
> experience of working
> with Morph one of writing tiny classes to do very
> specific things which
> can then be arranged by configuration to accomplish
> the large tasks",
> setting up an InstantiatingReflector provides a
> separate abstraction
> concerned with creating objects.
>
> If the goal is to only have to write one class that
> references a given
> type of domain object, I think a transformer
> extended from
> BaseTransformer that implements convertImpl and
> copyImpl will fit the
> bill (this is what I was talking about in my last
> email).
>
> I am confused by what you mean by "I suppose it
> would be possible to add
> the parent converter concept to BaseTransformer
> without using a new
> interface--the default converter could delegate to
> the BaseTransformer
> instance's (Instantiating-) Reflector..."
> BaseTransformer already has a
> reflector property which you can use to plug in your
> instantiating
> reflector. It's a little more complicated because
> you actually have to
> supply a SimpleDelegatingReflector that has your
> InstantiatingReflector
> added to its list of delegates, but the capability
> is there. I would
> assume this is the mechanism Ben Alex is using to
> plug in his
> InstantiatingReflectors.
>
> By the way, it's called a SimpleInstantingReflector
> for a reason: I
> anticipate we'll write a better one with a better
> name at some point.
> For example, one could imagine a RegisteryReflector
> that has methods
> like registerReflector(String name, Reflector
> reflector) that would make
> it easier to setup custom reflectors. There could
> also be a
> RegistryTransformer with methods like
> registerTransformer(String name,
> Transformer transformer) and even
> registerReflector(String name,
> Reflector reflector) to make it much simpler to
> integrate a few custom
> reflectors and transformers with Morph's built-in
> capabilities. Is this
> what you're getting at, that it's too difficult to
> configure Morph? On
> this point I wholeheartedly agree and I think there
> are some simple
> things we could do to improve the situation. I
> don't think we need any
> new abstractions though, just new and better
> implementations of
> composite Reflectors and Transformers.
>
> Matt S
>
> Matt Benson wrote:
> > I can see your point here, and concede that it is
> > possible to continue as-is. I guess I am aiming
> for
> > trying to make the experience of working with
> Morph
> > one of writing tiny classes to do very specific
> things
> > which can then be arranged by configuration to
> > accomplish the large tasks. So when we see
> something
> > as common as "how do we get the destination
> instance
> > for a conversion" that makes an attractive
> extension
> > point. I suppose it would be possible to add the
> > parent converter concept to BaseTransformer
> without
> > using a new interface--the default converter could
> > delegate to the BaseTransformer instance's
> > (Instantiating-) Reflector so as to preserve the
> > status quo while permitting the granular
> customization
> > I am after... would this sound like a reasonable
> > compromise to you?
> >
> > -Matt B
> >
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >
> >> Hello again Matt B - thanks for following up on
> this
> >> issue, because I
> >> think it's important we get this right. One of
> the
> >> main benefits of
> >> Morph over other frameworks is the strength of
> its
> >> abstractions, and
> >> right now it seems like Morph is falling flat on
> its
> >> face when dealing
> >> with objects that don't have a public no-arg
> >> constructor.
> >>
> >> I see what you're getting at with the
> >> DerivedConverter, but I'm not
> >> convinced that a new interface is needed here.
> What
> >> should be happening
> >> to avoid use of the InstantiatingReflector is
> simply
> >> overriding the
> >> convertImpl method to do the desired conversion
> >> operation. I know the
> >> default implementation looks scary:
> >>
> >> Object reuseableSource =
> >> createReusableSource(destinationClass,
> >> source);
> >> Object newInstance =
> >> createNewInstanceImpl(destinationClass,
> >> reuseableSource);
> >> copyImpl(newInstance, reuseableSource,
> >> locale,
> >> Converter.TRANSFORMATION_TYPE_CONVERT);
> >> return newInstance;
> >>
> >> but overriding it isn't nearly so horrid:
> >>
> >> Object newInstance = new
> ComplexObject(arg1,
> >> arg2, arg3);
> >> copyImpl(newInstance, source, locale,
> >> Converter.TRANSFORMATION_TYPE_CONVERT);
> >> return newInstance;
> >>
> >> I really think the problem here is just the
> comments
> >> on the convertImpl
> >> method. The documentation states "this
> >> implementation should be fine
> >> as-is for Copiers" when instead it should state
> "you
> >> will need to
> >> override this method if your destination object
> does
> >> not have a public
> >> no-arg constructor".
> >>
> >> In terms of strengthening abstractions for the
> >> AssemblerCopier and
> >> DisassemblerCopier, I think that's an issue for
> >> those copiers to
> >> address, not for BaseTransformer.
> >>
> >> Matt S
> >>
> >> Matt Benson wrote:
> >>
> >>> Okay... my design might be somewhat crippled by
> >>>
> >> the
> >>
> >>> attempt to be as non-disruptive as possible:
> >>>
> >>> /** A converter derived from another converter
> */
> >>> interface DerivedConverter extends Converter {
> >>> Converter getParentConverter();
> >>> }
> >>>
> >>> Basically I think BaseTransformer would provide
> >>>
> >> the
> >>
> >>> DerivedConverter implementation something like
> >>>
> >> this:
> >>
> >>> public class BaseTransformer ... {
> >>> private static final Converter DEFAULT_PARENT
> =
> >>>
> >> new
> >>
> >>> NewInstanceConverter();
> >>>
> >>> private Converter parentConverter;
> >>>
> >>> public Converter getParentConverter() {
> >>> return parentConverter == null ?
> >>>
> >> DEFAULT_PARENT :
> >>
> >>> parentConverter;
> >>> }
> >>>
> >>> public void setParentConverter() { //routine }
> >>>
> >>> protected Object convertImpl(Class
> >>>
> >> destinationClass,
> >>
> >>> Object source,
> >>> Locale locale) throws Exception {
> >>> if (!(this instanceof DerivedConverter)) {
> >>> throw new UnsupportedOperation();
> >>> }
> >>> Object reuseableSource =
> >>> createReusableSource(destinationClass, source);
> >>> Object destObject =
> >>> getParentConverter().convert(destinationClass,
> >>> reuseableSource);
> >>> copyImpl(destObject, reuseableSource,
> locale,
> >>> Converter.TRANSFORMATION_TYPE_CONVERT);
> >>> return destObject;
> >>> }
> >>> }
> >>>
> >>> Again, we are talking ultimately about an entity
> >>>
> >> that
> >>
> >>> transforms a source object to an instance of a
> >>> specified destination class. If we do away with
> >>>
> >> the
> >>
> >>> InstantiatingReflector concept, AT LEAST where
> >>> converters are concerned, Morph becomes more
> >>> versatile, because any converter can be used as
> >>>
> >> the
> >>
> >>> parent converter in a derivedConverter
> >>>
> >> implementation.
> >>
> >>> A concrete example:
> >>>
> >>> Morph contains a (-n unfinished)
> >>> MultipleDestinationConverter. This can also be
> >>>
> >> viewed
> >>
> >>> as a DisassemblerCopier (complemented by my
> >>>
> >> recently
> >>
> >>> added AssemblerCopier). In terms of
> implementing
> >>> copying, this is pretty simple. You have a list
> >>>
> >> of
> >>
> >>> copier children which should be the same size as
> >>>
> >> the
> >>
> >>> destination object container. The component
> >>>
> >> copiers
> >>
> >>> are invoked one at a time from the source object
> >>>
> >> to
> >>
> >>> the corresponding child in the destination
> >>>
> >> container.
> >>
> >>> The existing partial
> MultipleDestinationConverter
> >>> implementation uses a list of classes to tell it
> >>>
> >> how
> >>
> >>> to create the destination object when
> implementing
> >>> Converter. But this is still a case of "we know
> >>>
> >> how
> >>
> >>> to copy and we just need to know how to create
> the
> >>> destination object". InstantiatingReflector
> >>>
> >> doesn't
> >>
> >>> fully represent the concept of creating a
> >>>
> >> (probably
> >>
> >>> heterogenous) collection of destination objects
> >>>
> >> IMHO.
> >>
> >>> But a parent Converter is semantically
> open-ended
> >>>
> >> and,
> >>
> >>> I believe, describes both situations fairly:
> the
> >>> simple (.newInstance()) as well as the complex.
> >>>
> >>> Does that make anything any clearer?
> >>>
> >>> -MJB
> >>>
> >>> --- Matt Sgarlata
> >>> <Mat...@wh...> wrote:
> >>>
> >>>
> >>>
> >>>> I agree, the addition of the "Object
> parameters"
> >>>> parameter to
> >>>> InstantiatingReflector.newInstance is
> worrisome.
> >>>> The idea behind a
> >>>> Reflector in general is that it tells you how
> to
> >>>> work with some new type
> >>>> of object that has properties which are not
> known
> >>>> until runtime. For
> >>>> example, Maps, DynaBeans, ResultSets, etc. If
> >>>>
> >> you
> >>
> >>>> have some sort of
> >>>> domain object there should be no need to write
> a
> >>>> reflector, because
> >>>> Morph's built-in ObjectReflector can use Java's
> >>>> built-in reflection
> >>>> capabilities to determine the properties of the
> >>>> object. If you just
> >>>> want to be able to convert stuff, it should be
> >>>> sufficient to write a
> >>>> single Transformer that implements both
> Converter
> >>>> and Copier interfaces
> >>>> and doesn't mess with InstantiatingReflectors
> at
> >>>> all.
> >>>>
> >>>> That said, I think the
> >>>> InstantiatingReflector.newInstance method is
> >>>> something that should be present in the API and
> >>>>
> >> not
> >>
> >>>> deprecated. We can
> >>>> and should specify in the comments what this
> >>>>
> >> method
> >>
> >>>> should and should
> >>>> not be used for. However, it is possible that
> >>>>
> >> some
> >>
> >>>> types of dynamic
> >>>> objects would require extra information before
> >>>>
> >> they
> >>
> >>>> are created. For
> >>>> example, the BasicDynaBean has no default
> >>>> constructor and requires a
> >>>> DynaClass to be constructed. Its properties
> are
> >>>>
> >> not
> >>
> >>>> known until
> >>>> runtime, but the DynaClass provides a contract
> >>>> describing the object's
> >>>> properties, etc.
> >>>>
> >>>> So in summary, I'm saying I think we have a
> >>>> documentation issue not an
> >>>> API issue. However, I don't fully understand
> >>>>
> >> what
> >>
> >>>> API changes you are
> >>>> proposing, so could you post some pseudo code
> for
> >>>>
> >> us
> >>
> >>>> to look at?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Matt S
> >>>>
> >>>> Matt Benson wrote:
> >>>>
> >>>>
> >>>>> I am reawakening this thread. I touched on
> this
> >>>>> subject during the original discussion, but at
> >>>>>
> >> the
> >>
> >>>>> time I couldn't quite articulate what was
> >>>>>
> >>>>>
> >>>> bothering me
> >>>>
> >>>>
> >>>>> about the whole business. Last Friday it
> burst
> >>>>>
> >>>>>
> >>>> upon
> >>>>
> >>>>
> >>>>> me, and I have continued to kick it around
> over
> >>>>>
> >>>>>
> >>>> the
> >>>>
> >>>>
> >>>>> weekend but have not been able to refute my
> own
> >>>>>
> >>>>>
> >>>> logic:
> >>>>
> >>>>
> >>>>> Basically with InstantiatingReflector taking a
> >>>>>
> >>>>>
> >>>> source
> >>>>
> >>>>
> >>>>> parameter, it IS a converter. What is the
> >>>>>
> >>>>>
> >>>> difference
> >>>>
> >>>>
> >>>>> between:
> >>>>>
> >>>>> InstantiatingReflector.newInstance(Class,
> >>>>>
> >> Object)
> >>
> >>>>> -and-
> >>>>> DecoratedConverter.convert(Class, Object)
> >>>>> ?
> >>>>>
> >>>>> >From my POV, nothing. Different semantics
> for
> >>>>>
> >>>>>
> >>>> what,
> >>>>
> >>>>
> >>>>> using the method parameters as an indicator,
> is
> >>>>>
> >>>>>
> >>>> one
> >>>>
> >>>>
> >>>>> concept. The role of the
> InstantiatingReflector
> >>>>>
> >>>>>
> >>>> in
> >>>>
> >>>>
> >>>>> the Morph library is to adapt a copier to the
> >>>>> converter interface, using the following
> >>>>>
> >>>>>
> >>>> algorithm:
> >>>>
> >>>>
> >>>>> 1. Create a new instance I
> >>>>> 2. Invoke copy() using I as the destination
> >>>>>
> >>>>>
> >>>> object.
> >>>>
> >>>>
> >>>>> This sequence of operations amounts to a
> >>>>>
> >> "derived
> >>
> >>>>> conversion": one which relies on a parent
> >>>>>
> >>>>>
> >>>> conversion
> >>>>
> >>>>
> >>>>> to supply the target object, then modifies the
> >>>>> resulting object. This modification will
> always
> >>>>> consist of making changes on a target object
> >>>>>
> >> based
> >>
> >>>>>
> >>>>>
> >>>> on
> >>>>
> >>>>
> >>>>> the source object (otherwise the parent
> >>>>>
> >> converter
> >>
> >>>>> alone would suffice), and thus infallibly
> >>>>>
> >>>>>
> >>>> corresponds
> >>>>
> >>>>
> >>>>> in intent with Copier.copy(). This proves
> that
> >>>>>
> >> a
> >>
> >>>>> DerivedConverter is precisely a Copier that
> >>>>>
> >>>>>
> >>>> implements
> >>>>
> >>>>
> >>>>> Converter by first delegating to a parent
> >>>>>
> >>>>>
> >>>> Converter,
> >>>>
> >>>>
> >>>>> then copies the source to the resulting
> >>>>>
> >>>>>
> >>>> destination
> >>>>
> >>>>
> >>>>> object. The parent converter can be
> overridden,
> >>>>>
> >>>>>
> >>>> but
> >>>>
> >>>>
> >>>>> would default to an, e.g.,
> NewInstanceConverter
> >>>>>
> >>>>>
> >>>> which
> >>>>
> >>>>
> >>>>> simply creates a new instance of the
> >>>>>
> >>>>>
> >>>> destinationClass.
> >>>>
> >>>>
> >>>>> In adopting the DerivedConverter concept,
> >>>>> InstantiatingReflector would, in my opinion,
> no
> >>>>>
> >>>>>
> >>>> longer
> >>>>
> >>>>
> >>>>> be needed, and would hopefully be deprecated
> and
> >>>>>
> >>>>>
> >>>> then
> >>>>
> >>>>
> >>>>> removed as soon as the current players on the
> >>>>>
> >>>>>
> >>>> mailing
> >>>>
> >>>>
> >>>>> list(s) are all up to speed. Because the
> >>>>>
> >>>>>
> >>>> interfaces
> >>>>
> >>>>
> >>>>> are so similar, I would expect the refactoring
> >>>>>
> >> of
> >>
> >>>>>
> >>>>>
> >>>> a
> >>>>
> >>>>
> >>>>> custom InstantiatingReflector implementation
> to
> >>>>>
> >> a
> >>
> >>>>> custom Converter implementation to be trivial.
> >>>>>
> >>>>> I invite discussion, but I really think I have
> >>>>> something here.
> >>>>>
> >>>>> Impatiently awaiting comment,
> >>>>> Matt B
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
>
____________________________________________________________________________________
> >
> >>>
> >>>
> >>>>> We won't tell. Get more on shows you hate to
> >>>>>
> >> love
> >>
> >>>>> (and love to hate): Yahoo! TV's Guilty
> Pleasures
> >>>>>
> >>>>>
> >>>> list.
> >>>>
> >>>>
> >>>>> http://tv.yahoo.com/collections/265
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
>
-------------------------------------------------------------------------
> >
> >>>
> >>>
> >>>>> Using Tomcat but need to do more? Need to
> >>>>>
> >> support
> >>
> >>>>>
> >>>>>
> >>>> web services, security?
> >>>>
> >>>>
> >>>>> Get stuff done quickly with pre-integrated
> >>>>>
> >>>>>
> >>>> technology to make your job easier.
> >>>>
> >>>>
> >>>>> Download IBM WebSphere Application Server
> >>>>>
> >> v.1.0.1
> >>
> >>>>>
> >>>>>
> >>>> based on Apache Geronimo
> >>>>
> >>>>
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> >>>
> >>>
> >>>>>
> _______________________________________________
> >>>>> morph-developer mailing list
> >>>>> mor...@li...
> >>>>>
> >>>>>
> >>>>>
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >>>
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >
>
-------------------------------------------------------------------------
> >
> >>>
> >>>
> >>>> Using Tomcat but need to do more? Need to
> support
> >>>> web services, security?
> >>>> Get stuff done quickly with pre-integrated
> >>>> technology to make your job easier.
> >>>> Download IBM WebSphere Application Server
> v.1.0.1
> >>>> based on Apache Geronimo
> >>>>
> >>>>
> >>>>
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> >>>
> >>>
> >>>> _______________________________________________
> >>>> morph-developer mailing list
> >>>> mor...@li...
> >>>>
> >>>>
> >>>>
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
____________________________________________________________________________________
> >
> >>> Yahoo! Music Unlimited
> >>> Access over 1 million songs.
> >>> http://music.yahoo.com/unlimited
> >>>
> >>>
> >>>
> >
>
-------------------------------------------------------------------------
> >
> >>> Using Tomcat but need to do more? Need to
> support
> >>>
> >> web services, security?
> >>
> >>> Get stuff done quickly with pre-integrated
> >>>
> >> technology to make your job easier.
> >>
> >>> Download IBM WebSphere Application Server
> v.1.0.1
> >>>
> >> based on Apache Geronimo
> >>
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> >>> _______________________________________________
> >>> morph-developer mailing list
> >>> mor...@li...
> >>>
> >>>
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >>>
> >>>
> >
>
-------------------------------------------------------------------------
> >
> >> Using Tomcat but need to do more? Need to support
> >> web services, security?
> >> Get stuff done quickly with pre-integrated
> >> technology to make your job easier.
> >> Download IBM WebSphere Application Server v.1.0.1
> >> based on Apache Geronimo
> >>
> >>
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
> > _______________________________________________
> >
> >> morph-developer mailing list
> >> mor...@li...
> >>
> >>
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >
> >
> >
> >
> >
>
____________________________________________________________________________________
> > TV dinner still cooling?
> > Check out "Tonight's Picks" on Yahoo! TV.
> > http://tv.yahoo.com/
> >
> >
>
-------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support
> web services, security?
> > Get stuff done quickly with pre-integrated
> technology to make your job easier.
> > Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >
>
> >
-------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support
> web services, security?
> Get stuff done quickly with pre-integrated
> technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
_______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
>
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
|
|
From: Matt S. <Mat...@wh...> - 2007-02-05 22:38:45
|
To me, "how do we get the destination instance for a conversion" could
be reworded "how do we instantiate the destination instance for a
conversion" to which the answer "write an InstantiatingReflector" seems
a logical answer. If our goal is to "make the experience of working
with Morph one of writing tiny classes to do very specific things which
can then be arranged by configuration to accomplish the large tasks",
setting up an InstantiatingReflector provides a separate abstraction
concerned with creating objects.
If the goal is to only have to write one class that references a given
type of domain object, I think a transformer extended from
BaseTransformer that implements convertImpl and copyImpl will fit the
bill (this is what I was talking about in my last email).
I am confused by what you mean by "I suppose it would be possible to add
the parent converter concept to BaseTransformer without using a new
interface--the default converter could delegate to the BaseTransformer
instance's (Instantiating-) Reflector..." BaseTransformer already has a
reflector property which you can use to plug in your instantiating
reflector. It's a little more complicated because you actually have to
supply a SimpleDelegatingReflector that has your InstantiatingReflector
added to its list of delegates, but the capability is there. I would
assume this is the mechanism Ben Alex is using to plug in his
InstantiatingReflectors.
By the way, it's called a SimpleInstantingReflector for a reason: I
anticipate we'll write a better one with a better name at some point.
For example, one could imagine a RegisteryReflector that has methods
like registerReflector(String name, Reflector reflector) that would make
it easier to setup custom reflectors. There could also be a
RegistryTransformer with methods like registerTransformer(String name,
Transformer transformer) and even registerReflector(String name,
Reflector reflector) to make it much simpler to integrate a few custom
reflectors and transformers with Morph's built-in capabilities. Is this
what you're getting at, that it's too difficult to configure Morph? On
this point I wholeheartedly agree and I think there are some simple
things we could do to improve the situation. I don't think we need any
new abstractions though, just new and better implementations of
composite Reflectors and Transformers.
Matt S
Matt Benson wrote:
> I can see your point here, and concede that it is
> possible to continue as-is. I guess I am aiming for
> trying to make the experience of working with Morph
> one of writing tiny classes to do very specific things
> which can then be arranged by configuration to
> accomplish the large tasks. So when we see something
> as common as "how do we get the destination instance
> for a conversion" that makes an attractive extension
> point. I suppose it would be possible to add the
> parent converter concept to BaseTransformer without
> using a new interface--the default converter could
> delegate to the BaseTransformer instance's
> (Instantiating-) Reflector so as to preserve the
> status quo while permitting the granular customization
> I am after... would this sound like a reasonable
> compromise to you?
>
> -Matt B
>
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>
>> Hello again Matt B - thanks for following up on this
>> issue, because I
>> think it's important we get this right. One of the
>> main benefits of
>> Morph over other frameworks is the strength of its
>> abstractions, and
>> right now it seems like Morph is falling flat on its
>> face when dealing
>> with objects that don't have a public no-arg
>> constructor.
>>
>> I see what you're getting at with the
>> DerivedConverter, but I'm not
>> convinced that a new interface is needed here. What
>> should be happening
>> to avoid use of the InstantiatingReflector is simply
>> overriding the
>> convertImpl method to do the desired conversion
>> operation. I know the
>> default implementation looks scary:
>>
>> Object reuseableSource =
>> createReusableSource(destinationClass,
>> source);
>> Object newInstance =
>> createNewInstanceImpl(destinationClass,
>> reuseableSource);
>> copyImpl(newInstance, reuseableSource,
>> locale,
>> Converter.TRANSFORMATION_TYPE_CONVERT);
>> return newInstance;
>>
>> but overriding it isn't nearly so horrid:
>>
>> Object newInstance = new ComplexObject(arg1,
>> arg2, arg3);
>> copyImpl(newInstance, source, locale,
>> Converter.TRANSFORMATION_TYPE_CONVERT);
>> return newInstance;
>>
>> I really think the problem here is just the comments
>> on the convertImpl
>> method. The documentation states "this
>> implementation should be fine
>> as-is for Copiers" when instead it should state "you
>> will need to
>> override this method if your destination object does
>> not have a public
>> no-arg constructor".
>>
>> In terms of strengthening abstractions for the
>> AssemblerCopier and
>> DisassemblerCopier, I think that's an issue for
>> those copiers to
>> address, not for BaseTransformer.
>>
>> Matt S
>>
>> Matt Benson wrote:
>>
>>> Okay... my design might be somewhat crippled by
>>>
>> the
>>
>>> attempt to be as non-disruptive as possible:
>>>
>>> /** A converter derived from another converter */
>>> interface DerivedConverter extends Converter {
>>> Converter getParentConverter();
>>> }
>>>
>>> Basically I think BaseTransformer would provide
>>>
>> the
>>
>>> DerivedConverter implementation something like
>>>
>> this:
>>
>>> public class BaseTransformer ... {
>>> private static final Converter DEFAULT_PARENT =
>>>
>> new
>>
>>> NewInstanceConverter();
>>>
>>> private Converter parentConverter;
>>>
>>> public Converter getParentConverter() {
>>> return parentConverter == null ?
>>>
>> DEFAULT_PARENT :
>>
>>> parentConverter;
>>> }
>>>
>>> public void setParentConverter() { //routine }
>>>
>>> protected Object convertImpl(Class
>>>
>> destinationClass,
>>
>>> Object source,
>>> Locale locale) throws Exception {
>>> if (!(this instanceof DerivedConverter)) {
>>> throw new UnsupportedOperation();
>>> }
>>> Object reuseableSource =
>>> createReusableSource(destinationClass, source);
>>> Object destObject =
>>> getParentConverter().convert(destinationClass,
>>> reuseableSource);
>>> copyImpl(destObject, reuseableSource, locale,
>>> Converter.TRANSFORMATION_TYPE_CONVERT);
>>> return destObject;
>>> }
>>> }
>>>
>>> Again, we are talking ultimately about an entity
>>>
>> that
>>
>>> transforms a source object to an instance of a
>>> specified destination class. If we do away with
>>>
>> the
>>
>>> InstantiatingReflector concept, AT LEAST where
>>> converters are concerned, Morph becomes more
>>> versatile, because any converter can be used as
>>>
>> the
>>
>>> parent converter in a derivedConverter
>>>
>> implementation.
>>
>>> A concrete example:
>>>
>>> Morph contains a (-n unfinished)
>>> MultipleDestinationConverter. This can also be
>>>
>> viewed
>>
>>> as a DisassemblerCopier (complemented by my
>>>
>> recently
>>
>>> added AssemblerCopier). In terms of implementing
>>> copying, this is pretty simple. You have a list
>>>
>> of
>>
>>> copier children which should be the same size as
>>>
>> the
>>
>>> destination object container. The component
>>>
>> copiers
>>
>>> are invoked one at a time from the source object
>>>
>> to
>>
>>> the corresponding child in the destination
>>>
>> container.
>>
>>> The existing partial MultipleDestinationConverter
>>> implementation uses a list of classes to tell it
>>>
>> how
>>
>>> to create the destination object when implementing
>>> Converter. But this is still a case of "we know
>>>
>> how
>>
>>> to copy and we just need to know how to create the
>>> destination object". InstantiatingReflector
>>>
>> doesn't
>>
>>> fully represent the concept of creating a
>>>
>> (probably
>>
>>> heterogenous) collection of destination objects
>>>
>> IMHO.
>>
>>> But a parent Converter is semantically open-ended
>>>
>> and,
>>
>>> I believe, describes both situations fairly: the
>>> simple (.newInstance()) as well as the complex.
>>>
>>> Does that make anything any clearer?
>>>
>>> -MJB
>>>
>>> --- Matt Sgarlata
>>> <Mat...@wh...> wrote:
>>>
>>>
>>>
>>>> I agree, the addition of the "Object parameters"
>>>> parameter to
>>>> InstantiatingReflector.newInstance is worrisome.
>>>> The idea behind a
>>>> Reflector in general is that it tells you how to
>>>> work with some new type
>>>> of object that has properties which are not known
>>>> until runtime. For
>>>> example, Maps, DynaBeans, ResultSets, etc. If
>>>>
>> you
>>
>>>> have some sort of
>>>> domain object there should be no need to write a
>>>> reflector, because
>>>> Morph's built-in ObjectReflector can use Java's
>>>> built-in reflection
>>>> capabilities to determine the properties of the
>>>> object. If you just
>>>> want to be able to convert stuff, it should be
>>>> sufficient to write a
>>>> single Transformer that implements both Converter
>>>> and Copier interfaces
>>>> and doesn't mess with InstantiatingReflectors at
>>>> all.
>>>>
>>>> That said, I think the
>>>> InstantiatingReflector.newInstance method is
>>>> something that should be present in the API and
>>>>
>> not
>>
>>>> deprecated. We can
>>>> and should specify in the comments what this
>>>>
>> method
>>
>>>> should and should
>>>> not be used for. However, it is possible that
>>>>
>> some
>>
>>>> types of dynamic
>>>> objects would require extra information before
>>>>
>> they
>>
>>>> are created. For
>>>> example, the BasicDynaBean has no default
>>>> constructor and requires a
>>>> DynaClass to be constructed. Its properties are
>>>>
>> not
>>
>>>> known until
>>>> runtime, but the DynaClass provides a contract
>>>> describing the object's
>>>> properties, etc.
>>>>
>>>> So in summary, I'm saying I think we have a
>>>> documentation issue not an
>>>> API issue. However, I don't fully understand
>>>>
>> what
>>
>>>> API changes you are
>>>> proposing, so could you post some pseudo code for
>>>>
>> us
>>
>>>> to look at?
>>>>
>>>> Thanks,
>>>>
>>>> Matt S
>>>>
>>>> Matt Benson wrote:
>>>>
>>>>
>>>>> I am reawakening this thread. I touched on this
>>>>> subject during the original discussion, but at
>>>>>
>> the
>>
>>>>> time I couldn't quite articulate what was
>>>>>
>>>>>
>>>> bothering me
>>>>
>>>>
>>>>> about the whole business. Last Friday it burst
>>>>>
>>>>>
>>>> upon
>>>>
>>>>
>>>>> me, and I have continued to kick it around over
>>>>>
>>>>>
>>>> the
>>>>
>>>>
>>>>> weekend but have not been able to refute my own
>>>>>
>>>>>
>>>> logic:
>>>>
>>>>
>>>>> Basically with InstantiatingReflector taking a
>>>>>
>>>>>
>>>> source
>>>>
>>>>
>>>>> parameter, it IS a converter. What is the
>>>>>
>>>>>
>>>> difference
>>>>
>>>>
>>>>> between:
>>>>>
>>>>> InstantiatingReflector.newInstance(Class,
>>>>>
>> Object)
>>
>>>>> -and-
>>>>> DecoratedConverter.convert(Class, Object)
>>>>> ?
>>>>>
>>>>> >From my POV, nothing. Different semantics for
>>>>>
>>>>>
>>>> what,
>>>>
>>>>
>>>>> using the method parameters as an indicator, is
>>>>>
>>>>>
>>>> one
>>>>
>>>>
>>>>> concept. The role of the InstantiatingReflector
>>>>>
>>>>>
>>>> in
>>>>
>>>>
>>>>> the Morph library is to adapt a copier to the
>>>>> converter interface, using the following
>>>>>
>>>>>
>>>> algorithm:
>>>>
>>>>
>>>>> 1. Create a new instance I
>>>>> 2. Invoke copy() using I as the destination
>>>>>
>>>>>
>>>> object.
>>>>
>>>>
>>>>> This sequence of operations amounts to a
>>>>>
>> "derived
>>
>>>>> conversion": one which relies on a parent
>>>>>
>>>>>
>>>> conversion
>>>>
>>>>
>>>>> to supply the target object, then modifies the
>>>>> resulting object. This modification will always
>>>>> consist of making changes on a target object
>>>>>
>> based
>>
>>>>>
>>>>>
>>>> on
>>>>
>>>>
>>>>> the source object (otherwise the parent
>>>>>
>> converter
>>
>>>>> alone would suffice), and thus infallibly
>>>>>
>>>>>
>>>> corresponds
>>>>
>>>>
>>>>> in intent with Copier.copy(). This proves that
>>>>>
>> a
>>
>>>>> DerivedConverter is precisely a Copier that
>>>>>
>>>>>
>>>> implements
>>>>
>>>>
>>>>> Converter by first delegating to a parent
>>>>>
>>>>>
>>>> Converter,
>>>>
>>>>
>>>>> then copies the source to the resulting
>>>>>
>>>>>
>>>> destination
>>>>
>>>>
>>>>> object. The parent converter can be overridden,
>>>>>
>>>>>
>>>> but
>>>>
>>>>
>>>>> would default to an, e.g., NewInstanceConverter
>>>>>
>>>>>
>>>> which
>>>>
>>>>
>>>>> simply creates a new instance of the
>>>>>
>>>>>
>>>> destinationClass.
>>>>
>>>>
>>>>> In adopting the DerivedConverter concept,
>>>>> InstantiatingReflector would, in my opinion, no
>>>>>
>>>>>
>>>> longer
>>>>
>>>>
>>>>> be needed, and would hopefully be deprecated and
>>>>>
>>>>>
>>>> then
>>>>
>>>>
>>>>> removed as soon as the current players on the
>>>>>
>>>>>
>>>> mailing
>>>>
>>>>
>>>>> list(s) are all up to speed. Because the
>>>>>
>>>>>
>>>> interfaces
>>>>
>>>>
>>>>> are so similar, I would expect the refactoring
>>>>>
>> of
>>
>>>>>
>>>>>
>>>> a
>>>>
>>>>
>>>>> custom InstantiatingReflector implementation to
>>>>>
>> a
>>
>>>>> custom Converter implementation to be trivial.
>>>>>
>>>>> I invite discussion, but I really think I have
>>>>> something here.
>>>>>
>>>>> Impatiently awaiting comment,
>>>>> Matt B
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> ____________________________________________________________________________________
>
>>>
>>>
>>>>> We won't tell. Get more on shows you hate to
>>>>>
>> love
>>
>>>>> (and love to hate): Yahoo! TV's Guilty Pleasures
>>>>>
>>>>>
>>>> list.
>>>>
>>>>
>>>>> http://tv.yahoo.com/collections/265
>>>>>
>>>>>
>>>>>
>>>>>
> -------------------------------------------------------------------------
>
>>>
>>>
>>>>> Using Tomcat but need to do more? Need to
>>>>>
>> support
>>
>>>>>
>>>>>
>>>> web services, security?
>>>>
>>>>
>>>>> Get stuff done quickly with pre-integrated
>>>>>
>>>>>
>>>> technology to make your job easier.
>>>>
>>>>
>>>>> Download IBM WebSphere Application Server
>>>>>
>> v.1.0.1
>>
>>>>>
>>>>>
>>>> based on Apache Geronimo
>>>>
>>>>
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>>>
>>>
>>>>> _______________________________________________
>>>>> morph-developer mailing list
>>>>> mor...@li...
>>>>>
>>>>>
>>>>>
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
> -------------------------------------------------------------------------
>
>>>
>>>
>>>> Using Tomcat but need to do more? Need to support
>>>> web services, security?
>>>> Get stuff done quickly with pre-integrated
>>>> technology to make your job easier.
>>>> Download IBM WebSphere Application Server v.1.0.1
>>>> based on Apache Geronimo
>>>>
>>>>
>>>>
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>>>
>>>
>>>> _______________________________________________
>>>> morph-developer mailing list
>>>> mor...@li...
>>>>
>>>>
>>>>
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> ____________________________________________________________________________________
>
>>> Yahoo! Music Unlimited
>>> Access over 1 million songs.
>>> http://music.yahoo.com/unlimited
>>>
>>>
>>>
> -------------------------------------------------------------------------
>
>>> Using Tomcat but need to do more? Need to support
>>>
>> web services, security?
>>
>>> Get stuff done quickly with pre-integrated
>>>
>> technology to make your job easier.
>>
>>> Download IBM WebSphere Application Server v.1.0.1
>>>
>> based on Apache Geronimo
>>
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>>> _______________________________________________
>>> morph-developer mailing list
>>> mor...@li...
>>>
>>>
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>>>
>>>
> -------------------------------------------------------------------------
>
>> Using Tomcat but need to do more? Need to support
>> web services, security?
>> Get stuff done quickly with pre-integrated
>> technology to make your job easier.
>> Download IBM WebSphere Application Server v.1.0.1
>> based on Apache Geronimo
>>
>>
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
> _______________________________________________
>
>> morph-developer mailing list
>> mor...@li...
>>
>>
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>
>
>
>
> ____________________________________________________________________________________
> TV dinner still cooling?
> Check out "Tonight's Picks" on Yahoo! TV.
> http://tv.yahoo.com/
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>
|
|
From: Matt B. <gud...@ya...> - 2007-02-05 22:06:35
|
I can see your point here, and concede that it is
possible to continue as-is. I guess I am aiming for
trying to make the experience of working with Morph
one of writing tiny classes to do very specific things
which can then be arranged by configuration to
accomplish the large tasks. So when we see something
as common as "how do we get the destination instance
for a conversion" that makes an attractive extension
point. I suppose it would be possible to add the
parent converter concept to BaseTransformer without
using a new interface--the default converter could
delegate to the BaseTransformer instance's
(Instantiating-) Reflector so as to preserve the
status quo while permitting the granular customization
I am after... would this sound like a reasonable
compromise to you?
-Matt B
--- Matt Sgarlata
<Mat...@wh...> wrote:
> Hello again Matt B - thanks for following up on this
> issue, because I
> think it's important we get this right. One of the
> main benefits of
> Morph over other frameworks is the strength of its
> abstractions, and
> right now it seems like Morph is falling flat on its
> face when dealing
> with objects that don't have a public no-arg
> constructor.
>
> I see what you're getting at with the
> DerivedConverter, but I'm not
> convinced that a new interface is needed here. What
> should be happening
> to avoid use of the InstantiatingReflector is simply
> overriding the
> convertImpl method to do the desired conversion
> operation. I know the
> default implementation looks scary:
>
> Object reuseableSource =
> createReusableSource(destinationClass,
> source);
> Object newInstance =
> createNewInstanceImpl(destinationClass,
> reuseableSource);
> copyImpl(newInstance, reuseableSource,
> locale,
> Converter.TRANSFORMATION_TYPE_CONVERT);
> return newInstance;
>
> but overriding it isn't nearly so horrid:
>
> Object newInstance = new ComplexObject(arg1,
> arg2, arg3);
> copyImpl(newInstance, source, locale,
> Converter.TRANSFORMATION_TYPE_CONVERT);
> return newInstance;
>
> I really think the problem here is just the comments
> on the convertImpl
> method. The documentation states "this
> implementation should be fine
> as-is for Copiers" when instead it should state "you
> will need to
> override this method if your destination object does
> not have a public
> no-arg constructor".
>
> In terms of strengthening abstractions for the
> AssemblerCopier and
> DisassemblerCopier, I think that's an issue for
> those copiers to
> address, not for BaseTransformer.
>
> Matt S
>
> Matt Benson wrote:
> > Okay... my design might be somewhat crippled by
> the
> > attempt to be as non-disruptive as possible:
> >
> > /** A converter derived from another converter */
> > interface DerivedConverter extends Converter {
> > Converter getParentConverter();
> > }
> >
> > Basically I think BaseTransformer would provide
> the
> > DerivedConverter implementation something like
> this:
> >
> > public class BaseTransformer ... {
> > private static final Converter DEFAULT_PARENT =
> new
> > NewInstanceConverter();
> >
> > private Converter parentConverter;
> >
> > public Converter getParentConverter() {
> > return parentConverter == null ?
> DEFAULT_PARENT :
> > parentConverter;
> > }
> >
> > public void setParentConverter() { //routine }
> >
> > protected Object convertImpl(Class
> destinationClass,
> > Object source,
> > Locale locale) throws Exception {
> > if (!(this instanceof DerivedConverter)) {
> > throw new UnsupportedOperation();
> > }
> > Object reuseableSource =
> > createReusableSource(destinationClass, source);
> > Object destObject =
> > getParentConverter().convert(destinationClass,
> > reuseableSource);
> > copyImpl(destObject, reuseableSource, locale,
> > Converter.TRANSFORMATION_TYPE_CONVERT);
> > return destObject;
> > }
> > }
> >
> > Again, we are talking ultimately about an entity
> that
> > transforms a source object to an instance of a
> > specified destination class. If we do away with
> the
> > InstantiatingReflector concept, AT LEAST where
> > converters are concerned, Morph becomes more
> > versatile, because any converter can be used as
> the
> > parent converter in a derivedConverter
> implementation.
> > A concrete example:
> >
> > Morph contains a (-n unfinished)
> > MultipleDestinationConverter. This can also be
> viewed
> > as a DisassemblerCopier (complemented by my
> recently
> > added AssemblerCopier). In terms of implementing
> > copying, this is pretty simple. You have a list
> of
> > copier children which should be the same size as
> the
> > destination object container. The component
> copiers
> > are invoked one at a time from the source object
> to
> > the corresponding child in the destination
> container.
> > The existing partial MultipleDestinationConverter
> > implementation uses a list of classes to tell it
> how
> > to create the destination object when implementing
> > Converter. But this is still a case of "we know
> how
> > to copy and we just need to know how to create the
> > destination object". InstantiatingReflector
> doesn't
> > fully represent the concept of creating a
> (probably
> > heterogenous) collection of destination objects
> IMHO.
> > But a parent Converter is semantically open-ended
> and,
> > I believe, describes both situations fairly: the
> > simple (.newInstance()) as well as the complex.
> >
> > Does that make anything any clearer?
> >
> > -MJB
> >
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >
> >> I agree, the addition of the "Object parameters"
> >> parameter to
> >> InstantiatingReflector.newInstance is worrisome.
> >> The idea behind a
> >> Reflector in general is that it tells you how to
> >> work with some new type
> >> of object that has properties which are not known
> >> until runtime. For
> >> example, Maps, DynaBeans, ResultSets, etc. If
> you
> >> have some sort of
> >> domain object there should be no need to write a
> >> reflector, because
> >> Morph's built-in ObjectReflector can use Java's
> >> built-in reflection
> >> capabilities to determine the properties of the
> >> object. If you just
> >> want to be able to convert stuff, it should be
> >> sufficient to write a
> >> single Transformer that implements both Converter
> >> and Copier interfaces
> >> and doesn't mess with InstantiatingReflectors at
> >> all.
> >>
> >> That said, I think the
> >> InstantiatingReflector.newInstance method is
> >> something that should be present in the API and
> not
> >> deprecated. We can
> >> and should specify in the comments what this
> method
> >> should and should
> >> not be used for. However, it is possible that
> some
> >> types of dynamic
> >> objects would require extra information before
> they
> >> are created. For
> >> example, the BasicDynaBean has no default
> >> constructor and requires a
> >> DynaClass to be constructed. Its properties are
> not
> >> known until
> >> runtime, but the DynaClass provides a contract
> >> describing the object's
> >> properties, etc.
> >>
> >> So in summary, I'm saying I think we have a
> >> documentation issue not an
> >> API issue. However, I don't fully understand
> what
> >> API changes you are
> >> proposing, so could you post some pseudo code for
> us
> >> to look at?
> >>
> >> Thanks,
> >>
> >> Matt S
> >>
> >> Matt Benson wrote:
> >>
> >>> I am reawakening this thread. I touched on this
> >>> subject during the original discussion, but at
> the
> >>> time I couldn't quite articulate what was
> >>>
> >> bothering me
> >>
> >>> about the whole business. Last Friday it burst
> >>>
> >> upon
> >>
> >>> me, and I have continued to kick it around over
> >>>
> >> the
> >>
> >>> weekend but have not been able to refute my own
> >>>
> >> logic:
> >>
> >>> Basically with InstantiatingReflector taking a
> >>>
> >> source
> >>
> >>> parameter, it IS a converter. What is the
> >>>
> >> difference
> >>
> >>> between:
> >>>
> >>> InstantiatingReflector.newInstance(Class,
> Object)
> >>> -and-
> >>> DecoratedConverter.convert(Class, Object)
> >>> ?
> >>>
> >>> >From my POV, nothing. Different semantics for
> >>>
> >> what,
> >>
> >>> using the method parameters as an indicator, is
> >>>
> >> one
> >>
> >>> concept. The role of the InstantiatingReflector
> >>>
> >> in
> >>
> >>> the Morph library is to adapt a copier to the
> >>> converter interface, using the following
> >>>
> >> algorithm:
> >>
> >>> 1. Create a new instance I
> >>> 2. Invoke copy() using I as the destination
> >>>
> >> object.
> >>
> >>> This sequence of operations amounts to a
> "derived
> >>> conversion": one which relies on a parent
> >>>
> >> conversion
> >>
> >>> to supply the target object, then modifies the
> >>> resulting object. This modification will always
> >>> consist of making changes on a target object
> based
> >>>
> >> on
> >>
> >>> the source object (otherwise the parent
> converter
> >>> alone would suffice), and thus infallibly
> >>>
> >> corresponds
> >>
> >>> in intent with Copier.copy(). This proves that
> a
> >>> DerivedConverter is precisely a Copier that
> >>>
> >> implements
> >>
> >>> Converter by first delegating to a parent
> >>>
> >> Converter,
> >>
> >>> then copies the source to the resulting
> >>>
> >> destination
> >>
> >>> object. The parent converter can be overridden,
> >>>
> >> but
> >>
> >>> would default to an, e.g., NewInstanceConverter
> >>>
> >> which
> >>
> >>> simply creates a new instance of the
> >>>
> >> destinationClass.
> >>
> >>> In adopting the DerivedConverter concept,
> >>> InstantiatingReflector would, in my opinion, no
> >>>
> >> longer
> >>
> >>> be needed, and would hopefully be deprecated and
> >>>
> >> then
> >>
> >>> removed as soon as the current players on the
> >>>
> >> mailing
> >>
> >>> list(s) are all up to speed. Because the
> >>>
> >> interfaces
> >>
> >>> are so similar, I would expect the refactoring
> of
> >>>
> >> a
> >>
> >>> custom InstantiatingReflector implementation to
> a
> >>> custom Converter implementation to be trivial.
> >>>
> >>> I invite discussion, but I really think I have
> >>> something here.
> >>>
> >>> Impatiently awaiting comment,
> >>> Matt B
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
____________________________________________________________________________________
> >
> >>> We won't tell. Get more on shows you hate to
> love
> >>> (and love to hate): Yahoo! TV's Guilty Pleasures
> >>>
> >> list.
> >>
> >>> http://tv.yahoo.com/collections/265
> >>>
> >>>
> >>>
> >
>
-------------------------------------------------------------------------
> >
> >>> Using Tomcat but need to do more? Need to
> support
> >>>
> >> web services, security?
> >>
> >>> Get stuff done quickly with pre-integrated
> >>>
> >> technology to make your job easier.
> >>
> >>> Download IBM WebSphere Application Server
> v.1.0.1
> >>>
> >> based on Apache Geronimo
> >>
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> >>> _______________________________________________
> >>> morph-developer mailing list
> >>> mor...@li...
> >>>
> >>>
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >>>
> >>>
> >>
> >>
> >
>
-------------------------------------------------------------------------
> >
> >> Using Tomcat but need to do more? Need to support
> >> web services, security?
> >> Get stuff done quickly with pre-integrated
> >> technology to make your job easier.
> >> Download IBM WebSphere Application Server v.1.0.1
> >> based on Apache Geronimo
> >>
> >>
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> >> _______________________________________________
> >> morph-developer mailing list
> >> mor...@li...
> >>
> >>
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >
> >
> >
> >
> >
> >
>
____________________________________________________________________________________
> > Yahoo! Music Unlimited
> > Access over 1 million songs.
> > http://music.yahoo.com/unlimited
> >
> >
>
-------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support
> web services, security?
> > Get stuff done quickly with pre-integrated
> technology to make your job easier.
> > Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >
>
> >
-------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support
> web services, security?
> Get stuff done quickly with pre-integrated
> technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
_______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
>
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
|
|
From: Matt S. <Mat...@wh...> - 2007-02-05 21:35:32
|
Hello again Matt B - thanks for following up on this issue, because I
think it's important we get this right. One of the main benefits of
Morph over other frameworks is the strength of its abstractions, and
right now it seems like Morph is falling flat on its face when dealing
with objects that don't have a public no-arg constructor.
I see what you're getting at with the DerivedConverter, but I'm not
convinced that a new interface is needed here. What should be happening
to avoid use of the InstantiatingReflector is simply overriding the
convertImpl method to do the desired conversion operation. I know the
default implementation looks scary:
Object reuseableSource = createReusableSource(destinationClass,
source);
Object newInstance = createNewInstanceImpl(destinationClass,
reuseableSource);
copyImpl(newInstance, reuseableSource, locale,
Converter.TRANSFORMATION_TYPE_CONVERT);
return newInstance;
but overriding it isn't nearly so horrid:
Object newInstance = new ComplexObject(arg1, arg2, arg3);
copyImpl(newInstance, source, locale,
Converter.TRANSFORMATION_TYPE_CONVERT);
return newInstance;
I really think the problem here is just the comments on the convertImpl
method. The documentation states "this implementation should be fine
as-is for Copiers" when instead it should state "you will need to
override this method if your destination object does not have a public
no-arg constructor".
In terms of strengthening abstractions for the AssemblerCopier and
DisassemblerCopier, I think that's an issue for those copiers to
address, not for BaseTransformer.
Matt S
Matt Benson wrote:
> Okay... my design might be somewhat crippled by the
> attempt to be as non-disruptive as possible:
>
> /** A converter derived from another converter */
> interface DerivedConverter extends Converter {
> Converter getParentConverter();
> }
>
> Basically I think BaseTransformer would provide the
> DerivedConverter implementation something like this:
>
> public class BaseTransformer ... {
> private static final Converter DEFAULT_PARENT = new
> NewInstanceConverter();
>
> private Converter parentConverter;
>
> public Converter getParentConverter() {
> return parentConverter == null ? DEFAULT_PARENT :
> parentConverter;
> }
>
> public void setParentConverter() { //routine }
>
> protected Object convertImpl(Class destinationClass,
> Object source,
> Locale locale) throws Exception {
> if (!(this instanceof DerivedConverter)) {
> throw new UnsupportedOperation();
> }
> Object reuseableSource =
> createReusableSource(destinationClass, source);
> Object destObject =
> getParentConverter().convert(destinationClass,
> reuseableSource);
> copyImpl(destObject, reuseableSource, locale,
> Converter.TRANSFORMATION_TYPE_CONVERT);
> return destObject;
> }
> }
>
> Again, we are talking ultimately about an entity that
> transforms a source object to an instance of a
> specified destination class. If we do away with the
> InstantiatingReflector concept, AT LEAST where
> converters are concerned, Morph becomes more
> versatile, because any converter can be used as the
> parent converter in a derivedConverter implementation.
> A concrete example:
>
> Morph contains a (-n unfinished)
> MultipleDestinationConverter. This can also be viewed
> as a DisassemblerCopier (complemented by my recently
> added AssemblerCopier). In terms of implementing
> copying, this is pretty simple. You have a list of
> copier children which should be the same size as the
> destination object container. The component copiers
> are invoked one at a time from the source object to
> the corresponding child in the destination container.
> The existing partial MultipleDestinationConverter
> implementation uses a list of classes to tell it how
> to create the destination object when implementing
> Converter. But this is still a case of "we know how
> to copy and we just need to know how to create the
> destination object". InstantiatingReflector doesn't
> fully represent the concept of creating a (probably
> heterogenous) collection of destination objects IMHO.
> But a parent Converter is semantically open-ended and,
> I believe, describes both situations fairly: the
> simple (.newInstance()) as well as the complex.
>
> Does that make anything any clearer?
>
> -MJB
>
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>
>> I agree, the addition of the "Object parameters"
>> parameter to
>> InstantiatingReflector.newInstance is worrisome.
>> The idea behind a
>> Reflector in general is that it tells you how to
>> work with some new type
>> of object that has properties which are not known
>> until runtime. For
>> example, Maps, DynaBeans, ResultSets, etc. If you
>> have some sort of
>> domain object there should be no need to write a
>> reflector, because
>> Morph's built-in ObjectReflector can use Java's
>> built-in reflection
>> capabilities to determine the properties of the
>> object. If you just
>> want to be able to convert stuff, it should be
>> sufficient to write a
>> single Transformer that implements both Converter
>> and Copier interfaces
>> and doesn't mess with InstantiatingReflectors at
>> all.
>>
>> That said, I think the
>> InstantiatingReflector.newInstance method is
>> something that should be present in the API and not
>> deprecated. We can
>> and should specify in the comments what this method
>> should and should
>> not be used for. However, it is possible that some
>> types of dynamic
>> objects would require extra information before they
>> are created. For
>> example, the BasicDynaBean has no default
>> constructor and requires a
>> DynaClass to be constructed. Its properties are not
>> known until
>> runtime, but the DynaClass provides a contract
>> describing the object's
>> properties, etc.
>>
>> So in summary, I'm saying I think we have a
>> documentation issue not an
>> API issue. However, I don't fully understand what
>> API changes you are
>> proposing, so could you post some pseudo code for us
>> to look at?
>>
>> Thanks,
>>
>> Matt S
>>
>> Matt Benson wrote:
>>
>>> I am reawakening this thread. I touched on this
>>> subject during the original discussion, but at the
>>> time I couldn't quite articulate what was
>>>
>> bothering me
>>
>>> about the whole business. Last Friday it burst
>>>
>> upon
>>
>>> me, and I have continued to kick it around over
>>>
>> the
>>
>>> weekend but have not been able to refute my own
>>>
>> logic:
>>
>>> Basically with InstantiatingReflector taking a
>>>
>> source
>>
>>> parameter, it IS a converter. What is the
>>>
>> difference
>>
>>> between:
>>>
>>> InstantiatingReflector.newInstance(Class, Object)
>>> -and-
>>> DecoratedConverter.convert(Class, Object)
>>> ?
>>>
>>> >From my POV, nothing. Different semantics for
>>>
>> what,
>>
>>> using the method parameters as an indicator, is
>>>
>> one
>>
>>> concept. The role of the InstantiatingReflector
>>>
>> in
>>
>>> the Morph library is to adapt a copier to the
>>> converter interface, using the following
>>>
>> algorithm:
>>
>>> 1. Create a new instance I
>>> 2. Invoke copy() using I as the destination
>>>
>> object.
>>
>>> This sequence of operations amounts to a "derived
>>> conversion": one which relies on a parent
>>>
>> conversion
>>
>>> to supply the target object, then modifies the
>>> resulting object. This modification will always
>>> consist of making changes on a target object based
>>>
>> on
>>
>>> the source object (otherwise the parent converter
>>> alone would suffice), and thus infallibly
>>>
>> corresponds
>>
>>> in intent with Copier.copy(). This proves that a
>>> DerivedConverter is precisely a Copier that
>>>
>> implements
>>
>>> Converter by first delegating to a parent
>>>
>> Converter,
>>
>>> then copies the source to the resulting
>>>
>> destination
>>
>>> object. The parent converter can be overridden,
>>>
>> but
>>
>>> would default to an, e.g., NewInstanceConverter
>>>
>> which
>>
>>> simply creates a new instance of the
>>>
>> destinationClass.
>>
>>> In adopting the DerivedConverter concept,
>>> InstantiatingReflector would, in my opinion, no
>>>
>> longer
>>
>>> be needed, and would hopefully be deprecated and
>>>
>> then
>>
>>> removed as soon as the current players on the
>>>
>> mailing
>>
>>> list(s) are all up to speed. Because the
>>>
>> interfaces
>>
>>> are so similar, I would expect the refactoring of
>>>
>> a
>>
>>> custom InstantiatingReflector implementation to a
>>> custom Converter implementation to be trivial.
>>>
>>> I invite discussion, but I really think I have
>>> something here.
>>>
>>> Impatiently awaiting comment,
>>> Matt B
>>>
>>>
>>>
>>>
>>>
> ____________________________________________________________________________________
>
>>> We won't tell. Get more on shows you hate to love
>>> (and love to hate): Yahoo! TV's Guilty Pleasures
>>>
>> list.
>>
>>> http://tv.yahoo.com/collections/265
>>>
>>>
>>>
> -------------------------------------------------------------------------
>
>>> Using Tomcat but need to do more? Need to support
>>>
>> web services, security?
>>
>>> Get stuff done quickly with pre-integrated
>>>
>> technology to make your job easier.
>>
>>> Download IBM WebSphere Application Server v.1.0.1
>>>
>> based on Apache Geronimo
>>
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>>> _______________________________________________
>>> morph-developer mailing list
>>> mor...@li...
>>>
>>>
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>>>
>>>
>>
>>
> -------------------------------------------------------------------------
>
>> Using Tomcat but need to do more? Need to support
>> web services, security?
>> Get stuff done quickly with pre-integrated
>> technology to make your job easier.
>> Download IBM WebSphere Application Server v.1.0.1
>> based on Apache Geronimo
>>
>>
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>> _______________________________________________
>> morph-developer mailing list
>> mor...@li...
>>
>>
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>
>
>
>
>
> ____________________________________________________________________________________
> Yahoo! Music Unlimited
> Access over 1 million songs.
> http://music.yahoo.com/unlimited
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>
|
|
From: Matt B. <gud...@ya...> - 2007-02-05 21:14:29
|
Okay... my design might be somewhat crippled by the
attempt to be as non-disruptive as possible:
/** A converter derived from another converter */
interface DerivedConverter extends Converter {
Converter getParentConverter();
}
Basically I think BaseTransformer would provide the
DerivedConverter implementation something like this:
public class BaseTransformer ... {
private static final Converter DEFAULT_PARENT = new
NewInstanceConverter();
private Converter parentConverter;
public Converter getParentConverter() {
return parentConverter == null ? DEFAULT_PARENT :
parentConverter;
}
public void setParentConverter() { //routine }
protected Object convertImpl(Class destinationClass,
Object source,
Locale locale) throws Exception {
if (!(this instanceof DerivedConverter)) {
throw new UnsupportedOperation();
}
Object reuseableSource =
createReusableSource(destinationClass, source);
Object destObject =
getParentConverter().convert(destinationClass,
reuseableSource);
copyImpl(destObject, reuseableSource, locale,
Converter.TRANSFORMATION_TYPE_CONVERT);
return destObject;
}
}
Again, we are talking ultimately about an entity that
transforms a source object to an instance of a
specified destination class. If we do away with the
InstantiatingReflector concept, AT LEAST where
converters are concerned, Morph becomes more
versatile, because any converter can be used as the
parent converter in a derivedConverter implementation.
A concrete example:
Morph contains a (-n unfinished)
MultipleDestinationConverter. This can also be viewed
as a DisassemblerCopier (complemented by my recently
added AssemblerCopier). In terms of implementing
copying, this is pretty simple. You have a list of
copier children which should be the same size as the
destination object container. The component copiers
are invoked one at a time from the source object to
the corresponding child in the destination container.
The existing partial MultipleDestinationConverter
implementation uses a list of classes to tell it how
to create the destination object when implementing
Converter. But this is still a case of "we know how
to copy and we just need to know how to create the
destination object". InstantiatingReflector doesn't
fully represent the concept of creating a (probably
heterogenous) collection of destination objects IMHO.
But a parent Converter is semantically open-ended and,
I believe, describes both situations fairly: the
simple (.newInstance()) as well as the complex.
Does that make anything any clearer?
-MJB
--- Matt Sgarlata
<Mat...@wh...> wrote:
> I agree, the addition of the "Object parameters"
> parameter to
> InstantiatingReflector.newInstance is worrisome.
> The idea behind a
> Reflector in general is that it tells you how to
> work with some new type
> of object that has properties which are not known
> until runtime. For
> example, Maps, DynaBeans, ResultSets, etc. If you
> have some sort of
> domain object there should be no need to write a
> reflector, because
> Morph's built-in ObjectReflector can use Java's
> built-in reflection
> capabilities to determine the properties of the
> object. If you just
> want to be able to convert stuff, it should be
> sufficient to write a
> single Transformer that implements both Converter
> and Copier interfaces
> and doesn't mess with InstantiatingReflectors at
> all.
>
> That said, I think the
> InstantiatingReflector.newInstance method is
> something that should be present in the API and not
> deprecated. We can
> and should specify in the comments what this method
> should and should
> not be used for. However, it is possible that some
> types of dynamic
> objects would require extra information before they
> are created. For
> example, the BasicDynaBean has no default
> constructor and requires a
> DynaClass to be constructed. Its properties are not
> known until
> runtime, but the DynaClass provides a contract
> describing the object's
> properties, etc.
>
> So in summary, I'm saying I think we have a
> documentation issue not an
> API issue. However, I don't fully understand what
> API changes you are
> proposing, so could you post some pseudo code for us
> to look at?
>
> Thanks,
>
> Matt S
>
> Matt Benson wrote:
> > I am reawakening this thread. I touched on this
> > subject during the original discussion, but at the
> > time I couldn't quite articulate what was
> bothering me
> > about the whole business. Last Friday it burst
> upon
> > me, and I have continued to kick it around over
> the
> > weekend but have not been able to refute my own
> logic:
> >
> > Basically with InstantiatingReflector taking a
> source
> > parameter, it IS a converter. What is the
> difference
> > between:
> >
> > InstantiatingReflector.newInstance(Class, Object)
> > -and-
> > DecoratedConverter.convert(Class, Object)
> > ?
> >
> > >From my POV, nothing. Different semantics for
> what,
> > using the method parameters as an indicator, is
> one
> > concept. The role of the InstantiatingReflector
> in
> > the Morph library is to adapt a copier to the
> > converter interface, using the following
> algorithm:
> >
> > 1. Create a new instance I
> > 2. Invoke copy() using I as the destination
> object.
> >
> > This sequence of operations amounts to a "derived
> > conversion": one which relies on a parent
> conversion
> > to supply the target object, then modifies the
> > resulting object. This modification will always
> > consist of making changes on a target object based
> on
> > the source object (otherwise the parent converter
> > alone would suffice), and thus infallibly
> corresponds
> > in intent with Copier.copy(). This proves that a
> > DerivedConverter is precisely a Copier that
> implements
> > Converter by first delegating to a parent
> Converter,
> > then copies the source to the resulting
> destination
> > object. The parent converter can be overridden,
> but
> > would default to an, e.g., NewInstanceConverter
> which
> > simply creates a new instance of the
> destinationClass.
> >
> > In adopting the DerivedConverter concept,
> > InstantiatingReflector would, in my opinion, no
> longer
> > be needed, and would hopefully be deprecated and
> then
> > removed as soon as the current players on the
> mailing
> > list(s) are all up to speed. Because the
> interfaces
> > are so similar, I would expect the refactoring of
> a
> > custom InstantiatingReflector implementation to a
> > custom Converter implementation to be trivial.
> >
> > I invite discussion, but I really think I have
> > something here.
> >
> > Impatiently awaiting comment,
> > Matt B
> >
> >
> >
> >
>
____________________________________________________________________________________
> > We won't tell. Get more on shows you hate to love
> > (and love to hate): Yahoo! TV's Guilty Pleasures
> list.
> > http://tv.yahoo.com/collections/265
> >
> >
>
-------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support
> web services, security?
> > Get stuff done quickly with pre-integrated
> technology to make your job easier.
> > Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > morph-developer mailing list
> > mor...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> >
> >
>
>
>
-------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support
> web services, security?
> Get stuff done quickly with pre-integrated
> technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
>
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited
|
|
From: Matt S. <Mat...@wh...> - 2007-02-05 19:08:22
|
I agree, the addition of the "Object parameters" parameter to InstantiatingReflector.newInstance is worrisome. The idea behind a Reflector in general is that it tells you how to work with some new type of object that has properties which are not known until runtime. For example, Maps, DynaBeans, ResultSets, etc. If you have some sort of domain object there should be no need to write a reflector, because Morph's built-in ObjectReflector can use Java's built-in reflection capabilities to determine the properties of the object. If you just want to be able to convert stuff, it should be sufficient to write a single Transformer that implements both Converter and Copier interfaces and doesn't mess with InstantiatingReflectors at all. That said, I think the InstantiatingReflector.newInstance method is something that should be present in the API and not deprecated. We can and should specify in the comments what this method should and should not be used for. However, it is possible that some types of dynamic objects would require extra information before they are created. For example, the BasicDynaBean has no default constructor and requires a DynaClass to be constructed. Its properties are not known until runtime, but the DynaClass provides a contract describing the object's properties, etc. So in summary, I'm saying I think we have a documentation issue not an API issue. However, I don't fully understand what API changes you are proposing, so could you post some pseudo code for us to look at? Thanks, Matt S Matt Benson wrote: > I am reawakening this thread. I touched on this > subject during the original discussion, but at the > time I couldn't quite articulate what was bothering me > about the whole business. Last Friday it burst upon > me, and I have continued to kick it around over the > weekend but have not been able to refute my own logic: > > Basically with InstantiatingReflector taking a source > parameter, it IS a converter. What is the difference > between: > > InstantiatingReflector.newInstance(Class, Object) > -and- > DecoratedConverter.convert(Class, Object) > ? > > >From my POV, nothing. Different semantics for what, > using the method parameters as an indicator, is one > concept. The role of the InstantiatingReflector in > the Morph library is to adapt a copier to the > converter interface, using the following algorithm: > > 1. Create a new instance I > 2. Invoke copy() using I as the destination object. > > This sequence of operations amounts to a "derived > conversion": one which relies on a parent conversion > to supply the target object, then modifies the > resulting object. This modification will always > consist of making changes on a target object based on > the source object (otherwise the parent converter > alone would suffice), and thus infallibly corresponds > in intent with Copier.copy(). This proves that a > DerivedConverter is precisely a Copier that implements > Converter by first delegating to a parent Converter, > then copies the source to the resulting destination > object. The parent converter can be overridden, but > would default to an, e.g., NewInstanceConverter which > simply creates a new instance of the destinationClass. > > In adopting the DerivedConverter concept, > InstantiatingReflector would, in my opinion, no longer > be needed, and would hopefully be deprecated and then > removed as soon as the current players on the mailing > list(s) are all up to speed. Because the interfaces > are so similar, I would expect the refactoring of a > custom InstantiatingReflector implementation to a > custom Converter implementation to be trivial. > > I invite discussion, but I really think I have > something here. > > Impatiently awaiting comment, > Matt B > > > > ____________________________________________________________________________________ > We won't tell. Get more on shows you hate to love > (and love to hate): Yahoo! TV's Guilty Pleasures list. > http://tv.yahoo.com/collections/265 > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > morph-developer mailing list > mor...@li... > https://lists.sourceforge.net/lists/listinfo/morph-developer > > |
|
From: Matt B. <gud...@ya...> - 2007-02-05 18:11:59
|
I am reawakening this thread. I touched on this subject during the original discussion, but at the time I couldn't quite articulate what was bothering me about the whole business. Last Friday it burst upon me, and I have continued to kick it around over the weekend but have not been able to refute my own logic: Basically with InstantiatingReflector taking a source parameter, it IS a converter. What is the difference between: InstantiatingReflector.newInstance(Class, Object) -and- DecoratedConverter.convert(Class, Object) ? >From my POV, nothing. Different semantics for what, using the method parameters as an indicator, is one concept. The role of the InstantiatingReflector in the Morph library is to adapt a copier to the converter interface, using the following algorithm: 1. Create a new instance I 2. Invoke copy() using I as the destination object. This sequence of operations amounts to a "derived conversion": one which relies on a parent conversion to supply the target object, then modifies the resulting object. This modification will always consist of making changes on a target object based on the source object (otherwise the parent converter alone would suffice), and thus infallibly corresponds in intent with Copier.copy(). This proves that a DerivedConverter is precisely a Copier that implements Converter by first delegating to a parent Converter, then copies the source to the resulting destination object. The parent converter can be overridden, but would default to an, e.g., NewInstanceConverter which simply creates a new instance of the destinationClass. In adopting the DerivedConverter concept, InstantiatingReflector would, in my opinion, no longer be needed, and would hopefully be deprecated and then removed as soon as the current players on the mailing list(s) are all up to speed. Because the interfaces are so similar, I would expect the refactoring of a custom InstantiatingReflector implementation to a custom Converter implementation to be trivial. I invite discussion, but I really think I have something here. Impatiently awaiting comment, Matt B ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 |
|
From: Matt B. <gud...@ya...> - 2007-01-31 20:54:55
|
IMHO this is sort of big: it yields a speed improvement in the test cases, and I feel it serves a practical purpose as well. Anyway, I wanted to call attention to it so that it could be shot down if need be. I have modified BaseReflector NOT to set properties to identical or immutable-and-equals() values. This is especially important with copiers, because when you do deep copying, you often don't really need to set the value because you've only changed the state, if you will, of the same actual object instance. Where this really helps, however, is in the situation where you are copying to objects with getters but no setters. Because the actual value object is the same, Morph will now recognize that there is no need to perform the set() and thus its functionality should be extended as a result of these changes (it won't fail trying to perform sets it didn't have to do to begin with). These are revs 101 + 102. -Matt ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ |
|
From: Matt S. <Mat...@wh...> - 2007-01-23 15:45:15
|
I've been thinking, and the original intent of the code in BaseTransformer that wraps exceptions as TransformationExceptions was put in place for 2 reasons: 1) to ensure simple transformers bundled with Morph threw TransformationExceptions rather than the various exceptions thrown by Java, and 2) so that subclasses could throw checked exceptions if needed and have those changed to runtime exceptions Wrapping all exceptions for all subclasses of BaseTransformer was kind of a side effect I hadn't thought through. So this is a very long-winded way of saying that yes, I think we should make the change that runtime exceptions are not wrapped in TransformationExceptions. In terms of implementation, I think the easiest way to do this would be to introduce a new boolean flag that indicates whether or not the BaseTransformer should wrap TransformationExceptions as RuntimeExceptions. The default value would be false, meaning do not wrap RuntimeExceptions as TransformationExceptions. I think this issue impacts more than just Transformers. For the sake of consistency, we would want to change this behavior in Reflectors (I think your patch may have covered these), Languages, Contexts and perhaps Wrappers as well (I'm a little rusty myself on what the current behavior of Wrappers is). I'm very busy at work for the beginning of this week, but hopefully will have some time to look into this toward the end of this week. Matt Ben Alex wrote: > Hi Matt > > Has there been any progress/decision on this issue? > > Cheers > Ben > > ------------------------------------------------------------------------- > 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 > > |
|
From: Ben A. <ben...@ac...> - 2007-01-23 05:08:21
|
Hi Matt Has there been any progress/decision on this issue? Cheers Ben |
2 messages has been excluded from this view by a project administrator.
