astefanutti commented on pull request #2831:
URL: https://github.com/apache/camel-k/pull/2831#issuecomment-994678794


   > The problem I see by remove the inline variant is that sometime is very 
verbose and not very intuitive, take as example the expressions block
   > 
   > With XML, you can write something like:
   > 
   > ```
   > <simple>${foo.bar}<simple>
   > ```
   > 
   > As today you can write something like:
   > 
   > ```yaml
   > simple: "${foo.bar}"
   > ```
   > 
   > Which seems nice and inline with the XML DSL, but removing the 
polymorphism would lead to:
   > 
   > ```yaml
   > simple: 
   >   expression: "${foo.bar}"
   > ```
   > 
   > Which to me seems to be not very intuitive and verbose.
   > 
   > In some cases, having only the inlined option may be ok, but if you have 
to also support additional options then, you cant express it in YAML because 
YAML does not have the same element and attribute concept as XML
   
   I agree. Actually, the real issue is to have both variants, not the 
_inlined_ variant by itself. So maybe the solution is to decide case by case 
which variant we want to keep based on its usage frequency.
   
   For instance for the `simple` expression:
   
   ```json
   "org.apache.camel.model.language.CSimpleExpression" : {
         "oneOf" : [ {
           "type" : "string"
         }, {
           "type" : "object",
           "properties" : {
             "expression" : {
               "type" : "string"
             },
             "id" : {
               "type" : "string"
             },
             "result-type" : {
               "type" : "string"
             },
             "trim" : {
               "type" : "boolean"
             }
           }
         } ],
         "required" : [ "expression" ]
       },
   ```
   
   It seems the _inlined_ variant is much more frequent than the _structured_ 
one, so the former would be kept.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to