-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Feature/properties in boundary definitions #113
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Vladimir Yussupov <[email protected]>
Signed-off-by: Vladimir Yussupov <[email protected]>
Signed-off-by: Vladimir Yussupov <[email protected]>
Signed-off-by: Vladimir Yussupov <[email protected]>
I generated a structure-diff below from pulling |
Signed-off-by: Vladimir Yussupov <[email protected]>
@@ -154,6 +154,8 @@ protected void setWPDElement(WinerysPropertiesDefinition res) { | |||
} | |||
|
|||
protected void setWPDNamespace(WinerysPropertiesDefinition res) { | |||
// bo be overridden by subclasses willing to use getWinerysPropertiesDefinition() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be marked as abstract
then, to force said overriding? This class is already abstract so we're not giving up anything for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was not sure if all TExtensibleElements actually need WPD support, since initially only TEntityType supported them. This is an attempt to reuse the method in both TEntityTypes and TServiceTemplates without duplicating it and at the same time without putting additional requirements on TExtensibleElements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a first sight, it looked good to me. I have some changes though and I will take a deeper look into it next week.
Please also ensure, that Travis completes successfully.
} | ||
|
||
protected void setWPDNamespace(WinerysPropertiesDefinition res) { | ||
// bo be overridden by subclasses willing to use getWinerysPropertiesDefinition() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need to have this "abstract" method. The implementations in both are similar and you could check if the current class is an instance of HasTargetNamespace
, and otherwise use a default one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that's a good solution if a namespace has to be set in the same way for both TEntityType and TServiceTemplate (currently setWPDNamespace is identical, so I assume there's no need for different implementations)
public class PropertiesResource { | ||
|
||
private static final Logger LOGGER = LoggerFactory.getLogger(PropertiesResource.class); | ||
|
||
private AbstractComponentInstanceResource res; | ||
private TEntityTemplate template; | ||
|
||
public PropertiesResource() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now it's not needed, I'll remove it (I first made BoundaryDefinitionsPropertiesResource
to be a subclass of PropertiesResource
and there I needed a default constructor, however I changed it later)
@@ -119,6 +120,11 @@ public BoundaryDefinitionsResource getBoundaryDefinitionsResource() { | |||
return new BoundaryDefinitionsResource(this, boundaryDefinitions); | |||
} | |||
|
|||
@Path("propertiesdefinition/") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please no trailing slash
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all other subresources (topologytemplate, plans, ...) in ServiceTemplateResource use trailing slashes, I just kept it consistent with the used convention
|
||
return this.http | ||
/*return this.http |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure!
public class PropertiesResource { | ||
|
||
private static final Logger LOGGER = LoggerFactory.getLogger(PropertiesResource.class); | ||
|
||
private AbstractComponentInstanceResource res; | ||
private TEntityTemplate template; | ||
|
||
public PropertiesResource() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need this?
@@ -119,6 +120,11 @@ public BoundaryDefinitionsResource getBoundaryDefinitionsResource() { | |||
return new BoundaryDefinitionsResource(this, boundaryDefinitions); | |||
} | |||
|
|||
@Path("propertiesdefinition/") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No trailing slashes
} | ||
} | ||
|
||
protected void setWPDNamespace(WinerysPropertiesDefinition res) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could actually implement it on this level since the methods are identical. To be able to use the getTargetNamespace
method, you can check if the current object is an instance of HasTargetNamespace
and cast it. Otherwise, you could use a default namespace.
Signed-off-by: Vladimir Yussupov <[email protected]>
Hi @v-yussupov, what needs to be done here for the final merge? |
@miwurster actually, I'm not sure if it's still needed. I think initially Lukas planned to have this feature for the paper, but eventually it was not used. @lharzenetter, is it still needed? |
@lharzenetter please revise, finalize and merge this PR ... otherwise, close it. |
Add Property Definitions for Properties in Boundary Defintions
With this feature, Properties in Boundary Defintions, in addition to the original plain XML specification, can be specified using a PropertyDefintions extension element that is defined on the level of ServiceTemplate.
What's added:
Properties Definition tab on the level of ServiceTemplate (similar to Node Types, etc)
Apart from Winery's KV proeprties, specification of XML elements/types is also possible
Properties are instantiated based on the specified Properties Definition
If no Properties Definition was specified, properties can be specified as in the original implementation
If existing Properties Definition are removed or their type is changed, e.g., from XML element to KV properties, specified properties and property mappings are also removed
Changes of KV Properties Definition (adding or removing new kv pairs) is reflected in both, properties and property mappings
Property Mappings now have a select element allowing to choose defined KV properties (in case KV properties were used in Properties Definition), otherwise an original input field is kept
Ensure that you followed http://eclipse.github.io/winery/dev/ToolChain#github---prepare-pull-request. Especially, we require a single commit
Ensure that the commit message is a good commit message
Ensure to use auto format in all files
Ensure that you appear in
NOTICE
at Copyright HoldersTests created for changes
Documentation updated (if needed)
Screenshots added (for UI changes)