morph-developer — For developers of the Morph framework. NOT for questions.

Re: [morph-developer] ASF incubation proposal

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

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

> My email program has inserted line breaks into your
> text, so I will give 
> comments rather than edit...

Okay... I'll respond in kind.

> 
> Matt Benson wrote:
> > BACKGROUND/RATIONALE
> >
> >   As information flows through an application, it
> > undergoes multiple transformations.  While the
> most
> > prevalent examples of this in the J2EE space are
> > well-known (e.g. HTTP request parameters to
> > domain/data transfer objects, DTOs to domain
> objects)
> > the overall problem space is characterized by the
> lack
> > of a simple, well-known, conveniently extensible
> > solution.  At least one JSR (295) describes such a
> > facility as a dependency.  Having identified the
> basic
> > commonalities among the best known application
> > operations requiring object conversion, Morph
> consolid
> > ates these into a single API which, along with
> various
> > bundled implementation classes, seeks to achieve
> the
> > oft-repeated software development goal of making
> "the
> > simple things easy, and the hard things possible"
> with
> > regard to its problem domain.
> >   
> Nice, we need to update the homepage with this (if
> you haven't already 
> done so).

Actually I don't think we ever went through adding me
on the sf project.  ;)  I started with the description
you currently had of Morph and edited.

> > CURRENT STATUS
> >
> > Meritocracy:
> >   The Morph team is eager to invest more deeply in
> the
> > meritocracy approach taken by the ASF.  To date,
> > however, Morph's development team has been
> accumulated
> > by a sort of "meritocracy-on-spec" approach:  Matt
> > Benson was added as a develope
> > r on the basis of his ideas until his actual work
> > proved him an asset to the team.
> >   
> You're missing a word in that last sentence.  Did
> you mean "Matt B was 
> *not* added" or "... *before* his actual work". 
> Sorry, I am fuzzy on my 
> history so I wasn't sure what you were trying to say
> ;)

Actually I meant what I said here.  You moved SVN,
gave me access based on our conversations and my
saying I wanted to hack on Morph, and then I did it,
and you smiled at most of it except for my irrational
preoccupation with the ternary operator.  ;)  That is
like "...*before" his actual work..." but my point was
that I wasn't asked to leave after having started
committing.  :)  I'll experiment with the wording
here.

> > Community:
> >   It is somewhat difficult to gauge the size of
> > Morph's community.  There have been modest but
> > consistent downloads of the project since its
> initial
> > prerelease:  these average 21/month over 28
> months. 
> > The traffic on its user and developer lists is
> > similarly light.  The team acknowledges that this
> > might indicate anything from high code quality to
> > suboptimal promotion.  One possible outcome of
> Morp
> > h's joining the Apache community is that increased
> > cooperation with and buy-in from other ASF
> projects
> > will generate users and possibly developers as
> well.
> >   
> There have been a half dozen users that have
> reported problems, 
> submitted patches, added bug reports, etc. over the
> past couple years.  
> I don't know if you want to mention them or not.

Probably.  I do mention later that user input is
welcomed and acted upon.

> > KNOWN RISKS
> >
> > Orphaned Products:
> >   The Morph developers are part of its user base. 
> The
> > general-purpose, crosscutting nature of this
> project
> > makes it a virtual certainty that a Java developer
> who
> > is familiar with Morph will find uses for the
> library
> > regardless of the particular industry, application
> > tier, or technology implementation he may find
> himself
> > working in/on/with.  For these reasons, the team
> > asserts that the risk of abandonment is low.
> >   
> This would technically be more proper as "... or
> technology 
> implementation *with/in/on which* he may find
> himself working.", if a 
> bit stuffy.

I was thinking of working IN an industry, ON an
application tier, and WITH a technology implementation
by which I was alluding to the use of frameworks and
implying that Morph should be non-intrusive enough to
be relevant in e.g. Spring MVC, Struts, etc.
applications.

> > Inexperience with Open Source:
> >   As has been indicated, one of the initial
> committers
> > has some years of experience as a committer and
> PMC
> > member at the ASF.  Additionally, Morph has always
> > been open-source software, with its evolution
> being
> > directly guided by user input and developer
> consensus
> > in similar fashion to other Apache projects.
> >   
> In fact, the initial list of requirements for the
> project was hashed out 
> on the jakarta-commons-dev email list.

I guess this is as good a section as any to elaborate
on Morph's origins somewhat.

> > Homogenous Developers:
> >   On the plus side, the initial committers are
> united
> > only by their common interest in Morph (and their
> > coincidental first names and middle initials). 
> > However, both hail from the United States, and
> > acknowledge this as a less-than-desirable level of
> > diversity.  As Java Locale support is a key
> strength
> > of Morph's transformation API, wider geographical
> > displacement would be a boon.  The inevitable
> input of
> > the ASF's diverse community could only be of
> positive
> > influence in this regard.
> >   
> "dispersement" might be a better word than
> "displacement".

Noted.

> > Reliance on Salaried Developers:
> >   While both of the core developers use Morph in
> their
> > own paid development jobs, they intend for time to
> > prove their committment to Morph's continued
> success
> > as a library in its own right, and believe it has
> the
> > potential to become THE solution for Java object
> > conversion.
> >   
> I'm confused by the phrase "they intend for time to
> prove their 
> commitment to Morph's continued success... "

I was meaning something like "The core developers use
Morph in their own paid development jobs, but are not
paid to develop Morph per se; so withdrawal of support
is therefore not an issue from this perspective. 
Additionally, Morph's problem domain is such that its
relevance far outstrips the context of a single
project or company, further minimizing the risk of
'itch cessation.'"

> > EXTERNAL DEPENDENCIES
> >
> >   Mandatory runtime dependencies are:
> >
> >   - Apache Jakarta commons-logging
> >   - Composite @ http://composite.sourceforge.net
> > (ASL2)
> >   
> Could we perhaps bundle Composite as a subproject of
> Morph?  I know this 
> might be tricky and/or a sticking point, but
> Composite really does form 
> a good bit of the low-level guts of Morph.

I think we could get away with this after a fashion. 
Composite was originally part of Morph's codebase, and
having no testcases aside from Morph's own, etc., I
would say it has never _fully_ evolved as a separate
project.  If we did this, I would suggest we add the
composite code as PART of the Morph project; it should
be painless to keep it in a different subtree, but it
would be built as part of the same jar and everything.
 This should keep us more in compliance with the terms
of incubation.  Bring it in as part of Morph, then
later we could explore further evolving the code with
its own testcases, etc. to see if it would survive as
an independent entity (and a dependency of Morph
again).  Niall:  Tell me if you think this is pushing
it, and I'll see if I can come up with a satisfactory
explanation for you.  :)

> > REQUIRED RESOURCES
> >
> > Mailing Lists:
> >   (Return to this subject after a sponsor is
> found)
> >
> > Subversion Directory:
> >   (Return to this subject after a sponsor is
> found)
> >
> > Issue Tracking:
> >   (Return to this subject after a sponsor is
> found)
> >   
> We already have this stuff available don't we?

These are the resources that would be used during
incubation--or are you suggesting using the sf lists,
trackers (ugh), etc. while incubating @ ASF?  I don't
know that its ever been done... especially the svn
part.  My inclination would be to go whole-hog ASF
resources as most incubating projects do.  Especially
as if Jakarta agrees to sponsor with the target home
being commons, I'm thinking development discussions
would then take place on commons-dev, which would keep
Morph on the radar of those there who might be
peripherally interested--then find themselves drawn
in!  >:)

> >
> > INITIAL COMMITTERS
> >
> >   - Matt Sgarlata (matthew DOT sgarlata DOT wh02
> AT
> > wharton DOT upenn DOT edu)

By the way, is that your preferred email address?

> >   - Matt Benson (mbenson AT apache DOT org)
> >
> >
> > AFFILIATIONS
> >
> >   Matt Sgarlata is employed by Spider Strategies,
> who
> > have graciously agreed to host Morph's Subversion
> > repository; this is the extent of the claim Spider
> > Strategies makes on the Morph project (i.e. none);
> > Morph has no corporate affiliation.
> >   
> If you like we can add something like "Spider
> Strategies has indicated 
> it's willingness to sign any required documentation
> indicating it holds 
> no claims whatsoever over Morph, its source code, or
> any related 
> electronic information."  I have been told this by
> my boss, who is one 
> of the partners at Spider Strategies and he has sole
> discretion over all 
> software development matters.

Cool, will do.

br,
Matt

> >
> > SPONSORS
> >
> > Champion:  Niall Pemberton
> >
> > Nominated Mentors:  TBD
> >
> > Sponsoring Entity:  TBD
> >
> >
> > March 13, 2007
> >   
> 
>
-------------------------------------------------------------------------
> 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
> 



 
____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

Re: [morph-developer] ASF incubation proposal

[Matt S. <Mat...@wh...>]

My email program has inserted line breaks into your text, so I will give 
comments rather than edit...

