I haven't looked into it but what do OGNL or other frameworks do? Do they offer some way to pick and choose between getters/setters and direct field access? If someone else has already solved this problem, naybe we could leverage their ideas.
Given no other guidance, I do like the idea of using getters/setters first and then rolling back to direct field access. But maybe the parenthesis syntax is OK if someone wants to force direct field access and bypass the getters/setters. The syntax without parenthesis would work in most cases, but this would also give a way to bypass the getters/setters if someone wanted to do something wierd. Jeff Butler On 2/10/07, Brandon Goodin <[EMAIL PROTECTED]> wrote:
Correction * a fieldMappingEnabled=true/false... On 2/10/07, Brandon Goodin <[EMAIL PROTECTED] > wrote: > > 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 > > > >> > > > > > > > > > > >
