SWITCHYARD-1313 Add property support on tooling

[igarashitm]

Hi Brian, Rob,

Finally I have raised a JIRA for the property support on tooling.

https://issues.jboss.org/browse/SWITCHYARD-1313

Other discussions

• [basic design] https://community.jboss.org/thread/220742
• [BPEL] https://community.jboss.org/thread/221015

I know adding composite/component property support is not a big problem for Brian, but having a bit worrying about environment property substitution. if we have

<transacted>$transacted</transacted>

in switchyard.xml, but Editor shows this transacted flag as a checkbox, then what happen?

Let's talk further here!

Thanks,

Tomo

[bfitzpat]

The properties are definitely going to throw the editor for a loop, but we may be able to handle this somehow in EMF. Is there a utility method we can use to get the value of a registered property?

[dward]

Not in all cases. Sometimes the properties are visible only to the component or composite. Sometimes, they are contextual to the domain. And sometimes, they come from system and/or test properties.  In those cases, you got nothin' you can do in the editor.

This wouldn't be much of a problem if properties were always string values.  However, they really can be any type of object, like the Boolean example above.

[rcernich]

Hey Brian,

There is already support in the model for properties.  See Component.getProperty(), Composite.getProperty(), DomainType.getProperties().  I think all we need to do is expose these to the user.  Component could be done by adding a new property sheet.  Composite could be done the same.  Domain could be added to the domain page in the editor.

I think the problem lies in how we allow the user to edit the property values.  It looks like SCA allows users to specify "type" (along with a bunch of other stuff), which could be used to provide a more user friendly editor.  That said, if the value is an expression, as in the example above, a checkbox doesn't really work if you want to specify an expression.  So, for phase one, I'd just try to get the tools to the point where the user can create a property (name) and set its value (simple text box).

Engine guys speak up if this doesn't sound right.

Best,

Rob

[dward]

The only problem is when a property value cannot be represented by text.  Simple types like Strings, Booleans, and Numbers can be.  Others, not so easy.  However, I don't think we should have to worry about non-simple types.  In those cases, the values are coming from a more dynamic source, and wouldn't be specified via the tooling anyways.

[bfitzpat]

Sounds good. Thanks for the feedback Rob. That definitely gets out of specific typed controls such as checkboxes. Combo boxes and text boxes are ok because they're editable in most cases. And we'd just need to update validation to handle a property reference in a field.

I'll see what I can start along these lines. Thankfully most of the properties are already text boxes or combo boxes, so hopefully there won't be that may checkboxes to adjust... Ha!

[rcernich]

Hey David,

That's always a problem, especially in this case, where the property will ultimately be represented as a string in the switchyard.xml file.  We could do some trickerly like serializing the instance and chunking cdata into the switchyard.xml, but I'm guessing we don't support anything like that today, and, as you said, there's probably a more effective mechanism for providing complex values.

I was mostly focused on Strings for the reasons listed above _and_ because that is all that is supported by our domain type, which means you can't override a property that cannot be represented as a String anyway.

Either way, I think we've got 80% coverage with this approach.  We can always get fancy later.

Best,

Rob

[dward]

I'm all for "getting fancier later" - but that's another story...

Yeah, our PropertyModel now only supports Strings as values, but I think this should change eventually.  Our PropertiesModel does, though, implement PropertyResolver, which accounts for values of any Object type.  But I think the only place we actually levarage that today is CDI injection of property values.

[kcbabo]

I know adding composite/component property support is not a big problem for Brian, but having a bit worrying about environment property substitution. if we have

<transacted>$transacted</transacted>

Short term and long term thoughts:

• short term : the editor will not support entering $property values for booleans, so it doesn't need to display them.  It's internally consistent.  Opening projects which use a boolean property (i.e. they were created or modified outside the tooling), it would be nice if the editor didn't blow up and even nicer if the checkbox could be disabled as a visual indicator.
• long term : we likely need to use the underlying property resolver support in config to resolve project properties as a part of the config parsing in the tooling.  Not sure how this melds with EMF, but it may just be a situation where the tooling needs to recognize property syntax and then ask the config to resolve the property value.

[kcbabo]

To follow up on David's point about properties defined outside the switchyard.xml (e.g. system properties) and complex types (XML or non-primitive/literal), I think they have the same solution.  The tooling needs to be able to simply display the property key as the value of a config property.  In the case where the property is resolvable locally in the project, I'm not even sure it's a good idea to substitute the token with the real value since the user then loses track of the fact that it's specified via property.  I would suggest the following:

• If the value of any config attribute/element is a property key, display the property key in the editor (not the value).
• Provide a pop-up bubble or a link to a property editor from any property key, which allows the user to see the current effective definition.
• Values specified from system and test properties will not be visible from the above link.  Complex types will also be out of scope initially.

IMO, the first items is required for 0.8.  The second item is nice to have.  The third item might be out of scope for 1.0 unless there's a cheap solution.

[rcernich]

I must be missing something here.  It seems like we're really trying to get fancy here.  In most other applications, properties are simply name/value pairs.  I think we should stick to that and simply provide a text input for the name and a text input for the value, then allow users to add/remove those pairs.  This is consistent with most other tools (e.g. pom editor).

As for resolution, I suppose we could have an "effective" view that shows the resolved values (e.g. effective pom), but I think logging in the engine is probably more useful (e.g. properties referencing system properties).

It seems like we're mixing property declaration with property resolution.

Just my two cents.

[kcbabo]

I must be missing something here.  It seems like we're really trying to get fancy here.  In most other applications, properties are simply name/value pairs.  I think we should stick to that and simply provide a text input for the name and a text input for the value, then allow users to add/remove those pairs.  This is consistent with most other tools (e.g. pom editor).

This is precisely what I described in the required item for 0.8. 

Long term, passing an XML fragment as a property value or a reference to an object should be something that we look at.  The former is not critical, but should not be terribly difficult to support.  The latter is more like a bean reference and it's also not required.

As for resolution, I suppose we could have an "effective" view that shows the resolved values (e.g. effective pom), but I think logging in the engine is probably more useful (e.g. properties referencing system properties).

The effective view is basically just a context-sensitive hint about the current value of a property which is specified.  This is nice to have and really just saves the user the trouble of going to the properties views manually.  Since the property values can be overridden at runtime (e.g. via system and test properties), this is just a hint during development based on what's known in the application scope.

It seems like we're mixing property declaration with property resolution.

The resolution is just a hint.