Matt Benson wrote:
> BACKGROUND/RATIONALE
>
>   As information flows through an application, it
> undergoes multiple transformations.  While the most
> prevalent examples of this in the J2EE space are
> well-known (e.g. HTTP request parameters to
> domain/data transfer objects, DTOs to domain objects)
> the overall problem space is characterized by the lack
> of a simple, well-known, conveniently extensible
> solution.  At least one JSR (295) describes such a
> facility as a dependency.  Having identified the basic
> commonalities among the best known application
> operations requiring object conversion, Morph consolid
> ates these into a single API which, along with various
> bundled implementation classes, seeks to achieve the
> oft-repeated software development goal of making "the
> simple things easy, and the hard things possible" with
> regard to its problem domain.
>   
Nice, we need to update the homepage with this (if you haven't already 
done so).
> CURRENT STATUS
>
> Meritocracy:
>   The Morph team is eager to invest more deeply in the
> meritocracy approach taken by the ASF.  To date,
> however, Morph's development team has been accumulated
> by a sort of "meritocracy-on-spec" approach:  Matt
> Benson was added as a develope
> r on the basis of his ideas until his actual work
> proved him an asset to the team.
>   
You're missing a word in that last sentence.  Did you mean "Matt B was 
*not* added" or "... *before* his actual work".  Sorry, I am fuzzy on my 
history so I wasn't sure what you were trying to say ;)
> Community:
>   It is somewhat difficult to gauge the size of
> Morph's community.  There have been modest but
> consistent downloads of the project since its initial
> prerelease:  these average 21/month over 28 months. 
> The traffic on its user and developer lists is
> similarly light.  The team acknowledges that this
> might indicate anything from high code quality to
> suboptimal promotion.  One possible outcome of Morp
> h's joining the Apache community is that increased
> cooperation with and buy-in from other ASF projects
> will generate users and possibly developers as well.
>   
There have been a half dozen users that have reported problems, 
submitted patches, added bug reports, etc. over the past couple years.  
I don't know if you want to mention them or not.
> KNOWN RISKS
>
> Orphaned Products:
>   The Morph developers are part of its user base.  The
> general-purpose, crosscutting nature of this project
> makes it a virtual certainty that a Java developer who
> is familiar with Morph will find uses for the library
> regardless of the particular industry, application
> tier, or technology implementation he may find himself
> working in/on/with.  For these reasons, the team
> asserts that the risk of abandonment is low.
>   
This would technically be more proper as "... or technology 
implementation *with/in/on which* he may find himself working.", if a 
bit stuffy.
> Inexperience with Open Source:
>   As has been indicated, one of the initial committers
> has some years of experience as a committer and PMC
> member at the ASF.  Additionally, Morph has always
> been open-source software, with its evolution being
> directly guided by user input and developer consensus
> in similar fashion to other Apache projects.
>   
In fact, the initial list of requirements for the project was hashed out 
on the jakarta-commons-dev email list.
> Homogenous Developers:
>   On the plus side, the initial committers are united
> only by their common interest in Morph (and their
> coincidental first names and middle initials). 
> However, both hail from the United States, and
> acknowledge this as a less-than-desirable level of
> diversity.  As Java Locale support is a key strength
> of Morph's transformation API, wider geographical
> displacement would be a boon.  The inevitable input of
> the ASF's diverse community could only be of positive
> influence in this regard.
>   
"dispersement" might be a better word than "displacement".
> Reliance on Salaried Developers:
>   While both of the core developers use Morph in their
> own paid development jobs, they intend for time to
> prove their committment to Morph's continued success
> as a library in its own right, and believe it has the
> potential to become THE solution for Java object
> conversion.
>   
I'm confused by the phrase "they intend for time to prove their 
commitment to Morph's continued success... "
> EXTERNAL DEPENDENCIES
>
>   Mandatory runtime dependencies are:
>
>   - Apache Jakarta commons-logging
>   - Composite @ http://composite.sourceforge.net
> (ASL2)
>   
Could we perhaps bundle Composite as a subproject of Morph?  I know this 
might be tricky and/or a sticking point, but Composite really does form 
a good bit of the low-level guts of Morph.
> REQUIRED RESOURCES
>
> Mailing Lists:
>   (Return to this subject after a sponsor is found)
>
> Subversion Directory:
>   (Return to this subject after a sponsor is found)
>
> Issue Tracking:
>   (Return to this subject after a sponsor is found)
>   
We already have this stuff available don't we?
>
> INITIAL COMMITTERS
>
>   - Matt Sgarlata (matthew DOT sgarlata DOT wh02 AT
> wharton DOT upenn DOT edu)
>   - Matt Benson (mbenson AT apache DOT org)
>
>
> AFFILIATIONS
>
>   Matt Sgarlata is employed by Spider Strategies, who
> have graciously agreed to host Morph's Subversion
> repository; this is the extent of the claim Spider
> Strategies makes on the Morph project (i.e. none);
> Morph has no corporate affiliation.
>   
If you like we can add something like "Spider Strategies has indicated 
it's willingness to sign any required documentation indicating it holds 
no claims whatsoever over Morph, its source code, or any related 
electronic information."  I have been told this by my boss, who is one 
of the partners at Spider Strategies and he has sole discretion over all 
software development matters.
>
> SPONSORS
>
> Champion:  Niall Pemberton
>
> Nominated Mentors:  TBD
>
> Sponsoring Entity:  TBD
>
>
> March 13, 2007
>   

[morph-developer] ASF incubation proposal

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

We have discussed this at a high level.  For the
benefit of the list, I have been scouting out support
for incubating Morph as a project at the Apache
Software Foundation.  A closer relationship with
especially the Jakarta commons components would be
beneficial to Morph and ultimately to those components
as well (IMHO).  What follows is the proposal I would
like to send to the general@jakarta list in hopes that
the Jakarta PMC will agree to sponsor Morph in the
incubator.  Please respond if you have any comments or
suggestions before I do so.

Thanks,
Matt B

----------------------------------------------------

Morph defines a comprehensive API for performing
object-to-object conversions in Java.

PROPOSAL


BACKGROUND/RATIONALE

  As information flows through an application, it
undergoes multiple transformations.  While the most
prevalent examples of this in the J2EE space are
well-known (e.g. HTTP request parameters to
domain/data transfer objects, DTOs to domain objects)
the overall problem space is characterized by the lack
of a simple, well-known, conveniently extensible
solution.  At least one JSR (295) describes such a
facility as a dependency.  Having identified the basic
commonalities among the best known application
operations requiring object conversion, Morph consolid
ates these into a single API which, along with various
bundled implementation classes, seeks to achieve the
oft-repeated software development goal of making "the
simple things easy, and the hard things possible" with
regard to its problem domain.

CURRENT STATUS

Meritocracy:
  The Morph team is eager to invest more deeply in the
meritocracy approach taken by the ASF.  To date,
however, Morph's development team has been accumulated
by a sort of "meritocracy-on-spec" approach:  Matt
Benson was added as a develope
r on the basis of his ideas until his actual work
proved him an asset to the team.

Community:
  It is somewhat difficult to gauge the size of
Morph's community.  There have been modest but
consistent downloads of the project since its initial
prerelease:  these average 21/month over 28 months. 
The traffic on its user and developer lists is
similarly light.  The team acknowledges that this
might indicate anything from high code quality to
suboptimal promotion.  One possible outcome of Morp
h's joining the Apache community is that increased
cooperation with and buy-in from other ASF projects
will generate users and possibly developers as well.

Core Developers:
  Matt Sgarlata is Morph's founding architect and
developer.  He has been a member of the Jakarta and
Struts user communities for some years.  Matt Benson
is a member of the Apache Ant PMC and a Jakarta
committer, so is familiar with (and fond of) the
consensus and transparency encouraged in ASF
development.

Alignment:
  Morph currently contains interoperability code for
commons-beanutils, commons-chain, and Velocity. 
Because it is Morph's secondary purpose to provide
implementations of common conversions, code that
facilitates Morph's use with well-known libraries in
easily anticipated ways is considered in-scope.  As
has already been implied, it is expected that
citizenship at the ASF would facilitate cooperation
with existing projects to mutal benefit.  Finally,
precedent demonstrating the desirability of such a
project at Apache exists in the form of Jakarta
commons-convert (this component ultimately failed to
achieve maturity).


KNOWN RISKS

Orphaned Products:
  The Morph developers are part of its user base.  The
general-purpose, crosscutting nature of this project
makes it a virtual certainty that a Java developer who
is familiar with Morph will find uses for the library
regardless of the particular industry, application
tier, or technology implementation he may find himself
working in/on/with.  For these reasons, the team
asserts that the risk of abandonment is low.

Inexperience with Open Source:
  As has been indicated, one of the initial committers
has some years of experience as a committer and PMC
member at the ASF.  Additionally, Morph has always
been open-source software, with its evolution being
directly guided by user input and developer consensus
in similar fashion to other Apache projects.

Homogenous Developers:
  On the plus side, the initial committers are united
only by their common interest in Morph (and their
coincidental first names and middle initials). 
However, both hail from the United States, and
acknowledge this as a less-than-desirable level of
diversity.  As Java Locale support is a key strength
of Morph's transformation API, wider geographical
displacement would be a boon.  The inevitable input of
the ASF's diverse community could only be of positive
influence in this regard.

Reliance on Salaried Developers:
  While both of the core developers use Morph in their
own paid development jobs, they intend for time to
prove their committment to Morph's continued success
as a library in its own right, and believe it has the
potential to become THE solution for Java object
conversion.

No Ties to Other Apache Products:
  As described in the Alignment section, this
framework already has ties to many Apache products. 
Additionally, Morph's codebase is already licensed
under the Apache Software License v2.0.

A Fascination with the Apache Brand:
  While "Apache" undeniably marks a project as a force
to be reckoned with, the Morph team is more impressed
by the ASF's organization, procedure, community,
transparency, and camaraderie than anything else. 
Morph's developers share a high opinion of Apache
software in general, and believe that Morph is of
sufficient quality and purity that it simply "belongs"
at the ASF.


DOCUMENTATION

  More information about Morph is available at
http://morph.sourceforge.net .


INITIAL SOURCE

  The initial code base is at
svn://development.spiderstrategies.com/morph .


EXTERNAL DEPENDENCIES

  Mandatory runtime dependencies are:

  - Apache Jakarta commons-logging
  - Composite @ http://composite.sourceforge.net
(ASL2)

  Additionally Morph has the following compile-time
dependencies:

  - Apache Jakarta commons-beanutils
  - Apache Jakarta commons-chain
  - Apache Velocity
  - J2EE Servlet API
  - Spring Framework (ASL2)

  Finally, Morph's test bed currently relies on Apache
Jakarta commons-lang, and will soon include code that
depends on the public domain ANTLR 2 parser generator.


REQUIRED RESOURCES

Mailing Lists:
  (Return to this subject after a sponsor is found)

Subversion Directory:
  (Return to this subject after a sponsor is found)

Issue Tracking:
  (Return to this subject after a sponsor is found)


INITIAL COMMITTERS

  - Matt Sgarlata (matthew DOT sgarlata DOT wh02 AT
wharton DOT upenn DOT edu)
  - Matt Benson (mbenson AT apache DOT org)


AFFILIATIONS

  Matt Sgarlata is employed by Spider Strategies, who
have graciously agreed to host Morph's Subversion
repository; this is the extent of the claim Spider
Strategies makes on the Morph project (i.e. none);
Morph has no corporate affiliation.


SPONSORS

Champion:  Niall Pemberton

Nominated Mentors:  TBD

Sponsoring Entity:  TBD


March 13, 2007


 
____________________________________________________________________________________
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 

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

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

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

> Yeah, I know exactly how you feel ;)  The big
> difference is, I used this 
> last week of vacation to wean myself off caffeine
> (it was making me have 
> trouble sleeping), so I am drinking decaf coffee and
> I'm only allowing 
> myself to do so in the mornings, not in the
> afternoon.
> 
> Anyway, there are probably better things for us to
> be worrying about 
> than the ultimate easy to use transformer.  Your
> idea is that we do that 
> with a declarative XML dialect instead of

