[3.3] Groovy Expression Evaluator Improvements

[Daniel Feist]

Hi,

I'm about to start working on some changes to make the use of script-based expression evaluators such as groovy much easier.

The following wiki page includes information about the motivation for the change and the proposal with some before and after examples.

http://www.mulesoft.org/documentation/display/MULECDEV/Improve+Script+Expression+Evaluator+Context

If you have an feedback, suggestions or ideas please let me know.

This is the kind of improvement (more info if you follow the link)

THIS: <expression-filter expression="#[groovy:message.getInboundProperty('Content-Type")=='text/html')">
BECOMES: <expression-filter expression="#[groovy:inbound['Content-Type'] == 'text/html')">

For further information about other changes to expressions in Mule 3.3 see: http://www.mulesoft.org/documentation/display/MULECDEV/Mule+Expressions+Improvements

thanks!
Dan
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Dan Diephouse]

This is great Dan! Looking forward to using it :-)

Dan

Post by Daniel Feist
Hi,
I'm about to start working on some changes to make the use of script-based
expression evaluators such as groovy much easier.
The following wiki page includes information about the motivation for the
change and the proposal with some before and after examples.
http://www.mulesoft.org/documentation/display/MULECDEV/Improve+Script+Expression+Evaluator+Context
If you have an feedback, suggestions or ideas please let me know.
This is the kind of improvement (more info if you follow the link)
THIS: <expression-filter
expression="#[groovy:message.getInboundProperty('Content-Type")=='text/html')">
BECOMES: <expression-filter expression="#[groovy:inbound['Content-Type'] == 'text/html')">
For further information about other changes to expressions in Mule 3.3
http://www.mulesoft.org/documentation/display/MULECDEV/Mule+Expressions+Improvements
thanks!
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Nahuel Lofeudo]

I love the idea, but I'd be careful with mixing different ways of accessing the same variable or property.
In fact, even the name "variables" for flow-scoped properties is confusing. Can we stick to only one way of calling the same element? It'll make it much simpler to understand to new users.
Why not simply use:

inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']
and so on

or

properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']
and so on?

Even if groovy supports both scope['name'] and scope.name, let's document only one of the options and stick to it. Power users can use the other one, but the learning curve will be better for newbies without sacrificing any features.

----------------------------

Before:

#[groovy:message.getInvocationProperty('myVar')
After:

#[groovy:myVar)

Please don't. It's not clear where myVar comes from and it could happen that a local variable overwrites a flow or session variable and creates all kinds of havoc.

----------------------------

<when expression="#[groovy:exception is SystemException]">
<expression-filter expression="#[groovy:inbound['Content-Type'] == 'text/html')">

I like it. A LOT.

THANKS!
Nahuel

Post by Dan Diephouse
This is great Dan! Looking forward to using it :-)
Dan
Hi,
I'm about to start working on some changes to make the use of script-based expression evaluators such as groovy much easier.
The following wiki page includes information about the motivation for the change and the proposal with some before and after examples.
http://www.mulesoft.org/documentation/display/MULECDEV/Improve+Script+Expression+Evaluator+Context
If you have an feedback, suggestions or ideas please let me know.
This is the kind of improvement (more info if you follow the link)
THIS: <expression-filter expression="#[groovy:message.getInboundProperty('Content-Type")=='text/html')">
BECOMES: <expression-filter expression="#[groovy:inbound['Content-Type'] == 'text/html')">
For further information about other changes to expressions in Mule 3.3 see: http://www.mulesoft.org/documentation/display/MULECDEV/Mule+Expressions+Improvements
thanks!
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
--
Dan Diephouse
iON Product Manager
http://muleion.com

[Dan Diephouse]

Post by Nahuel Lofeudo
Please don't. It's not clear where myVar comes from and it could happen
that a local variable overwrites a flow or session variable and creates all
kinds of havoc.

Please give an example where this would happen.

[Daniel Feist]

Post by Nahuel Lofeudo
inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']

Considered this option, the issue with this was that it's not really clear that session and flow are are map of variables.

Post by Nahuel Lofeudo
properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']

We deliberately want to separate the concepts of "property" and "variable" rather than throw them all into the same back, this will make things easier to understand once documented well, for example a transformer to add an message property won't need a scope (this is a separate proposal though..!)

That said something like this might work:

inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']

WDYT? The only think you can't do with this is explicit get a variable and have the scope resolved automatically (flow/session).

