To avoid the unpredictability of this functionality couldn't we add some configure options like:
* a diretoryToMappintEnabled=true/false property on the SQL Map Config. This would set it globally. False would follow strict bean and (eventually) constructor setting. * To bring further clarity we should define the lookup order in our docs. First a setter is attempted and then a property is attempted ( I would guess) * Perhaps you could even go as far as placing a reverseLookup=true/false field on mappings so that the field is examined before the setter this could be done in the inline and xml based mappings. Just some thoughts that may provide our usual implicit/explicit options. Layout the functionality to act in a common known way and provide the ability to tweak it when needed. Brandon On 2/9/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
No, what Jeff originally described in this thread, that you already agreed with. ;-) Clinton On 2/9/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > I searched the mail archives, but I am not privy to what Jeff originally > described. Is it anything similar to what I've been talking about? > Please send me a link or email :-) > > Thanks! > Paul > > Clinton Begin wrote: > > Okay guys. I'm convinced. Let's give this thread 24 hours for anyone > > else who wants to chime in. If nobody speaks up, we'll implement it > > the way Jeff described it originally. > > > > I think it will be cool regardless. I'm actually feeling pretty dumb > > for not implementing this 3 years ago...it was way too easy to have > > not done it long ago. it was a couple of extra methods and a few line > > changes in about 5 classes... :-/ > > > > Cheers, > > Clinton > > > > On 2/9/07, Poitras Christian <[EMAIL PROTECTED]> wrote: > >> > >> > >> I guess you have a point. > >> > >> Probably 90% of developpers won't want to know how the real path used... > >> Even if knowing it is interesting, it might disapoint people to force > >> them > >> to know it in advance. > >> In other cases, getters may include code that will be skipped using > >> direct > >> field access. > >> > >> Now the point to this email is that iBATIS didn't force people to have an > >> idea of the implementation before writting xml files. Changing this habit > >> may reduce the interest of iBATIS as a simple tool for O/R mapping. > >> Personally, I am afraid of the reactions some people will have when > >> they'll > >> begin mixing beans, pojos and maps (all 3 for crazy people only!, but > >> most > >> pojos/maps users). > >> Another problem will arise with resultMaps that will need this > >> notation at > >> the same time (to know if we call a setter or a use the field). > >> > >> I personally think it is to late to force people to change their iBATIS > >> habit. But make sure that they'll know what the framework will do. For > >> instance calling the getter if present, if not accessing the field > >> directly. > >> > >> Maybe the notation can be optionnal and will force iBATIS to try > >> accessing > >> the field first, then the getter if field is not present. Think this > >> would > >> do? > >> > >> Christian > >> > >> ________________________________ > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On > >> Behalf Of Paul Benedict > >> Sent: Friday, 09 February 2007 15:17 > >> To: dev@ibatis.apache.org > >> Subject: Re: Direct-to-Field mappings now implemented. > >> > >> > >> Poitras and Clinton, > >> > >> I agree. The refactoring argument is pretty strong. Property notation is > >> script-like because the actual means to get to the value (method vs. > >> direct-field access) is totally secondary to the intention. The developer > >> just needs to express the path, and the framework should be intelligent > >> enough to get there. But we can't assume the developer always wants > >> direct-field access, which is why the option must be turned on. > >> > >> PS: -1 on the brackets. > >> > >> Paul > >> > > >