Not XML!!! ;)  I like writing DSLs for the fun of it
and so "silly-human-XML-is-for-machines" advocates can
rest easy... so far what I've got would still normally
be used as a child of an SDT + default components
anyway, though.  :)

> programmatically anyway.  If 
> someone is trying to do stuff programmatically, then
> making use of a 
> constructor argument is a perfectly reasonable thing
> to do.  So let's 
> just leave appendDefaultComponents as part of the
> constructor as was 
> your original plan.  Sorry for the long walk down
> the path of making it 
> mutable, when that's probably not a feature we even
> need.
> 
> I agree with you the NodeCopier interface is an
> unfortunate interface to 
> have to introduce.  At least I was able to get rid
> of the 
> GraphTransformer interface
> (SimpleDelegatingTransformer being the only 
> transformer that ever implemented it), but yeah, it
> would be nice to get 
> rid of the NodeCopier interface as well.
>

Glad you didn't take that any wrong way.  I should
have known your design skills would detect the
imperfection of this interface.  Maybe in the future
we will see how to do this better.

-Matt B
 
> Matt S
> 
> Matt Benson wrote:
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> > [SNIP]
> >   
> >> Yeah, that doesn't sound good.
> >>
> >> Let me back up a moment and remember why we are
> >> doing this.  The idea is 
> >> we want to make SimpleDelegatingTransformer
> easier
> >> to use.  The problem 
> >> is that doing so kind of breaks one of its
> features
> >> which is that it is 
> >> customizable just by using getters/setters and
> >> Spring.  I think this 
> >> feature is important, because in some cases you
> may
> >> not even want any of 
> >> Morph's built in transformers to run at all.  An
> >> example is if you are 
> >> doing a very complex conversion of an object
> graph
> >> and most of your 
> >> conversions are done with your own custom
> >> Transformers.  I view the 
> >> SimpleDelegatingTransformer as the
> >> ultra-customizable graph copier.
> >>
> >> If we want to make something easier to use, it
> might
> >> make sense for it 
> >> to just not be the SimpleDelegatingTransformer. 
> The
> >> class used to be 
> >> called the DelegatingTransformer but then I
> realized
> >> there shouldn't be 
> >> just one implementation, different
> implementations
> >> will suit different 
> >> needs.
> >>
> >> My original idea of a very easily customizable
> >> transformer was to have a 
> >> RegistryTransformer that would store its
> components
> >> in a sort of MapList 
> >> that would be both a Map and a List (the entries
> in
> >> the Map are arranged 
> >> in the order they were added).  If you wanted to
> >> replace an existing 
> >> transformer you could do it like this 
> >>
> >>     
> >
>
transformer.replaceTransformer("textToNumberConverter",
> >   
> >> new 
> >> MyTextToNumberConverter()).  If you wanted to add
> a
> >> new transformer you 
> >> could
> >>
> >>     
> >
>
transformer.prependTransformer("stringToMoneyConverter",
> >   
> >> new 
> >> StringToMoneyConverter()).  Implementation could
> be
> >> similar to the 
> >> SimpleDelegatingTransformer, perhaps making use
> of
> >> corresponding 
> >> Registry implementations of interfaces in the
> >> Composite package, for 
> >> example RegistryComponentAccessor.
> >>
> >> Now I'd like to hear your thoughts.  Which of
> these
> >> options are you 
> >> interested in pursuing:
> >> 1) Really really try to get that
> >> appendDefaultComponents stuck into 
> >> SimpleDelegatingTransformer, even if our
> >> implementation ends up a bit hacky
> >> 2) Get started on the RegistryTransformer idea
> >> 3) Create some type of new graph copier that
> could
> >> be used instead of 
> >> SimpleDelegatingTransformer in some cases (I
> don't
> >> know what this would 
> >> look like, ideas?)
> >>
> >>     
> >
> > For some reason I can't get my brain functioning
> today
> > no matter how much caffeine I ingest, so this
> probably
> > won't go far... 
> >
> > option 1... appendDefaultComponents in SDT/SDR: 
> quick
> > & easy = in constructor only.  Drawbacks: biggest
> IMO
> > is that createDefaultComponents() is implicitly
> forced
> > to generate valid data when called from a newly
> > instantiated (no properties set) instance.  Not
> > necessarily the end of the world if not the
> greatest
> > thing.
> >
> > option 2... RegistryTransformer, I'm too dumb
> today to
> > have understood in a concrete way how this could
> solve
> > the problem.
> >
> > option 3... [pause while I deal with having
> spilled a
> > giant cup of coffee in my lap... @#$!] ANYWAY... a
> new
> > kind of graph copier... this sounds like how I was
> > trying to figure out how to just make SDT
> implement
> > NodeCopier, but kept running into trouble.  The
> main
> > problem was that when checking a default SDT
> whether
> > it can node-copy something, you'll usually end up
> > falling down to the PropertyNameMatchingCopier
> which
> > assumes it can copy anything.  So things that you
> > would ordinarily want converted would be copied
> > instead.  I guess I could revisit this, but I'll
> throw
> > that out there in case that gives you any ideas. 
> I
> > think it might be possible to improve on the
> > graph-copying, NodeCopier, etc., though I haven't
> the
> > first idea how to do it (so don't take offense). 
> :)
> >
> > -Matt B
> 
> >
-------------------------------------------------------------------------
> 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
> 



 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

[Matt S. <Mat...@wh...>]

Yeah, I know exactly how you feel ;)  The big difference is, I used this 
last week of vacation to wean myself off caffeine (it was making me have 
trouble sleeping), so I am drinking decaf coffee and I'm only allowing 
myself to do so in the mornings, not in the afternoon.

Anyway, there are probably better things for us to be worrying about 
than the ultimate easy to use transformer.  Your idea is that we do that 
with a declarative XML dialect instead of programmatically anyway.  If 
someone is trying to do stuff programmatically, then making use of a 
constructor argument is a perfectly reasonable thing to do.  So let's 
just leave appendDefaultComponents as part of the constructor as was 
your original plan.  Sorry for the long walk down the path of making it 
mutable, when that's probably not a feature we even need.

I agree with you the NodeCopier interface is an unfortunate interface to 
have to introduce.  At least I was able to get rid of the 
GraphTransformer interface (SimpleDelegatingTransformer being the only 
transformer that ever implemented it), but yeah, it would be nice to get 
rid of the NodeCopier interface as well.

Matt S

Matt Benson wrote:
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
> [SNIP]
>   
>> Yeah, that doesn't sound good.
>>
>> Let me back up a moment and remember why we are
>> doing this.  The idea is 
>> we want to make SimpleDelegatingTransformer easier
>> to use.  The problem 
>> is that doing so kind of breaks one of its features
>> which is that it is 
>> customizable just by using getters/setters and
>> Spring.  I think this 
>> feature is important, because in some cases you may
>> not even want any of 
>> Morph's built in transformers to run at all.  An
>> example is if you are 
>> doing a very complex conversion of an object graph
>> and most of your 
>> conversions are done with your own custom
>> Transformers.  I view the 
>> SimpleDelegatingTransformer as the
>> ultra-customizable graph copier.
>>
>> If we want to make something easier to use, it might
>> make sense for it 
>> to just not be the SimpleDelegatingTransformer.  The
>> class used to be 
>> called the DelegatingTransformer but then I realized
>> there shouldn't be 
>> just one implementation, different implementations
>> will suit different 
>> needs.
>>
>> My original idea of a very easily customizable
>> transformer was to have a 
>> RegistryTransformer that would store its components
>> in a sort of MapList 
>> that would be both a Map and a List (the entries in
>> the Map are arranged 
>> in the order they were added).  If you wanted to
>> replace an existing 
>> transformer you could do it like this 
>>
>>     
> transformer.replaceTransformer("textToNumberConverter",
>   
>> new 
>> MyTextToNumberConverter()).  If you wanted to add a
>> new transformer you 
>> could
>>
>>     
> transformer.prependTransformer("stringToMoneyConverter",
>   
>> new 
>> StringToMoneyConverter()).  Implementation could be
>> similar to the 
>> SimpleDelegatingTransformer, perhaps making use of
>> corresponding 
>> Registry implementations of interfaces in the
>> Composite package, for 
>> example RegistryComponentAccessor.
>>
>> Now I'd like to hear your thoughts.  Which of these
>> options are you 
>> interested in pursuing:
>> 1) Really really try to get that
>> appendDefaultComponents stuck into 
>> SimpleDelegatingTransformer, even if our
>> implementation ends up a bit hacky
>> 2) Get started on the RegistryTransformer idea
>> 3) Create some type of new graph copier that could
>> be used instead of 
>> SimpleDelegatingTransformer in some cases (I don't
>> know what this would 
>> look like, ideas?)
>>
>>     
>
> For some reason I can't get my brain functioning today
> no matter how much caffeine I ingest, so this probably
> won't go far... 
>
> option 1... appendDefaultComponents in SDT/SDR:  quick
> & easy = in constructor only.  Drawbacks: biggest IMO
> is that createDefaultComponents() is implicitly forced
> to generate valid data when called from a newly
> instantiated (no properties set) instance.  Not
> necessarily the end of the world if not the greatest
> thing.
>
> option 2... RegistryTransformer, I'm too dumb today to
> have understood in a concrete way how this could solve
> the problem.
>
> option 3... [pause while I deal with having spilled a
> giant cup of coffee in my lap... @#$!] ANYWAY... a new
> kind of graph copier... this sounds like how I was
> trying to figure out how to just make SDT implement
> NodeCopier, but kept running into trouble.  The main
> problem was that when checking a default SDT whether
> it can node-copy something, you'll usually end up
> falling down to the PropertyNameMatchingCopier which
> assumes it can copy anything.  So things that you
> would ordinarily want converted would be copied
> instead.  I guess I could revisit this, but I'll throw
> that out there in case that gives you any ideas.  I
> think it might be possible to improve on the
> graph-copying, NodeCopier, etc., though I haven't the
> first idea how to do it (so don't take offense).  :)
>
> -Matt B

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

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

--- Matt Sgarlata
<Mat...@wh...> wrote:
[SNIP]
> Yeah, that doesn't sound good.
> 
> Let me back up a moment and remember why we are
> doing this.  The idea is 
> we want to make SimpleDelegatingTransformer easier
> to use.  The problem 
> is that doing so kind of breaks one of its features
> which is that it is 
> customizable just by using getters/setters and
> Spring.  I think this 
> feature is important, because in some cases you may
> not even want any of 
> Morph's built in transformers to run at all.  An
> example is if you are 
> doing a very complex conversion of an object graph
> and most of your 
> conversions are done with your own custom
> Transformers.  I view the 
> SimpleDelegatingTransformer as the
> ultra-customizable graph copier.
> 
> If we want to make something easier to use, it might
> make sense for it 
> to just not be the SimpleDelegatingTransformer.  The
> class used to be 
> called the DelegatingTransformer but then I realized
> there shouldn't be 
> just one implementation, different implementations
> will suit different 
> needs.
> 
> My original idea of a very easily customizable
> transformer was to have a 
> RegistryTransformer that would store its components
> in a sort of MapList 
> that would be both a Map and a List (the entries in
> the Map are arranged 
> in the order they were added).  If you wanted to
> replace an existing 
> transformer you could do it like this 
>
transformer.replaceTransformer("textToNumberConverter",
> new 
> MyTextToNumberConverter()).  If you wanted to add a
> new transformer you 
> could
>
transformer.prependTransformer("stringToMoneyConverter",
> new 
> StringToMoneyConverter()).  Implementation could be
> similar to the 
> SimpleDelegatingTransformer, perhaps making use of
> corresponding 
> Registry implementations of interfaces in the
> Composite package, for 
> example RegistryComponentAccessor.
> 
> Now I'd like to hear your thoughts.  Which of these
> options are you 
> interested in pursuing:
> 1) Really really try to get that
> appendDefaultComponents stuck into 
> SimpleDelegatingTransformer, even if our
> implementation ends up a bit hacky
> 2) Get started on the RegistryTransformer idea
> 3) Create some type of new graph copier that could
> be used instead of 
> SimpleDelegatingTransformer in some cases (I don't
> know what this would 
> look like, ideas?)
> 

