One change I'd like to see in the mapper file is to allow any ordering of clauses within a ResultMap. I've gotten tripped up twice because I put an association clause in the middle of a bunch of result clauses. Why would I want to do this? To keep the clauses in the same order as the columns from the select. I don't see why the parser should care about what order the clauses appear.

Thanks.

On 2/4/2010 2:00 PM, Clinton Begin wrote:
 >> because an XML file should not be "formatting-sensitive".

That's not true at all.  The XML tags shouldn't be formatting sensitive,
but the content can be.  That's our format, that's our requirement.

That said, I'm open to improving the error.  But I personally will not
support line breaks in the parameter structure.

Clinton

On Thu, Feb 4, 2010 at 9:03 AM, Marco Speranza
<marco.speranz...@gmail.com <mailto:marco.speranz...@gmail.com>> wrote:

    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
    <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:da...@6degrees.com>> wrote:
             >> >
             >> > On Wed, Feb 3, 2010 at 7:38 PM, Guy Rouillier
            <guyr-...@burntmail.com <mailto: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 <mailto:da...@6degrees.com>
             >> >
             >>
             >>
            
---------------------------------------------------------------------
             >> To unsubscribe, e-mail:
            user-java-unsubscr...@ibatis.apache.org
            <mailto:user-java-unsubscr...@ibatis.apache.org>
             >> For additional commands, e-mail:
            user-java-h...@ibatis.apache.org
            <mailto:user-java-h...@ibatis.apache.org>
             >>
             >
             >

            
---------------------------------------------------------------------
            To unsubscribe, e-mail:
            user-java-unsubscr...@ibatis.apache.org
            <mailto:user-java-unsubscr...@ibatis.apache.org>
            For additional commands, e-mail:
            user-java-h...@ibatis.apache.org
            <mailto:user-java-h...@ibatis.apache.org>





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




--
Guy Rouillier

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org

Reply via email to