OGNL uses property notation syntax which calls getters and setters. As
for the parenthesis syntax, there is no precedent in the market for such
a syntax being used to access fields directly. The syntax should be the
same (I want to navigate to X), with an additional attribute specifying
how it should be done (take me by plane or car).
Paul
Jeff Butler wrote:
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]
<mailto:[EMAIL PROTECTED]>> wrote:
Correction
* a fieldMappingEnabled=true/false...
On 2/10/07, *Brandon Goodin* <[EMAIL PROTECTED]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]>
> >> [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] On
> >> Behalf Of Paul Benedict
> >> Sent: Friday, 09 February 2007 15:17
> >> To: dev@ibatis.apache.org <mailto: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
> >>
> >
>