For some reason I can't get my brain functioning today
no matter how much caffeine I ingest, so this probably
won't go far... 

option 1... appendDefaultComponents in SDT/SDR:  quick
& easy = in constructor only.  Drawbacks: biggest IMO
is that createDefaultComponents() is implicitly forced
to generate valid data when called from a newly
instantiated (no properties set) instance.  Not
necessarily the end of the world if not the greatest
thing.

option 2... RegistryTransformer, I'm too dumb today to
have understood in a concrete way how this could solve
the problem.

option 3... [pause while I deal with having spilled a
giant cup of coffee in my lap... @#$!] ANYWAY... a new
kind of graph copier... this sounds like how I was
trying to figure out how to just make SDT implement
NodeCopier, but kept running into trouble.  The main
problem was that when checking a default SDT whether
it can node-copy something, you'll usually end up
falling down to the PropertyNameMatchingCopier which
assumes it can copy anything.  So things that you
would ordinarily want converted would be copied
instead.  I guess I could revisit this, but I'll throw
that out there in case that gives you any ideas.  I
think it might be possible to improve on the
graph-copying, NodeCopier, etc., though I haven't the
first idea how to do it (so don't take offense).  :)

-Matt B

> Matt S
> 
>
-------------------------------------------------------------------------
> 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
> 



 
____________________________________________________________________________________
Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> Here is where I still have a problem.  Okay, with your
> clone() impl above, lets assume
> appendDefaultComponents is a property, and that it is
> set to true for this instance.  The clone would still
> have it set to true.  If a user called setComponents()
> on the clone, it would behave appropriately by
> appending the default components.  However, if the
> CloningSpecializer was the caller, it would call
> setComponents with the specialized subset of classes,
> but SDT would then append the default components
> again, which is incorrect.  :(
We could get around this by creating a new ComponentAccessor that works 
with the underlying private property rather than the getters/setters.  
That's a kind of sketchy implementation, but at least it's a sketchy 
implementation detail and not a sketchy interface or sketchy behavior 
presented to users.

Remember, Hibernate is perfectly happy to work with private variables to 
get around problems just like this.  Hibernate is a very successful open 
source project, and I don't think using reflection to access private 
variables has hampered its success.  Here's an example of how Hibernate 
accesses private variables, and why it's necessary.  I have a type of 
object in my application called a Scorecard Node that can be "linked" 
meaning it inherits some values from a different Scorecard Node in the 
system.  One of the values it can inherit is its label, which we present 
to users:

    /**
     * @hibernate.property
     *  column="scorecardnodename"
     *  access="field"
     */
    public String getLabel() {
        if (nodeType == IScorecardNodeConstants.LINKED && 
Boolean.TRUE.equals(useSourceName)) {
            return getSourceNode().getLabel();
        }
        return label;
    }

The trouble is, if I am working with a linked scorecard node like this, 
I don't want the label property to get copied and updated in the 
database each time the label of the source scorecard node changes.  If 
it was updated, this would mean I was storing the data multiple times in 
the database which is a big no-no in relational design.  So I have to 
designate access="field" and tell Hibernate to only look at my private 
field values.  Otherwise, Hibernate would call the getter and think it 
needed to update the linked node's label in the database.

>   But if you declare
> that clones will always have appendDefaultComponents
> set to false, the CloningSpecializer works, but now
> what's the point of having it be a property at all? 
> The cloned instance would have the unexpected (from a
> user perspective) behavior of NOT appending default
> components on subsequent calls to setComponents.  I
> just don't see yet how we can do this without making
> the API confusing or inconsistent in some way.  An
> alternative might be some kind of extra interface in
> the Composite project, but this idea feels kind of
> hacky.  :(
>   
Yeah, that doesn't sound good.

Let me back up a moment and remember why we are doing this.  The idea is 
we want to make SimpleDelegatingTransformer easier to use.  The problem 
is that doing so kind of breaks one of its features which is that it is 
customizable just by using getters/setters and Spring.  I think this 
feature is important, because in some cases you may not even want any of 
Morph's built in transformers to run at all.  An example is if you are 
doing a very complex conversion of an object graph and most of your 
conversions are done with your own custom Transformers.  I view the 
SimpleDelegatingTransformer as the ultra-customizable graph copier.

If we want to make something easier to use, it might make sense for it 
to just not be the SimpleDelegatingTransformer.  The class used to be 
called the DelegatingTransformer but then I realized there shouldn't be 
just one implementation, different implementations will suit different 
needs.

My original idea of a very easily customizable transformer was to have a 
RegistryTransformer that would store its components in a sort of MapList 
that would be both a Map and a List (the entries in the Map are arranged 
in the order they were added).  If you wanted to replace an existing 
transformer you could do it like this 
transformer.replaceTransformer("textToNumberConverter", new 
MyTextToNumberConverter()).  If you wanted to add a new transformer you 
could transformer.prependTransformer("stringToMoneyConverter", new 
StringToMoneyConverter()).  Implementation could be similar to the 
SimpleDelegatingTransformer, perhaps making use of corresponding 
Registry implementations of interfaces in the Composite package, for 
example RegistryComponentAccessor.

Now I'd like to hear your thoughts.  Which of these options are you 
interested in pursuing:
1) Really really try to get that appendDefaultComponents stuck into 
SimpleDelegatingTransformer, even if our implementation ends up a bit hacky
2) Get started on the RegistryTransformer idea
3) Create some type of new graph copier that could be used instead of 
SimpleDelegatingTransformer in some cases (I don't know what this would 
look like, ideas?)

Matt S

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

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

I realize you're not yet back, Matt, but I've been
thinking about this stuff and wanted to publish my
latest thoughts:

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

> Matt Benson wrote:
> > Yeah, I thought about that, but wouldn't that be
> kind
> > of expensive having to add the default converters
> > every time?
> Good point.  To get around this overhead, we could
> cache the full list 
> of components inside the object.  For example, we
> could introduce a new 
> transient variable called something like
> allComponents or something that 
> was cleared out whenever a call to setComponents was
> made.

This could be okay, but read on...

> 
> > Especially given the caveat that we're
> > probably best off always calling
> > createDefaultComponents() and thus instantiating
> new
> > component converters every time (because nothing
> would
> > stop a user from making changes to converters
> obtained
> > from getConverters() if we were to e.g. use
> statically
> > defined components).
> I'm not sure I fully understand what you're saying
> here, but if the 
> concern here is that someone would call
> 
> getComponents()[0] = Something.class
> 
> I think that is probably an edge case.  We can just
> state in the 
> documentation that if you are messing with
> components you should call 
> setComponents.

I could live with that... keep going...

> > Plus we still then have to make
> > the unilateral decision that a cloned SDT instance
> has
> > appendDefaultConverters set to false to make it
> work
> > right with the Composite framework, despite the
> fact
> > that a user-requested clone() operation probably
> wants
> > a true clone, appendDefaultComponents and all...
> you
> > know?
> >   
> I did notice after I sent my original email that
> specialization is done 
> using the CloningSpecializer.  If we want to
> continue using that 
> specializer we'd have to override the clone  method
> like this:
> 
> public Object clone() throws
> CloneNotSupportedException {
>     SimpleDelegatingTransformer clone =
> (SimpleDelegatingTransformer) 
> super.clone();
>     // can't call setComponents because this could
> append the default 
> components again
>     clone.components = getComponents();
>     return clone;
> }

Here is where I still have a problem.  Okay, with your
clone() impl above, lets assume
appendDefaultComponents is a property, and that it is
set to true for this instance.  The clone would still
have it set to true.  If a user called setComponents()
on the clone, it would behave appropriately by
appending the default components.  However, if the
CloningSpecializer was the caller, it would call
setComponents with the specialized subset of classes,
but SDT would then append the default components
again, which is incorrect.  :(  But if you declare
that clones will always have appendDefaultComponents
set to false, the CloningSpecializer works, but now
what's the point of having it be a property at all? 
The cloned instance would have the unexpected (from a
user perspective) behavior of NOT appending default
components on subsequent calls to setComponents.  I
just don't see yet how we can do this without making
the API confusing or inconsistent in some way.  An
alternative might be some kind of extra interface in
the Composite project, but this idea feels kind of
hacky.  :(

-Matt B

> > -MJB
> LOL, my middle initial is J too.

;)

> 
>
-------------------------------------------------------------------------
> 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
> 



 
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

Re: [morph-developer] ROO

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

So basically you're just waiting on a release...?  If
so, just stay tuned over the next few weeks and we'll
see what happens.  :)

-Matt

--- Ben Alex <ben...@ac...> wrote:

> Matt Benson wrote:
> > Ben: Are you still here?  I was reading through
> older
> > emails and for some reason the first time through
> it
> > escaped me that you gave the name of the project
> you
> > were working on, implying that it might be
> available
> > to random eyes.  I got several hits on Google, but
> > nothing that showed me what was what, really.  Is
> ROO
> > available for public perusal, and are you still
> > intending to use Morph in it?
> 
> Hi Matt
> 
> ROO isn't released, but hopefully will be in due
> course.
> 
> We are currently using Dozer 3, as the patches I
> needed to Morph
> regarding creation of objects using non-default
> constructors weren't
> applied and it got too hard keeping a local snapshot
> synced with the
> other enhancements you were making in SVN.
> 
> I would like to have support for either assembler in
> ROO, but we need
> the capability previously discussed to make this
> feasible.
> 
> 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
> 



 
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

Re: [morph-developer] ROO

[Ben A. <ben...@ac...>]

Matt Benson wrote:
> Ben: Are you still here?  I was reading through older
> emails and for some reason the first time through it
> escaped me that you gave the name of the project you
> were working on, implying that it might be available
> to random eyes.  I got several hits on Google, but
> nothing that showed me what was what, really.  Is ROO
> available for public perusal, and are you still
> intending to use Morph in it?

Hi Matt

ROO isn't released, but hopefully will be in due course.

We are currently using Dozer 3, as the patches I needed to Morph
regarding creation of objects using non-default constructors weren't
applied and it got too hard keeping a local snapshot synced with the
other enhancements you were making in SVN.

I would like to have support for either assembler in ROO, but we need
the capability previously discussed to make this feasible.

Cheers
Ben

[morph-developer] Vacation

[Matt S. <Mat...@wh...>]

I will be on vacation next week, Mar 5 - 9.  I will try to address any 
questions/discussions that come up regarding Morph when I return on Mar 12.

Matt

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> Yeah, I thought about that, but wouldn't that be kind
> of expensive having to add the default converters
> every time?
Good point.  To get around this overhead, we could cache the full list 
of components inside the object.  For example, we could introduce a new 
transient variable called something like allComponents or something that 
was cleared out whenever a call to setComponents was made.

> Especially given the caveat that we're
> probably best off always calling
> createDefaultComponents() and thus instantiating new
> component converters every time (because nothing would
> stop a user from making changes to converters obtained
> from getConverters() if we were to e.g. use statically
> defined components).
I'm not sure I fully understand what you're saying here, but if the 
concern here is that someone would call

getComponents()[0] = Something.class

I think that is probably an edge case.  We can just state in the 
documentation that if you are messing with components you should call 
setComponents.
> Plus we still then have to make
> the unilateral decision that a cloned SDT instance has
> appendDefaultConverters set to false to make it work
> right with the Composite framework, despite the fact
> that a user-requested clone() operation probably wants
> a true clone, appendDefaultComponents and all... you
> know?
>   
I did notice after I sent my original email that specialization is done 
using the CloningSpecializer.  If we want to continue using that 
specializer we'd have to override the clone  method like this:

public Object clone() throws CloneNotSupportedException {
    SimpleDelegatingTransformer clone = (SimpleDelegatingTransformer) 
super.clone();
    // can't call setComponents because this could append the default 
components again
    clone.components = getComponents();
    return clone;
}
> -MJB
LOL, my middle initial is J too.

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

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

Yeah, I thought about that, but wouldn't that be kind
of expensive having to add the default converters
every time?  Especially given the caveat that we're
probably best off always calling
createDefaultComponents() and thus instantiating new
component converters every time (because nothing would
stop a user from making changes to converters obtained
from getConverters() if we were to e.g. use statically
defined components).  Plus we still then have to make
the unilateral decision that a cloned SDT instance has
appendDefaultConverters set to false to make it work
right with the Composite framework, despite the fact
that a user-requested clone() operation probably wants
a true clone, appendDefaultComponents and all... you
know?

-MJB

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

> Thinking further about option #1, how about this
> logic
> 
> class SDT {
> boolean appendDefaultComponents=true;
> ...
>   getComponents() {
>   if (appendDefaultComponents) {
>     return concat(components,
> getDefaultComponents());
>   }
>   else {
>      if (isEmpty(components))
>        throw new MorphException("No components
> found");
>      return components;
>   }
> }
> 
> Matt S
> 
> Matt Benson wrote:
> > On option 1 below:  first issue: it seems that it
> > would be difficult to differentiate when to add
> what,
> > especially when no user-supplied components are
> > provided.  second issue: it seems like this would
> > still cause problems with composites, wouldn't it?
>  :(
> >
> > -MJB
> >
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >   
> >> That sounds like a reasonable approach.
> >>
> >> Here is some brainstorming on other approaches:
> >> 1) Modify the getComponents method instead of the
> >> setComponents method 
> >> to code the behavior of appendDefaultComponents
> >> 2) Introduce a new property like
> >> nonDefaultComponents that must be used 
> >> when you want to appendDefaultComponents. 
> >> Configuration is then done 
> >> either with appendDefaultComponents = true and
> >> modifications done to 
> >> nonDefaultComponents or when
> >> appendDefaultComponents=false directly to 
> >> the components property.
> >>
> >> #2 definitely seems like a kludge and not a very
> >> good solution to me.  
> >> Did you try out #1?
> >>
> >> Matt S
> >>
> >> Matt Benson wrote:
> >>     
> >>> I had implemented this for
> >>> SimpleDelegatingTransformer, was working on
> >>> duplicating the effort for
> >>>       
> >> SimpleDelegatingReflector,
> >>     
> >>> and managed to break several test cases.  I was
> >>> setting a flag and--if true--appending default
> >>> components every time components were set via
> >>> setComponents().  Debugging made it obvious that
> >>>       
> >> this
> >>     
> >>> completely circumvents the point of having these
> >>> classes be composites; i.e. they are no longer
> >>> specializable.  So I'd like to discuss what the
> >>> options are for enabling this simplified
> >>>       
> >> configuration
> >>     
> >>> without breaking existing specialization
> >>> (SimpleDelegatingTransformer should in theory
> >>>       
> >> suffer
> >>     
> >>> from the same situation, only none of the core
> >>>       
> >> code
> >>     
> >>> happens to specialize an SDT):
> >>>
> >>> I think in order to do this safely the easiest
> >>>       
> >> thing,
> >>     
> >>> at least to start with, is to simple provide a
> >>> constructor that allows the user to specify the
> >>> component list and accepts
> appendDefaultComponents
> >>>       
> >> as
> >>     
> >>> a boolean parameter on a one-time-only basis.  I
> >>>       
> >> have
> >>     
> >>> made this change to SimpleDelegatingReflector
> and
> >>>       
> >> will
> >>     
> >>> go ahead and modify SimpleDelegatingTransformer
> >>> similarly.  This at least provides for the
> >>>       
> >> behavior at
> >>     
> >>> the cost of forcing the user to use constructor
> >>> injection (assuming Spring config).  Perhaps we
> >>>       
> >> will
> >>     
> >>> then be able to see better how to proceed.
> >>>
> >>> -Matt
> >>>
> >>> --- Matt Sgarlata
> >>> <Mat...@wh...> wrote:
> >>>
> >>>   
> >>>       
> >>>> Matt Benson wrote:
> >>>>     
> >>>>         
> >>>>> Hmph--hadn't noticed the Spring file.  :) 
> This
> >>>>>           
> >> is
> >>     
> >>>>> something I would like to think more about for
> >>>>>           
> >> the
> >>     
> >>>>> long-term.  I've been looking at this stuff
> for
> >>>>> several hours today (and once more revisited
> the
> >>>>> UNfruitful path of having SDT flat-out
> implement
> >>>>> NodeCopier, though I almost got there) and now
> I
> >>>>>       
> >>>>>           
> >>>> think
> >>>>     
> >>>>         
> >>>>> a tiny piece of effort that would have quite a
> >>>>>           
> >> bit
> >>     
> >>>>>       
> >>>>>           
> >>>> of
> >>>>     
> >>>>         
> >>>>> yield would simply be a boolean
> >>>>> appendDefaultComponents flag for SDT.  This
> >>>>>           
> >> would
> >>     
> >>>>> greatly simplify Spring (or otherwise)
> >>>>>       
> >>>>>           
> >>>> configuration
> >>>>     
> >>>>         
> >>>>> of an application's top-level SDT where the
> >>>>>       
> >>>>>           
> >>>> developer
> >>>>     
> >>>>         
> >>>>> provides custom transformer implementations,
> but
> >>>>>       
> >>>>>           
> >>>> wants
> >>>>     
> >>>>         
> >>>>> to defer to Morph's default behavior for
> >>>>>           
> >> standard
> >>     
> >>>>> cases.  Hopefully this would cover >= 90% of
> >>>>>           
> >> what
> >>     
> >>>>> developers would want to do, while still
> leaving
> >>>>>       
> >>>>>           
> >>>> the
> >>>>     
> >>>>         
> >>>>> door open for more complex configurations.
> >>>>>
> >>>>> "Make easy things easy and hard things
> >>>>>           
> >> possible."
> >>     
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> Yes, it is a huge pain in the neck to customize
> >>>>         
> >> the
> >>     
> >>>> SDT because of the 
> >>>> need to exactly duplicate the default
> >>>>         
> >> transformers
> >>     
> >>>> that come with Morph 
> >>>> and make sure the custom transformers come
> before
> >>>> the built-in ones.  I 
> >>>> hadn't really considered adding a boolean flag
> >>>>         
> >> like
> >>     
> >>>> this, and I do agree 
> >>>> it would be a very minor change with a very
> large
> >>>> benefit.  I would also 
> >>>> be in favor of the default value for the flag
> to
> >>>>         
> >> be
> >>     
> >>>> true.  I believe 
> >>>> SimpleDelegatingReflector would also benefit
> from
> >>>>         
> >> a
> >>     
> >>>> similar change.
> >>>>
> >>>> Matt S
> >>>>
> >>>>
> >>>>     
> >>>>         
> >
>
-------------------------------------------------------------------------
> >   
> >>>   
> >>>       
> >>>> 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
> >   
> >>>   
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>>
> >>>       
> >
>
____________________________________________________________________________________
> >   
> >>> Do you Yahoo!?
> >>> Everyone is raving about the all-new Yahoo! Mail
> >>>       
> >> beta.
> >>     
> >>> http://new.mail.yahoo.com
> >>>
> >>>
> >>>       
> >
>
-------------------------------------------------------------------------
> >   
> >>> 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
> >   
> >
> >
> >
> >  
> >
>
____________________________________________________________________________________
> > Cheap talk?
> > Check out Yahoo! Messenger's low PC-to-Phone call
> rates.
> > http://voice.yahoo.com
> >
> >
>
-------------------------------------------------------------------------
> > 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
> 



 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

[Matt S. <Mat...@wh...>]

Thinking further about option #1, how about this logic

class SDT {
boolean appendDefaultComponents=true;
...
  getComponents() {
  if (appendDefaultComponents) {
    return concat(components, getDefaultComponents());
  }
  else {
     if (isEmpty(components))
       throw new MorphException("No components found");
     return components;
  }
}

Matt S

Matt Benson wrote:
> On option 1 below:  first issue: it seems that it
> would be difficult to differentiate when to add what,
> especially when no user-supplied components are
> provided.  second issue: it seems like this would
> still cause problems with composites, wouldn't it?  :(
>
> -MJB
>
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> That sounds like a reasonable approach.
>>
>> Here is some brainstorming on other approaches:
>> 1) Modify the getComponents method instead of the
>> setComponents method 
>> to code the behavior of appendDefaultComponents
>> 2) Introduce a new property like
>> nonDefaultComponents that must be used 
>> when you want to appendDefaultComponents. 
>> Configuration is then done 
>> either with appendDefaultComponents = true and
>> modifications done to 
>> nonDefaultComponents or when
>> appendDefaultComponents=false directly to 
>> the components property.
>>
>> #2 definitely seems like a kludge and not a very
>> good solution to me.  
>> Did you try out #1?
>>
>> Matt S
>>
>> Matt Benson wrote:
>>     
>>> I had implemented this for
>>> SimpleDelegatingTransformer, was working on
>>> duplicating the effort for
>>>       
>> SimpleDelegatingReflector,
>>     
>>> and managed to break several test cases.  I was
>>> setting a flag and--if true--appending default
>>> components every time components were set via
>>> setComponents().  Debugging made it obvious that
>>>       
>> this
>>     
>>> completely circumvents the point of having these
>>> classes be composites; i.e. they are no longer
>>> specializable.  So I'd like to discuss what the
>>> options are for enabling this simplified
>>>       
>> configuration
>>     
>>> without breaking existing specialization
>>> (SimpleDelegatingTransformer should in theory
>>>       
>> suffer
>>     
>>> from the same situation, only none of the core
>>>       
>> code
>>     
>>> happens to specialize an SDT):
>>>
>>> I think in order to do this safely the easiest
>>>       
>> thing,
>>     
>>> at least to start with, is to simple provide a
>>> constructor that allows the user to specify the
>>> component list and accepts appendDefaultComponents
>>>       
>> as
>>     
>>> a boolean parameter on a one-time-only basis.  I
>>>       
>> have
>>     
>>> made this change to SimpleDelegatingReflector and
>>>       
>> will
>>     
>>> go ahead and modify SimpleDelegatingTransformer
>>> similarly.  This at least provides for the
>>>       
>> behavior at
>>     
>>> the cost of forcing the user to use constructor
>>> injection (assuming Spring config).  Perhaps we
>>>       
>> will
>>     
>>> then be able to see better how to proceed.
>>>
>>> -Matt
>>>
>>> --- Matt Sgarlata
>>> <Mat...@wh...> wrote:
>>>
>>>   
>>>       
>>>> Matt Benson wrote:
>>>>     
>>>>         
>>>>> Hmph--hadn't noticed the Spring file.  :)  This
>>>>>           
>> is
>>     
>>>>> something I would like to think more about for
>>>>>           
>> the
>>     
>>>>> long-term.  I've been looking at this stuff for
>>>>> several hours today (and once more revisited the
>>>>> UNfruitful path of having SDT flat-out implement
>>>>> NodeCopier, though I almost got there) and now I
>>>>>       
>>>>>           
>>>> think
>>>>     
>>>>         
>>>>> a tiny piece of effort that would have quite a
>>>>>           
>> bit
>>     
>>>>>       
>>>>>           
>>>> of
>>>>     
>>>>         
>>>>> yield would simply be a boolean
>>>>> appendDefaultComponents flag for SDT.  This
>>>>>           
>> would
>>     
>>>>> greatly simplify Spring (or otherwise)
>>>>>       
>>>>>           
>>>> configuration
>>>>     
>>>>         
>>>>> of an application's top-level SDT where the
>>>>>       
>>>>>           
>>>> developer
>>>>     
>>>>         
>>>>> provides custom transformer implementations, but
>>>>>       
>>>>>           
>>>> wants
>>>>     
>>>>         
>>>>> to defer to Morph's default behavior for
>>>>>           
>> standard
>>     
>>>>> cases.  Hopefully this would cover >= 90% of
>>>>>           
>> what
>>     
>>>>> developers would want to do, while still leaving
>>>>>       
>>>>>           
>>>> the
>>>>     
>>>>         
>>>>> door open for more complex configurations.
>>>>>
>>>>> "Make easy things easy and hard things
>>>>>           
>> possible."
>>     
>>>>>   
>>>>>       
>>>>>           
>>>> Yes, it is a huge pain in the neck to customize
>>>>         
>> the
>>     
>>>> SDT because of the 
>>>> need to exactly duplicate the default
>>>>         
>> transformers
>>     
>>>> that come with Morph 
>>>> and make sure the custom transformers come before
>>>> the built-in ones.  I 
>>>> hadn't really considered adding a boolean flag
>>>>         
>> like
>>     
>>>> this, and I do agree 
>>>> it would be a very minor change with a very large
>>>> benefit.  I would also 
>>>> be in favor of the default value for the flag to
>>>>         
>> be
>>     
>>>> true.  I believe 
>>>> SimpleDelegatingReflector would also benefit from
>>>>         
>> a
>>     
>>>> similar change.
>>>>
>>>> Matt S
>>>>
>>>>
>>>>     
>>>>         
> -------------------------------------------------------------------------
>   
>>>   
>>>       
>>>> 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
>   
>>>   
>>>
>>>
>>>
>>>
>>>  
>>>
>>>       
> ____________________________________________________________________________________
>   
>>> Do you Yahoo!?
>>> Everyone is raving about the all-new Yahoo! Mail
>>>       
>> beta.
>>     
>>> http://new.mail.yahoo.com
>>>
>>>
>>>       
> -------------------------------------------------------------------------
>   
>>> 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
>   
>
>
>
>  
> ____________________________________________________________________________________
> Cheap talk?
> Check out Yahoo! Messenger's low PC-to-Phone call rates.
> http://voice.yahoo.com
>
> -------------------------------------------------------------------------
> 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
>
>   

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

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

On option 1 below:  first issue: it seems that it
would be difficult to differentiate when to add what,
especially when no user-supplied components are
provided.  second issue: it seems like this would
still cause problems with composites, wouldn't it?  :(

-MJB

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

> That sounds like a reasonable approach.
> 
> Here is some brainstorming on other approaches:
> 1) Modify the getComponents method instead of the
> setComponents method 
> to code the behavior of appendDefaultComponents
> 2) Introduce a new property like
> nonDefaultComponents that must be used 
> when you want to appendDefaultComponents. 
> Configuration is then done 
> either with appendDefaultComponents = true and
> modifications done to 
> nonDefaultComponents or when
> appendDefaultComponents=false directly to 
> the components property.
> 
> #2 definitely seems like a kludge and not a very
> good solution to me.  
> Did you try out #1?
> 
> Matt S
> 
> Matt Benson wrote:
> > I had implemented this for
> > SimpleDelegatingTransformer, was working on
> > duplicating the effort for
> SimpleDelegatingReflector,
> > and managed to break several test cases.  I was
> > setting a flag and--if true--appending default
> > components every time components were set via
> > setComponents().  Debugging made it obvious that
> this
> > completely circumvents the point of having these
> > classes be composites; i.e. they are no longer
> > specializable.  So I'd like to discuss what the
> > options are for enabling this simplified
> configuration
> > without breaking existing specialization
> > (SimpleDelegatingTransformer should in theory
> suffer
> > from the same situation, only none of the core
> code
> > happens to specialize an SDT):
> >
> > I think in order to do this safely the easiest
> thing,
> > at least to start with, is to simple provide a
> > constructor that allows the user to specify the
> > component list and accepts appendDefaultComponents
> as
> > a boolean parameter on a one-time-only basis.  I
> have
> > made this change to SimpleDelegatingReflector and
> will
> > go ahead and modify SimpleDelegatingTransformer
> > similarly.  This at least provides for the
> behavior at
> > the cost of forcing the user to use constructor
> > injection (assuming Spring config).  Perhaps we
> will
> > then be able to see better how to proceed.
> >
> > -Matt
> >
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >   
> >> Matt Benson wrote:
> >>     
> >>> Hmph--hadn't noticed the Spring file.  :)  This
> is
> >>> something I would like to think more about for
> the
> >>> long-term.  I've been looking at this stuff for
> >>> several hours today (and once more revisited the
> >>> UNfruitful path of having SDT flat-out implement
> >>> NodeCopier, though I almost got there) and now I
> >>>       
> >> think
> >>     
> >>> a tiny piece of effort that would have quite a
> bit
> >>>       
> >> of
> >>     
> >>> yield would simply be a boolean
> >>> appendDefaultComponents flag for SDT.  This
> would
> >>> greatly simplify Spring (or otherwise)
> >>>       
> >> configuration
> >>     
> >>> of an application's top-level SDT where the
> >>>       
> >> developer
> >>     
> >>> provides custom transformer implementations, but
> >>>       
> >> wants
> >>     
> >>> to defer to Morph's default behavior for
> standard
> >>> cases.  Hopefully this would cover >= 90% of
> what
> >>> developers would want to do, while still leaving
> >>>       
> >> the
> >>     
> >>> door open for more complex configurations.
> >>>
> >>> "Make easy things easy and hard things
> possible."
> >>>   
> >>>       
> >> Yes, it is a huge pain in the neck to customize
> the
> >> SDT because of the 
> >> need to exactly duplicate the default
> transformers
> >> that come with Morph 
> >> and make sure the custom transformers come before
> >> the built-in ones.  I 
> >> hadn't really considered adding a boolean flag
> like
> >> this, and I do agree 
> >> it would be a very minor change with a very large
> >> benefit.  I would also 
> >> be in favor of the default value for the flag to
> be
> >> true.  I believe 
> >> SimpleDelegatingReflector would also benefit from
> a
> >> similar change.
> >>
> >> Matt S
> >>
> >>
> >>     
> >
>
-------------------------------------------------------------------------
> >   
> >> 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
> >   
> >
> >
> >
> >
> >  
> >
>
____________________________________________________________________________________
> > Do you Yahoo!?
> > Everyone is raving about the all-new Yahoo! Mail
> beta.
> > http://new.mail.yahoo.com
> >
> >
>
-------------------------------------------------------------------------
> > 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
> 



 
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

