Hi Clinton,

So if the #{} syntax will never be removed we have to fix the little
line-break problem, because an XML file should not be
"formatting-sensitive".
Moreover yesterday night I made a simple test-case that reproduces the
example wrote in the iBatis manual (page 26), and the parser raises a
BuilderException (Improper inline parameter map format.  Should be:
#{propName,attr1=val1,attr2=val2}).
So if your intention is maintaining this syntax, and you're open to fix this
problem, I can submit through Jira the patch needed I mentioned mails ago in
the same thread.
What do you think?




2010/2/4 Clinton Begin <clinton.be...@gmail.com>

> These are all great thoughts.  As I said, one of them is likely to be
> implemented in the future.  It's just been deprioritized for now.
>
> Clinton
>
>
> On Thu, Feb 4, 2010 at 8:42 AM, Simone Tripodi 
> <simone.trip...@gmail.com>wrote:
>
>> Yep, I forgot the same syntax is used in annotations :)
>> BTW, it was just a 2 cents idea, not a real proposal.
>> Cheers,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>>
>>
>>
>> On Thu, Feb 4, 2010 at 4:22 PM, Clinton Begin <clinton.be...@gmail.com>
>> wrote:
>> > The syntax will never be removed, first because it's the preferred way
>> of
>> > the majority, and second, because we need a parameter syntax that is
>> > compatible with other configuration options, like annotations or JSON,
>> etc.
>> >
>> > Clinton
>> >
>> > On Thu, Feb 4, 2010 at 12:44 AM, Simone Tripodi <
>> simone.trip...@gmail.com>
>> > wrote:
>> >>
>> >> Hi all guys,
>> >> sorry but I explained my "2 cents idea" in the wrong way :P
>> >> Indeed, in my dreams, I'd completely _remove_ the #{} syntax, IMHO it
>> >> should be simpler reading a 100% pure XML SQL map like:
>> >>
>> >> update ORDER_ENTRY.CONTACT
>> >> set
>> >>  DEPT_ID = <parameter name="deptId" javaType="String"
>> jdbcType="VARCHAR"
>> >> />
>> >>  STATE_ID = <parameter name="stateId" javaType="String"
>> jdbcType="VARCHAR"
>> >> />
>> >>  TIME_ZONE_ID = <parameter name="timeZoneId" javaType="String"
>> >> jdbcType="VARCHAR" />
>> >>
>> >> instead of
>> >>
>> >> update ORDER_ENTRY.CONTACT
>> >> set
>> >>  DEPT_ID = #{deptId, javaType=String, jdbcType=VARCHAR},
>> >>  STATE_ID = #{stateId, javaType=String, jdbcType=VARCHAR},
>> >>  TIME_ZONE_ID = #{timeZoneId, javaType=String, jdbcType=VARCHAR}
>> >>
>> >> even if, of course, for a simpler case like:
>> >>
>> >> insert into
>> >>    users (
>> >>        id,
>> >>        username,
>> >>        password)
>> >> values (
>> >>        <parameter name="id"/>,
>> >>        <parameter name="username"/>,
>> >>        <parameter name="password"/>
>> >> )
>> >>
>> >> is much more verbose than:
>> >>
>> >> insert into
>> >>    users (
>> >>        id,
>> >>        username,
>> >>        password)
>> >> values (
>> >>        #{id},
>> >>        #{username},
>> >>        #{password}
>> >> )
>> >>
>> >> Thoughts?
>> >> All the best,
>> >> Simo
>> >>
>> >> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>> >>
>> >>
>> >>
>> >> On Thu, Feb 4, 2010 at 2:20 AM, Daryl Stultz <da...@6degrees.com>
>> wrote:
>> >> >
>> >> > On Wed, Feb 3, 2010 at 7:38 PM, Guy Rouillier <
>> guyr-...@burntmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On 2/3/2010 3:54 PM, Daryl Stultz wrote:
>> >> >
>> >> >
>> >> >>>
>> >> >>> I like this idea, though to keep things consistent, I would just
>> use
>> >> >>> "parameter" instead of "parameterDef".
>> >> >
>> >> > Right, I just made up parameterDef to indicate is was for defining
>> the
>> >> > parameter rather than using it. I'm pretty new to iBATIS, so I
>> haven't
>> >> > used
>> >> > <parameter> yet and didn't want to suggest an orthogonal usage of it.
>> >> > --
>> >> > Daryl Stultz
>> >> > _____________________________________
>> >> > 6 Degrees Software and Consulting, Inc.
>> >> > http://www.6degrees.com
>> >> > mailto:da...@6degrees.com
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>> >> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>
>>
>


-- 
Marco Speranza <marco.speranz...@gmail.com>

Reply via email to