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


Reply via email to