I not sure about the use of plural, the only real reason for using plural is because it makes more sense if you want to get the whole map of properties/variables

Post by Nahuel Lofeudo
Even if groovy supports both scope['name'] and scope.name, let's document only one of the options and stick to it. Power users can use the other one, but the learning curve will be better for newbies without sacrificing any features.

Agree so we are best to use the ['..'] style.

Post by Nahuel Lofeudo
#[groovy:myVar)
Please don't. It's not clear where myVar comes from and it could happen that a local variable overwrites a flow or session variable and creates all kinds of havoc.

This would be well documented. Also note that inbound/outbound message properties are never used implicitly only ever user-set variables. I don't think conflicts would be likely and can easily be worked around, also those that prefer explicit can always use explicit if they want.

Thanks for the feedback

Dan
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Mariano Capurro]

In general I like the approach, but have one small concern and one question

Small concern: myVar vs. variables.session['myVar] / variables.flow['myVar]

Something bothers me thinking from Studio side as there are two ways to
represent the same. Studio proved to be really sensitive to having two ways
of doing the same thing. For me it is more clear to explicitly declare what
is the scope of the variable (ession or flow) or in the case that you don't
care do: variables['myVar']
Using myVar alone will make it more difficult when you have another
variable myVar in your groovy script for example. My opinion here is: If we
need to document something really well, then it is not easy to use or it
may be prune to confusion.

The question I have is that I saw that one of the things we are replacing
is the "header" evaluator. Are we planning to deprecate this in favor of
groovy?

Post by Daniel Feist

Post by Nahuel Lofeudo
inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']

Considered this option, the issue with this was that it's not really clear
that session and flow are are map of variables.

Post by Nahuel Lofeudo
properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']

We deliberately want to separate the concepts of "property" and "variable"
rather than throw them all into the same back, this will make things
easier to understand once documented well, for example a transformer to add
an message property won't need a scope (this is a separate proposal
though..!)
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
WDYT? The only think you can't do with this is explicit get a variable
and have the scope resolved automatically (flow/session).
I not sure about the use of plural, the only real reason for using plural
is because it makes more sense if you want to get the whole map of
properties/variables

Post by Nahuel Lofeudo
Even if groovy supports both scope['name'] and scope.name, let's

document only one of the options and stick to it. Power users can use the
other one, but the learning curve will be better for newbies without
sacrificing any features.
Agree so we are best to use the ['..'] style.

Post by Nahuel Lofeudo
#[groovy:myVar)
Please don't. It's not clear where myVar comes from and it could happen

that a local variable overwrites a flow or session variable and creates all
kinds of havoc.
This would be well documented. Also note that inbound/outbound message
properties are never used implicitly only ever user-set variables. I don't
think conflicts would be likely and can easily be worked around, also those
that prefer explicit can always use explicit if they want.
Thanks for the feedback
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Daniel Feist]

How about this, any better?

inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']

Personally I don't see an issue with studio, studio will simply provide auto-complete for inbound/outbound/flowVariable/sessionVariable etc. If the user decides to use myVar, then fine this will just be passed through and used.

If flow variables can be accessed implicitly is debatable and different people have different opinions. My view is that as long as there is an explicit alternative then what the fuss about, in most cases it will make use of expression more concise.

All the other evaluators will stay as they are, more and more people use groovy rather than those evaluators though, so we need to make it as painless as possible.

Dan

Post by Mariano Capurro
In general I like the approach, but have one small concern and one question
Small concern: myVar vs. variables.session['myVar] / variables.flow['myVar]
Something bothers me thinking from Studio side as there are two ways to represent the same. Studio proved to be really sensitive to having two ways of doing the same thing. For me it is more clear to explicitly declare what is the scope of the variable (ession or flow) or in the case that you don't care do: variables['myVar']
Using myVar alone will make it more difficult when you have another variable myVar in your groovy script for example. My opinion here is: If we need to document something really well, then it is not easy to use or it may be prune to confusion.
The question I have is that I saw that one of the things we are replacing is the "header" evaluator. Are we planning to deprecate this in favor of groovy?

Post by Nahuel Lofeudo
inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']

Considered this option, the issue with this was that it's not really clear that session and flow are are map of variables.

Post by Nahuel Lofeudo
properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']

