Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of hzbarcea@gmail.com designates
 209.85.161.173 as permitted sender)
Message-ID: <4FBA5198.3030907@gmail.com>
Date: Mon, 21 May 2012 10:30:48 -0400
From: Hadrian Zbarcea <hzbarcea@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: [DISCUSS] - XML DSL and trimming value
References: 
 <CAGB5yNnC0vx5ap9j7yqhBVLMQKcF25NBL-UBsA=jXU1UZa-Ldw@mail.gmail.com>
 <4FB9155B.9050004@gmail.com>
 <CAGB5yNkx5ijykrjff-oSLCpFK74hrXqa_AL5e+s-napv2RUnbQ@mail.gmail.com>
In-Reply-To: 
 <CAGB5yNkx5ijykrjff-oSLCpFK74hrXqa_AL5e+s-napv2RUnbQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

IMO, that's something easily and better solved by properly documenting 
the functionality and expectations. A simple note in the wiki would 
achieve the same goal. I doubt there'll be a significant number of 
developers complaining that the expression must follow immediately after 
the tag and they don't have the flexibility to add spaces/tabs/crlf if 
they wanted to.

To me this is a non issue (and yes I am fully aware that we're talking 
about the xml dsl as the subject says). The only thing we'd do is add 
unnecessary complexity. On top of that it's a part of camel that is not 
even used at runtime, it's just the route creation. I think we already 
went too far down the path of accommodating dubious scenarios and to me, 
this is one of them. What problem exactly are we trying to solve? A user 
being unwilling to put the expression after the tag? A tool that 
generates xml and has the limitation that the text node will be on a 
separate line? I don't quite get it.

Hadrian

On 05/20/2012 03:28 PM, Claus Ibsen wrote:
> On Sun, May 20, 2012 at 6:01 PM, Hadrian Zbarcea<hzbarcea@gmail.com>  wrote:
>> My vote would be for *no* auto trim. Makes things predictable and easy to
>> understand.
>>
>> Hadrian
>>
>
> Well yeah we should improve on this.
>
> What I am talking about is the XML DSLs. This is the ones where people
> is struggling when you can have "spaces" around your expressions due
> coding style and whatnot.
>
> You dont have this problem for other expressions such as xpath. This
> is what you can do today
>
>    <camelContext xmlns="http://camel.apache.org/schema/spring">
>      <route>
>        <from uri="direct:start"/>
>        <filter>
>          <xpath>
>            /person[@name='James']
>          </xpath>
>          <to uri="mock:result"/>
>        </filter>
>      </route>
>    </camelContext>
>
> Which would be the same as
>
>    <camelContext xmlns="http://camel.apache.org/schema/spring">
>      <route>
>        <from uri="direct:start"/>
>        <filter>
>          <xpath>/person[@name='James']</xpath>
>          <to uri="mock:result"/>
>        </filter>
>      </route>
>    </camelContext>
>
> People is most likely accustomed to the "free form" in XML, where the
> "whitespace noise" is trimmed by default.
>
>
>
>
> What we could do, and should do IMHO, is to add an attribute to the
> expressions in Camel XML DSLs so you can turn trimming on|off.
>
> <simple trim="false">
>     I want no trim please
>     And I can do as I want
> </simple>
>
> And by having trim default to true, we can have the Camel expressions
> in the XML DSL behave consistent, and not include the "whitespace
> noise" by default.
>
>
>
>>
>> On 05/20/2012 06:33 AM, Claus Ibsen wrote:
>>>
>>> Hi
>>>
>>> We have a number of JIRA tickets which is related
>>> https://issues.apache.org/jira/browse/CAMEL-5294
>>> https://issues.apache.org/jira/browse/CAMEL-5285
>>> https://issues.apache.org/jira/browse/CAMEL-4990
>>>
>>> When you use the XML DSLs you may have a coding style where you have
>>> newlines, and spaces etc. in the text of the XML tags, eg
>>>
>>> <transform>
>>>    <simple>
>>>      data=${body}
>>>    </simple>
>>> </transform>
>>>
>>> Notice how we have new lines in the<simple>    text.
>>> Below shows what the intent is without newlines:
>>>
>>> <transform>
>>>    <simple>data=${body}</simple>
>>> </transform>
>>>
>>> Today we will auto trim Simple expressions (but not the others). IMHO
>>> I think this is wrong and we should make this consistent, to either
>>> - no auto trim
>>> - auto trim all expressions
>>>
>>> If we auto trim, and you want an explicit newline, then the end user
>>> can use a \n to indicate newline, eg
>>> <transform>
>>>    <simple>data=${body}\n</simple>
>>> </transform>
>>>
>>> I think we should go for a
>>> - auto trim all expressions
>>> - end users can use \n to force new lines
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>>
>>
>
>
>