Re: [morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

[Matt S. <Mat...@wh...>]

That sounds like a reasonable approach.

Here is some brainstorming on other approaches:
1) Modify the getComponents method instead of the setComponents method 
to code the behavior of appendDefaultComponents
2) Introduce a new property like nonDefaultComponents that must be used 
when you want to appendDefaultComponents.  Configuration is then done 
either with appendDefaultComponents = true and modifications done to 
nonDefaultComponents or when appendDefaultComponents=false directly to 
the components property.

#2 definitely seems like a kludge and not a very good solution to me.  
Did you try out #1?

Matt S

Matt Benson wrote:
> I had implemented this for
> SimpleDelegatingTransformer, was working on
> duplicating the effort for SimpleDelegatingReflector,
> and managed to break several test cases.  I was
> setting a flag and--if true--appending default
> components every time components were set via
> setComponents().  Debugging made it obvious that this
> completely circumvents the point of having these
> classes be composites; i.e. they are no longer
> specializable.  So I'd like to discuss what the
> options are for enabling this simplified configuration
> without breaking existing specialization
> (SimpleDelegatingTransformer should in theory suffer
> from the same situation, only none of the core code
> happens to specialize an SDT):
>
> I think in order to do this safely the easiest thing,
> at least to start with, is to simple provide a
> constructor that allows the user to specify the
> component list and accepts appendDefaultComponents as
> a boolean parameter on a one-time-only basis.  I have
> made this change to SimpleDelegatingReflector and will
> go ahead and modify SimpleDelegatingTransformer
> similarly.  This at least provides for the behavior at
> the cost of forcing the user to use constructor
> injection (assuming Spring config).  Perhaps we will
> then be able to see better how to proceed.
>
> -Matt
>
> --- Matt Sgarlata
> <Mat...@wh...> wrote:
>
>   
>> Matt Benson wrote:
>>     
>>> Hmph--hadn't noticed the Spring file.  :)  This is
>>> something I would like to think more about for the
>>> long-term.  I've been looking at this stuff for
>>> several hours today (and once more revisited the
>>> UNfruitful path of having SDT flat-out implement
>>> NodeCopier, though I almost got there) and now I
>>>       
>> think
>>     
>>> a tiny piece of effort that would have quite a bit
>>>       
>> of
>>     
>>> yield would simply be a boolean
>>> appendDefaultComponents flag for SDT.  This would
>>> greatly simplify Spring (or otherwise)
>>>       
>> configuration
>>     
>>> of an application's top-level SDT where the
>>>       
>> developer
>>     
>>> provides custom transformer implementations, but
>>>       
>> wants
>>     
>>> to defer to Morph's default behavior for standard
>>> cases.  Hopefully this would cover >= 90% of what
>>> developers would want to do, while still leaving
>>>       
>> the
>>     
>>> door open for more complex configurations.
>>>
>>> "Make easy things easy and hard things possible."
>>>   
>>>       
>> Yes, it is a huge pain in the neck to customize the
>> SDT because of the 
>> need to exactly duplicate the default transformers
>> that come with Morph 
>> and make sure the custom transformers come before
>> the built-in ones.  I 
>> hadn't really considered adding a boolean flag like
>> this, and I do agree 
>> it would be a very minor change with a very large
>> benefit.  I would also 
>> be in favor of the default value for the flag to be
>> true.  I believe 
>> SimpleDelegatingReflector would also benefit from a
>> similar change.
>>
>> Matt S
>>
>>
>>     
> -------------------------------------------------------------------------
>   
>> 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
>   
>
>
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> -------------------------------------------------------------------------
> 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
>
>   