We deliberately want to separate the concepts of "property" and "variable" rather than throw them all into the same back, this will make things easier to understand once documented well, for example a transformer to add an message property won't need a scope (this is a separate proposal though..!)
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
WDYT? The only think you can't do with this is explicit get a variable and have the scope resolved automatically (flow/session).
I not sure about the use of plural, the only real reason for using plural is because it makes more sense if you want to get the whole map of properties/variables

Post by Nahuel Lofeudo
Even if groovy supports both scope['name'] and scope.name, let's document only one of the options and stick to it. Power users can use the other one, but the learning curve will be better for newbies without sacrificing any features.

Agree so we are best to use the ['..'] style.

Post by Nahuel Lofeudo
#[groovy:myVar)
Please don't. It's not clear where myVar comes from and it could happen that a local variable overwrites a flow or session variable and creates all kinds of havoc.

This would be well documented. Also note that inbound/outbound message properties are never used implicitly only ever user-set variables. I don't think conflicts would be likely and can easily be worked around, also those that prefer explicit can always use explicit if they want.
Thanks for the feedback
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
--
Mariano Capurro
Engineering Technical Manager
MuleSoft
25 de mayo 555 9th floor
C.A.B.A., Argentina
Tel: [phone]

[Pablo La Greca]

Guys,

Can we move this conversation to the community forums? Maybe we can get
some other thoughts from the community. Also, using the community makes
this communication persistent so we can review it later in the future if we
have to do similar changes.

Pablo.

