Community
Participate
Working Groups
In the forum, an interesting problem has come up: 1. in an MWE workflow, a property containing backslashes (\) was declared. 2. This property was handed on to a component which evaluates an Xtend expression. Example: ------ var src_gen = "c:\\var\\foo" org.eclipse.xtend.typesystem.xsd.XMLWriter { uriExpression = { expression = "\'${src_gen}\' + extension::getFileName()" } } ------ http://www.openarchitectureware.org/forum/viewtopic.php?showtopic=15205 This can not work because either MWE needs to be able to escape the backshashes or Xtend need to have a string-token that can contain unescaped backslashes. If the propertie's original value is seen as untouchable, one solution might be to allow derived attributes: ------ var src_gen = "c:\\var\\foo" var src_gen_esacepd = replaceBacksashWithForwarndSlash(src_gen) org.eclipse.xtend.typesystem.xsd.XMLWriter { uriExpression = { expression = "\'${src_gen_esacepd}\' + extension::getFileName()" } } ------ with replaceBacksashWithForwarndSlash() being a Java method.
If you have four backslashes it should work. In case you want to reuse the information and only make it xtend compatible for the one situation (i.e. you can't use four backslashes), you should create a small subclass of the component, where you do the escaping. For instance : org.eclipse.xtend.typesystem.xsd.XMLWriter { uriExpression = MyEscapingUriExpression { expression = "\'${src_gen_esacepd}\' + extension::getFileName()" } } Where MyEscapingUriExpression replaces single backslashes by double backslashes. Also as suggested simple forward slashes should also solve the issue. I think such rare situations are solvable with this approach. Therefore I wouldn't want to add the proposed feature. Did I miss something?