[morph-developer] ROO

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

Ben: Are you still here?  I was reading through older
emails and for some reason the first time through it
escaped me that you gave the name of the project you
were working on, implying that it might be available
to random eyes.  I got several hits on Google, but
nothing that showed me what was what, really.  Is ROO
available for public perusal, and are you still
intending to use Morph in it?

br,
Matt


 
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html 

[morph-developer] appendDefaultComponents WAS Re: Copying Objects to Maps

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

I had implemented this for
SimpleDelegatingTransformer, was working on
duplicating the effort for SimpleDelegatingReflector,
and managed to break several test cases.  I was
setting a flag and--if true--appending default
components every time components were set via
setComponents().  Debugging made it obvious that this
completely circumvents the point of having these
classes be composites; i.e. they are no longer
specializable.  So I'd like to discuss what the
options are for enabling this simplified configuration
without breaking existing specialization
(SimpleDelegatingTransformer should in theory suffer
from the same situation, only none of the core code
happens to specialize an SDT):

I think in order to do this safely the easiest thing,
at least to start with, is to simple provide a
constructor that allows the user to specify the
component list and accepts appendDefaultComponents as
a boolean parameter on a one-time-only basis.  I have
made this change to SimpleDelegatingReflector and will
go ahead and modify SimpleDelegatingTransformer
similarly.  This at least provides for the behavior at
the cost of forcing the user to use constructor
injection (assuming Spring config).  Perhaps we will
then be able to see better how to proceed.

