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