Post by Daniel Feist
How about this, any better?
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
Personally I don't see an issue with studio, studio will simply provide
auto-complete for inbound/outbound/flowVariable/sessionVariable etc. If
the user decides to use myVar, then fine this will just be passed through
and used.
If flow variables can be accessed implicitly is debatable and different
people have different opinions. My view is that as long as there is an
explicit alternative then what the fuss about, in most cases it will make
use of expression more concise.
All the other evaluators will stay as they are, more and more people use
groovy rather than those evaluators though, so we need to make it as
painless as possible.
Dan
In general I like the approach, but have one small concern and one question
Small concern: myVar vs. variables.session['myVar] /
variables.flow['myVar]
Something bothers me thinking from Studio side as there are two ways to
represent the same. Studio proved to be really sensitive to having two ways
of doing the same thing. For me it is more clear to explicitly declare what
is the scope of the variable (ession or flow) or in the case that you don't
care do: variables['myVar']
Using myVar alone will make it more difficult when you have another
variable myVar in your groovy script for example. My opinion here is: If we
need to document something really well, then it is not easy to use or it
may be prune to confusion.
The question I have is that I saw that one of the things we are replacing
is the "header" evaluator. Are we planning to deprecate this in favor of
groovy?

Post by Daniel Feist

Post by Nahuel Lofeudo
inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']

Considered this option, the issue with this was that it's not really
clear that session and flow are are map of variables.

Post by Nahuel Lofeudo
properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']

We deliberately want to separate the concepts of "property" and
"variable" rather than throw them all into the same back, this will make
things easier to understand once documented well, for example a transformer
to add an message property won't need a scope (this is a separate proposal
though..!)
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
WDYT? The only think you can't do with this is explicit get a variable
and have the scope resolved automatically (flow/session).
I not sure about the use of plural, the only real reason for using plural
is because it makes more sense if you want to get the whole map of
properties/variables

Post by Nahuel Lofeudo
Even if groovy supports both scope['name'] and scope.name, let's

document only one of the options and stick to it. Power users can use the
other one, but the learning curve will be better for newbies without
sacrificing any features.
Agree so we are best to use the ['..'] style.

Post by Nahuel Lofeudo
#[groovy:myVar)
Please don't. It's not clear where myVar comes from and it could happen

that a local variable overwrites a flow or session variable and creates all
kinds of havoc.
This would be well documented. Also note that inbound/outbound message
properties are never used implicitly only ever user-set variables. I don't
think conflicts would be likely and can easily be worked around, also those
that prefer explicit can always use explicit if they want.
Thanks for the feedback
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
*Mariano Capurro*
Engineering Technical Manager
MuleSoft
25 de mayo 555 9th floor
C.A.B.A., Argentina
Tel: [phone]

[Daniel Feist]

Already using the dev list, there must be an issue with the propagation to forums :-(

Dan

Guys,
Can we move this conversation to the community forums? Maybe we can get some other thoughts from the community. Also, using the community makes this communication persistent so we can review it later in the future if we have to do similar changes.
Pablo.
How about this, any better?
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
Personally I don't see an issue with studio, studio will simply provide auto-complete for inbound/outbound/flowVariable/sessionVariable etc. If the user decides to use myVar, then fine this will just be passed through and used.
If flow variables can be accessed implicitly is debatable and different people have different opinions. My view is that as long as there is an explicit alternative then what the fuss about, in most cases it will make use of expression more concise.
All the other evaluators will stay as they are, more and more people use groovy rather than those evaluators though, so we need to make it as painless as possible.
Dan

Post by Mariano Capurro
In general I like the approach, but have one small concern and one question
Small concern: myVar vs. variables.session['myVar] / variables.flow['myVar]
Something bothers me thinking from Studio side as there are two ways to represent the same. Studio proved to be really sensitive to having two ways of doing the same thing. For me it is more clear to explicitly declare what is the scope of the variable (ession or flow) or in the case that you don't care do: variables['myVar']
Using myVar alone will make it more difficult when you have another variable myVar in your groovy script for example. My opinion here is: If we need to document something really well, then it is not easy to use or it may be prune to confusion.
The question I have is that I saw that one of the things we are replacing is the "header" evaluator. Are we planning to deprecate this in favor of groovy?

Post by Nahuel Lofeudo
inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']

Considered this option, the issue with this was that it's not really clear that session and flow are are map of variables.

Post by Nahuel Lofeudo
properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']

We deliberately want to separate the concepts of "property" and "variable" rather than throw them all into the same back, this will make things easier to understand once documented well, for example a transformer to add an message property won't need a scope (this is a separate proposal though..!)
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
WDYT? The only think you can't do with this is explicit get a variable and have the scope resolved automatically (flow/session).
I not sure about the use of plural, the only real reason for using plural is because it makes more sense if you want to get the whole map of properties/variables

Post by Nahuel Lofeudo
Even if groovy supports both scope['name'] and scope.name, let's document only one of the options and stick to it. Power users can use the other one, but the learning curve will be better for newbies without sacrificing any features.

Agree so we are best to use the ['..'] style.

Post by Nahuel Lofeudo
#[groovy:myVar)
Please don't. It's not clear where myVar comes from and it could happen that a local variable overwrites a flow or session variable and creates all kinds of havoc.

This would be well documented. Also note that inbound/outbound message properties are never used implicitly only ever user-set variables. I don't think conflicts would be likely and can easily be worked around, also those that prefer explicit can always use explicit if they want.
Thanks for the feedback
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
--
Mariano Capurro
Engineering Technical Manager
MuleSoft
25 de mayo 555 9th floor
C.A.B.A., Argentina
Tel: [phone]

[Andrew Perepelytsya]

Separating variable and property is only adding to the confusion. This is
the case where fewer options would only help.

Andrew

Post by Daniel Feist
Already using the dev list, there must be an issue with the propagation to forums :-(
Dan
Guys,
Can we move this conversation to the community forums? Maybe we can get
some other thoughts from the community. Also, using the community makes
this communication persistent so we can review it later in the future if we
have to do similar changes.
Pablo.

Post by Daniel Feist
How about this, any better?
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
Personally I don't see an issue with studio, studio will simply provide
auto-complete for inbound/outbound/flowVariable/sessionVariable etc. If
the user decides to use myVar, then fine this will just be passed through
and used.
If flow variables can be accessed implicitly is debatable and different
people have different opinions. My view is that as long as there is an
explicit alternative then what the fuss about, in most cases it will make
use of expression more concise.
All the other evaluators will stay as they are, more and more people use
groovy rather than those evaluators though, so we need to make it as
painless as possible.
Dan
In general I like the approach, but have one small concern and one question
Small concern: myVar vs. variables.session['myVar] /
variables.flow['myVar]
Something bothers me thinking from Studio side as there are two ways to
represent the same. Studio proved to be really sensitive to having two ways
of doing the same thing. For me it is more clear to explicitly declare what
is the scope of the variable (ession or flow) or in the case that you don't
care do: variables['myVar']
Using myVar alone will make it more difficult when you have another
variable myVar in your groovy script for example. My opinion here is: If we
need to document something really well, then it is not easy to use or it
may be prune to confusion.
The question I have is that I saw that one of the things we are replacing
is the "header" evaluator. Are we planning to deprecate this in favor of
groovy?

Post by Daniel Feist

Post by Nahuel Lofeudo
inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']

Considered this option, the issue with this was that it's not really
clear that session and flow are are map of variables.

Post by Nahuel Lofeudo
properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']

We deliberately want to separate the concepts of "property" and
"variable" rather than throw them all into the same back, this will make
things easier to understand once documented well, for example a transformer
to add an message property won't need a scope (this is a separate proposal
though..!)
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
WDYT? The only think you can't do with this is explicit get a variable
and have the scope resolved automatically (flow/session).
I not sure about the use of plural, the only real reason for using
plural is because it makes more sense if you want to get the whole map of
properties/variables

Post by Nahuel Lofeudo
Even if groovy supports both scope['name'] and scope.name, let's

document only one of the options and stick to it. Power users can use the
other one, but the learning curve will be better for newbies without
sacrificing any features.
Agree so we are best to use the ['..'] style.

Post by Nahuel Lofeudo
#[groovy:myVar)
Please don't. It's not clear where myVar comes from and it could

happen that a local variable overwrites a flow or session variable and
creates all kinds of havoc.
This would be well documented. Also note that inbound/outbound message
properties are never used implicitly only ever user-set variables. I don't
think conflicts would be likely and can easily be worked around, also those
that prefer explicit can always use explicit if they want.
Thanks for the feedback
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
*Mariano Capurro*
Engineering Technical Manager
MuleSoft
25 de mayo 555 9th floor
C.A.B.A., Argentina
Tel: [phone]

[Pablo La Greca]

I disagree.

Message properties and Variables have different lifecycle and putting them
together is making users get confused about which scope they should use.

I understand that it can confuse a little current users, but is going to be
a big win for new users.

Pablo.

Post by Andrew Perepelytsya
Separating variable and property is only adding to the confusion. This is
the case where fewer options would only help.
Andrew

Post by Daniel Feist
Already using the dev list, there must be an issue with the propagation to forums :-(
Dan
Guys,
Can we move this conversation to the community forums? Maybe we can get
some other thoughts from the community. Also, using the community makes
this communication persistent so we can review it later in the future if we
have to do similar changes.
Pablo.

Post by Daniel Feist
How about this, any better?
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
Personally I don't see an issue with studio, studio will simply provide
auto-complete for inbound/outbound/flowVariable/sessionVariable etc. If
the user decides to use myVar, then fine this will just be passed through
and used.
If flow variables can be accessed implicitly is debatable and different
people have different opinions. My view is that as long as there is an
explicit alternative then what the fuss about, in most cases it will make
use of expression more concise.
All the other evaluators will stay as they are, more and more people use
groovy rather than those evaluators though, so we need to make it as
painless as possible.
Dan
In general I like the approach, but have one small concern and one question
Small concern: myVar vs. variables.session['myVar] /
variables.flow['myVar]
Something bothers me thinking from Studio side as there are two ways to
represent the same. Studio proved to be really sensitive to having two ways
of doing the same thing. For me it is more clear to explicitly declare what
is the scope of the variable (ession or flow) or in the case that you don't
care do: variables['myVar']
Using myVar alone will make it more difficult when you have another
variable myVar in your groovy script for example. My opinion here is: If we
need to document something really well, then it is not easy to use or it
may be prune to confusion.
The question I have is that I saw that one of the things we are
replacing is the "header" evaluator. Are we planning to deprecate this in
favor of groovy?

Post by Daniel Feist

Post by Nahuel Lofeudo
inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']

Considered this option, the issue with this was that it's not really
clear that session and flow are are map of variables.

Post by Nahuel Lofeudo
properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']

We deliberately want to separate the concepts of "property" and
"variable" rather than throw them all into the same back, this will make
things easier to understand once documented well, for example a transformer
to add an message property won't need a scope (this is a separate proposal
though..!)
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
WDYT? The only think you can't do with this is explicit get a variable
and have the scope resolved automatically (flow/session).
I not sure about the use of plural, the only real reason for using
plural is because it makes more sense if you want to get the whole map of
properties/variables

Post by Nahuel Lofeudo
Even if groovy supports both scope['name'] and scope.name, let's

document only one of the options and stick to it. Power users can use the
other one, but the learning curve will be better for newbies without
sacrificing any features.
Agree so we are best to use the ['..'] style.

Post by Nahuel Lofeudo
#[groovy:myVar)
Please don't. It's not clear where myVar comes from and it could

happen that a local variable overwrites a flow or session variable and
creates all kinds of havoc.
This would be well documented. Also note that inbound/outbound message
properties are never used implicitly only ever user-set variables. I don't
think conflicts would be likely and can easily be worked around, also those
that prefer explicit can always use explicit if they want.
Thanks for the feedback
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
*Mariano Capurro*
Engineering Technical Manager
MuleSoft
25 de mayo 555 9th floor
C.A.B.A., Argentina
Tel: [phone]

[Daniel Feist]

Hi,

I've updated the proposal to use:

flowVariables['name'] and sessionVariables['name']

I think this is clearer and avoids 3 levels.

The only think i'm not 100% convinced about is making attachments two separate top-level maps rather than only exposing them via the message (given it's not used much).

Dan

Post by Mariano Capurro
In general I like the approach, but have one small concern and one question
Small concern: myVar vs. variables.session['myVar] / variables.flow['myVar]
Something bothers me thinking from Studio side as there are two ways to represent the same. Studio proved to be really sensitive to having two ways of doing the same thing. For me it is more clear to explicitly declare what is the scope of the variable (ession or flow) or in the case that you don't care do: variables['myVar']
Using myVar alone will make it more difficult when you have another variable myVar in your groovy script for example. My opinion here is: If we need to document something really well, then it is not easy to use or it may be prune to confusion.
The question I have is that I saw that one of the things we are replacing is the "header" evaluator. Are we planning to deprecate this in favor of groovy?

Post by Nahuel Lofeudo
inbound['name']
outbound['name']
session['name']
flow['name']
inboundAttachments['name']

Considered this option, the issue with this was that it's not really clear that session and flow are are map of variables.

Post by Nahuel Lofeudo
properties.inbound['name']
properties.outbound['name']
properties.session['name']
properties.flow['name']
properties.inboundAttachments['name']

We deliberately want to separate the concepts of "property" and "variable" rather than throw them all into the same back, this will make things easier to understand once documented well, for example a transformer to add an message property won't need a scope (this is a separate proposal though..!)
inbound['name']
outbound['name']
myVar
flowVariables['myVar']
sessionVariables['myVar']
inboundAttachments['name']
onboundAttachments['name']
WDYT? The only think you can't do with this is explicit get a variable and have the scope resolved automatically (flow/session).
I not sure about the use of plural, the only real reason for using plural is because it makes more sense if you want to get the whole map of properties/variables

Post by Nahuel Lofeudo
Even if groovy supports both scope['name'] and scope.name, let's document only one of the options and stick to it. Power users can use the other one, but the learning curve will be better for newbies without sacrificing any features.

Agree so we are best to use the ['..'] style.

Post by Nahuel Lofeudo
#[groovy:myVar)
Please don't. It's not clear where myVar comes from and it could happen that a local variable overwrites a flow or session variable and creates all kinds of havoc.

This would be well documented. Also note that inbound/outbound message properties are never used implicitly only ever user-set variables. I don't think conflicts would be likely and can easily be worked around, also those that prefer explicit can always use explicit if they want.
Thanks for the feedback
Dan
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
--
Mariano Capurro
Engineering Technical Manager
MuleSoft
25 de mayo 555 9th floor
C.A.B.A., Argentina
Tel: [phone]

[Ken Yagen]

don't have any direct comments. Generally like the improvement in
terms of more concise syntax.

Ken Yagen
Vice President Engineering | MuleSoft Inc.
30 Maiden Lane, Suite 500 | San Francisco, CA 94108
Direct: [phone] | Mobile: [phone]
ken.yagen-569aJbr3hvNWk0Htik3J/***@public.gmane.org | twitter.com/kenyagen
http://www.mulesoft.com
MuleSoft is hiring: http://www.mulesoft.com/careers

Post by Daniel Feist
Hi,
I'm about to start working on some changes to make the use of script-based expression evaluators such as groovy much easier.
The following wiki page includes information about the motivation for the change and the proposal with some before and after examples.
http://www.mulesoft.org/documentation/display/MULECDEV/Improve+Script+Expression+Evaluator+Context
If you have an feedback, suggestions or ideas please let me know.
This is the kind of improvement (more info if you follow the link)
THIS: <expression-filter expression="#[groovy:message.getInboundProperty('Content-Type")=='text/html')">
BECOMES: <expression-filter expression="#[groovy:inbound['Content-Type'] == 'text/html')">
For further information about other changes to expressions in Mule 3.3 see: http://www.mulesoft.org/documentation/display/MULECDEV/Mule+Expressions+Improvements
thanks!
Dan
---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email