-Matt

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

> Matt Benson wrote:
> > Hmph--hadn't noticed the Spring file.  :)  This is
> > something I would like to think more about for the
> > long-term.  I've been looking at this stuff for
> > several hours today (and once more revisited the
> > UNfruitful path of having SDT flat-out implement
> > NodeCopier, though I almost got there) and now I
> think
> > a tiny piece of effort that would have quite a bit
> of
> > yield would simply be a boolean
> > appendDefaultComponents flag for SDT.  This would
> > greatly simplify Spring (or otherwise)
> configuration
> > of an application's top-level SDT where the
> developer
> > provides custom transformer implementations, but
> wants
> > to defer to Morph's default behavior for standard
> > cases.  Hopefully this would cover >= 90% of what
> > developers would want to do, while still leaving
> the
> > door open for more complex configurations.
> >
> > "Make easy things easy and hard things possible."
> >   
> Yes, it is a huge pain in the neck to customize the
> SDT because of the 
> need to exactly duplicate the default transformers
> that come with Morph 
> and make sure the custom transformers come before
> the built-in ones.  I 
> hadn't really considered adding a boolean flag like
> this, and I do agree 
> it would be a very minor change with a very large
> benefit.  I would also 
> be in favor of the default value for the flag to be
> true.  I believe 
> SimpleDelegatingReflector would also benefit from a
> similar change.
> 
> Matt S
> 
>
-------------------------------------------------------------------------
> 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
> 




 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Re: [morph-developer] Copying Objects to Maps

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> Hmph--hadn't noticed the Spring file.  :)  This is
> something I would like to think more about for the
> long-term.  I've been looking at this stuff for
> several hours today (and once more revisited the
> UNfruitful path of having SDT flat-out implement
> NodeCopier, though I almost got there) and now I think
> a tiny piece of effort that would have quite a bit of
> yield would simply be a boolean
> appendDefaultComponents flag for SDT.  This would
> greatly simplify Spring (or otherwise) configuration
> of an application's top-level SDT where the developer
> provides custom transformer implementations, but wants
> to defer to Morph's default behavior for standard
> cases.  Hopefully this would cover >= 90% of what
> developers would want to do, while still leaving the
> door open for more complex configurations.
>
> "Make easy things easy and hard things possible."
>   
Yes, it is a huge pain in the neck to customize the SDT because of the 
need to exactly duplicate the default transformers that come with Morph 
and make sure the custom transformers come before the built-in ones.  I 
hadn't really considered adding a boolean flag like this, and I do agree 
it would be a very minor change with a very large benefit.  I would also 
be in favor of the default value for the flag to be true.  I believe 
SimpleDelegatingReflector would also benefit from a similar change.

Matt S

Re: [morph-developer] Copying Objects to Maps

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

Hmph--hadn't noticed the Spring file.  :)  This is
something I would like to think more about for the
long-term.  I've been looking at this stuff for
several hours today (and once more revisited the
UNfruitful path of having SDT flat-out implement
NodeCopier, though I almost got there) and now I think
a tiny piece of effort that would have quite a bit of
yield would simply be a boolean
appendDefaultComponents flag for SDT.  This would
greatly simplify Spring (or otherwise) configuration
of an application's top-level SDT where the developer
provides custom transformer implementations, but wants
to defer to Morph's default behavior for standard
cases.  Hopefully this would cover >= 90% of what
developers would want to do, while still leaving the
door open for more complex configurations.

"Make easy things easy and hard things possible."

-Matt (B)

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

> Matt Benson wrote:
> > Follow Up:
> >
> > 1) No news is good news, so I will implement such
> that
> > beans will indeed map properties to map entries by
> > default.
> >   
> OK, I had a chance to look over this.  The reason
> for the old behavior 
> was an implementation coincidence and not really
> intended.  It happened 
> because:
> - MapReflector is perfectly happy treating a Map as
> both a container and 
> as a bean
> - ContainerCopier has to come before
> PropertyNameMatchingCopier, 
> otherwise when collections were encountered you
> would have the 
> properties of the collection copied rather than
> their data
> > 2) I over-analyzed the issue before; my original
> idea
> > of using a PropertyNameMatchingCopier is
> sufficient to
> > copy indexed containers to maps, since a basic
> > reflector will list the string versions of
> available
> > indices as property names.  :)
> >   
> Adding a more specific PropertyNameMatchingCopier
> before the 
> ContainerCopier sounds like a good approach.  A new
> class should not be 
> needed.  The Spring application context file that
> comes bundled with 
> Morph and is located in
> src\core\net\sf\morph\morphContext.xml should be 
> updated as well.
> 
> Matt S
> 
> > -Matt B
> >
> > --- Matt Benson <gud...@ya...> wrote:
> >
> >   
> >> SimpleDelegatingTransformer currently uses as its
> >> last
> >> two resorts a containerCopier and a
> >> propertyNameMatchingCopier; attempting to convert
> a
> >> POJO to a map results in that object being added
> to
> >> the map with a null key (the container copier
> does
> >> this by assuming the POJO is a container with a
> >> single
> >> component).  It is my assertion that the average
> >> user
> >> would rather want the POJO's properties mapped as
> >> key-value pairs in the target map.
> >>
> >>   My first instinct was to add a
> >> PropertyNameMatchingCopier with its dest
> class(es)
> >> set
> >> to Map.class just before ContainerCopier.  But
> then
> >> I
> >> realized that copying an indexed container to a
> map
> >> would be disabled that way.  So I wrote an
> >> ObjectToMapCopier which only matches Map
> >> destinations
> >> and extends SDT, delegating first to a
> >> ContainerCopier
> >> that only does indexed container reflection, then
> to
> >> a
> >> PropertyNameMatchingCopier.  So that it can be
> used
> >> beneath SDT, it implements NodeCopier.
> >>
> >>   Copying
> >> PropertyNameMatchingCopierTestCase.testCopy() to
> >> DelegatingCopierTestCase shows that Morph
> currently
> >> does not implement this (IMO) reasonable behavior
> by
> >> default.  By adding ObjectToMapCopier to SDT's
> >> default
> >> components list, just before ContainerCopier, we
> can
> >> convert POJOs to Maps while continuing to convert
> >> indexed collections as expected.
> >>
> >> I would like to make this change.  Any arguments
> >> against my interpretation of the likely DWIM
> >> interpretation of "copy this POJO to this Map"???
> >>
> >> -Matt
> >>
> >>
> >>  
> >>
> >>     
> >
>
____________________________________________________________________________________
> >   
> >> 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
> >   
> >
> >
> >
> >  
> >
>
____________________________________________________________________________________
> > Do you Yahoo!?
> > Everyone is raving about the all-new Yahoo! Mail
> beta.
> > http://new.mail.yahoo.com
> >
> >
>
-------------------------------------------------------------------------
> > 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
> 




 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

Re: [morph-developer] Copying Objects to Maps

[Matt S. <Mat...@wh...>]

Matt Benson wrote:
> Follow Up:
>
> 1) No news is good news, so I will implement such that
> beans will indeed map properties to map entries by
> default.
>   
OK, I had a chance to look over this.  The reason for the old behavior 
was an implementation coincidence and not really intended.  It happened 
because:
- MapReflector is perfectly happy treating a Map as both a container and 
as a bean
- ContainerCopier has to come before PropertyNameMatchingCopier, 
otherwise when collections were encountered you would have the 
properties of the collection copied rather than their data
> 2) I over-analyzed the issue before; my original idea
> of using a PropertyNameMatchingCopier is sufficient to
> copy indexed containers to maps, since a basic
> reflector will list the string versions of available
> indices as property names.  :)
>   
Adding a more specific PropertyNameMatchingCopier before the 
ContainerCopier sounds like a good approach.  A new class should not be 
needed.  The Spring application context file that comes bundled with 
Morph and is located in src\core\net\sf\morph\morphContext.xml should be 
updated as well.

Matt S

> -Matt B
>
> --- Matt Benson <gud...@ya...> wrote:
>
>   
>> SimpleDelegatingTransformer currently uses as its
>> last
>> two resorts a containerCopier and a
>> propertyNameMatchingCopier; attempting to convert a
>> POJO to a map results in that object being added to
>> the map with a null key (the container copier does
>> this by assuming the POJO is a container with a
>> single
>> component).  It is my assertion that the average
>> user
>> would rather want the POJO's properties mapped as
>> key-value pairs in the target map.
>>
>>   My first instinct was to add a
>> PropertyNameMatchingCopier with its dest class(es)
>> set
>> to Map.class just before ContainerCopier.  But then
>> I
>> realized that copying an indexed container to a map
>> would be disabled that way.  So I wrote an
>> ObjectToMapCopier which only matches Map
>> destinations
>> and extends SDT, delegating first to a
>> ContainerCopier
>> that only does indexed container reflection, then to
>> a
>> PropertyNameMatchingCopier.  So that it can be used
>> beneath SDT, it implements NodeCopier.
>>
>>   Copying
>> PropertyNameMatchingCopierTestCase.testCopy() to
>> DelegatingCopierTestCase shows that Morph currently
>> does not implement this (IMO) reasonable behavior by
>> default.  By adding ObjectToMapCopier to SDT's
>> default
>> components list, just before ContainerCopier, we can
>> convert POJOs to Maps while continuing to convert
>> indexed collections as expected.
>>
>> I would like to make this change.  Any arguments
>> against my interpretation of the likely DWIM
>> interpretation of "copy this POJO to this Map"???
>>
>> -Matt
>>
>>
>>  
>>
>>     
> ____________________________________________________________________________________
>   
>> 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
>   
>
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> -------------------------------------------------------------------------
> 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
>
>   

Re: [morph-developer] Copying Objects to Maps

[Matt S. <Mat...@wh...>]

Hi Matt B - I was out of the office on Friday and am just catching up on 
emails now.  I will get back to you today.

Matt S

Matt Benson wrote:
> Follow Up:
>
> 1) No news is good news, so I will implement such that
> beans will indeed map properties to map entries by
> default.
>
> 2) I over-analyzed the issue before; my original idea
> of using a PropertyNameMatchingCopier is sufficient to
> copy indexed containers to maps, since a basic
> reflector will list the string versions of available
> indices as property names.  :)
>
> -Matt B
>
> --- Matt Benson <gud...@ya...> wrote:
>
>   
>> SimpleDelegatingTransformer currently uses as its
>> last
>> two resorts a containerCopier and a
>> propertyNameMatchingCopier; attempting to convert a
>> POJO to a map results in that object being added to
>> the map with a null key (the container copier does
>> this by assuming the POJO is a container with a
>> single
>> component).  It is my assertion that the average
>> user
>> would rather want the POJO's properties mapped as
>> key-value pairs in the target map.
>>
>>   My first instinct was to add a
>> PropertyNameMatchingCopier with its dest class(es)
>> set
>> to Map.class just before ContainerCopier.  But then
>> I
>> realized that copying an indexed container to a map
>> would be disabled that way.  So I wrote an
>> ObjectToMapCopier which only matches Map
>> destinations
>> and extends SDT, delegating first to a
>> ContainerCopier
>> that only does indexed container reflection, then to
>> a
>> PropertyNameMatchingCopier.  So that it can be used
>> beneath SDT, it implements NodeCopier.
>>
>>   Copying
>> PropertyNameMatchingCopierTestCase.testCopy() to
>> DelegatingCopierTestCase shows that Morph currently
>> does not implement this (IMO) reasonable behavior by
>> default.  By adding ObjectToMapCopier to SDT's
>> default
>> components list, just before ContainerCopier, we can
>> convert POJOs to Maps while continuing to convert
>> indexed collections as expected.
>>
>> I would like to make this change.  Any arguments
>> against my interpretation of the likely DWIM
>> interpretation of "copy this POJO to this Map"???
>>
>> -Matt
>>
>>
>>  
>>
>>     
> ____________________________________________________________________________________
>   
>> 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
>   
>
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> -------------------------------------------------------------------------
> 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
>
>   

Re: [morph-developer] Copying Objects to Maps

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

Follow Up:

1) No news is good news, so I will implement such that
beans will indeed map properties to map entries by
default.

2) I over-analyzed the issue before; my original idea
of using a PropertyNameMatchingCopier is sufficient to
copy indexed containers to maps, since a basic
reflector will list the string versions of available
indices as property names.  :)

-Matt B

--- Matt Benson <gud...@ya...> wrote:

> SimpleDelegatingTransformer currently uses as its
> last
> two resorts a containerCopier and a
> propertyNameMatchingCopier; attempting to convert a
> POJO to a map results in that object being added to
> the map with a null key (the container copier does
> this by assuming the POJO is a container with a
> single
> component).  It is my assertion that the average
> user
> would rather want the POJO's properties mapped as
> key-value pairs in the target map.
> 
>   My first instinct was to add a
> PropertyNameMatchingCopier with its dest class(es)
> set
> to Map.class just before ContainerCopier.  But then
> I
> realized that copying an indexed container to a map
> would be disabled that way.  So I wrote an
> ObjectToMapCopier which only matches Map
> destinations
> and extends SDT, delegating first to a
> ContainerCopier
> that only does indexed container reflection, then to
> a
> PropertyNameMatchingCopier.  So that it can be used
> beneath SDT, it implements NodeCopier.
> 
>   Copying
> PropertyNameMatchingCopierTestCase.testCopy() to
> DelegatingCopierTestCase shows that Morph currently
> does not implement this (IMO) reasonable behavior by
> default.  By adding ObjectToMapCopier to SDT's
> default
> components list, just before ContainerCopier, we can
> convert POJOs to Maps while continuing to convert
> indexed collections as expected.
> 
> I would like to make this change.  Any arguments
> against my interpretation of the likely DWIM
> interpretation of "copy this POJO to this Map"???
> 
> -Matt
> 
> 
>  
>
____________________________________________________________________________________
> 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
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

[morph-developer] Copying Objects to Maps

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

SimpleDelegatingTransformer currently uses as its last
two resorts a containerCopier and a
propertyNameMatchingCopier; attempting to convert a
POJO to a map results in that object being added to
the map with a null key (the container copier does
this by assuming the POJO is a container with a single
component).  It is my assertion that the average user
would rather want the POJO's properties mapped as
key-value pairs in the target map.

  My first instinct was to add a
PropertyNameMatchingCopier with its dest class(es) set
to Map.class just before ContainerCopier.  But then I
realized that copying an indexed container to a map
would be disabled that way.  So I wrote an
ObjectToMapCopier which only matches Map destinations
and extends SDT, delegating first to a ContainerCopier
that only does indexed container reflection, then to a
PropertyNameMatchingCopier.  So that it can be used
beneath SDT, it implements NodeCopier.

  Copying
PropertyNameMatchingCopierTestCase.testCopy() to
DelegatingCopierTestCase shows that Morph currently
does not implement this (IMO) reasonable behavior by
default.  By adding ObjectToMapCopier to SDT's default
components list, just before ContainerCopier, we can
convert POJOs to Maps while continuing to convert
indexed collections as expected.

I would like to make this change.  Any arguments
against my interpretation of the likely DWIM
interpretation of "copy this POJO to this Map"???

-Matt


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

Re: [morph-developer] SimpleLanguageBeanReflector

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

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

> 
> > 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...


"What I am working on" = basically a deep
PropertyNameMappingCopier .  IMO, Languages depend
mostly on Reflectors rather than Transformers so a
Transformer that uses a Language rather than a
Reflector is possibly a positive thing.  And as for
depending explicitly on SimpleLanguage, I am
defenseless on that front.  My approach here was to
reduce code duplication--"a deep property mapping
copier is similar to a shallow one"--but I will weigh
my options here and inform.

-Matt B

> 
> Matt
> 
>
-------------------------------------------------------------------------
> 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
> 




 
____________________________________________________________________________________
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