[jboss-jira] [JBoss JIRA] (WFCORE-759) Improve encapsulation of logic for handling ordered resource children

[Paul Ferraro (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFCORE-759:
--------------------------------
    Description: 
Currently, a resource that has ordered child resources needs to define this logic in 3 places:
# The ResourceDefinition needs to indicate that it supports indexed adds (solely for adding the appropriate add-index description) by overwriting SimpleResourceDefinition.isOrderedChildResource()
# The add operation handler of the parent resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that dictates which child types will be ordered
# The add operation handler of the ordered child resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that indicates that the resource supports add-index.

IMO, this seems like poor encapsulation.  If we added a ImmutableManagementResourceRegistration.isOrderedChildResource() method, then the AbstractAddStepHandler can query the resource registration to determine whether the current resource supports the add-index parameter, and to see which child types are ordered.  This would eliminate the need for subsystems to do #2 and #3 - based solely on the information provided by #1.
Also, indicating this behavior (i.e. #1) via overriding a protected method also seems a little hacky/tacked-on.  This method is only read by the SimpleResourceDefinition constructor - which means that this information is more appropriately provided by the constructor.  I assume it was done this way since the SimpleResourceDefinition constructors are already overly polluted/complex.  Why not instead define this behavior by:
ManagementResourceRegistration.registerOrderedSubModel(ResourceDefinition)
or
ManagementResourceRegistration.registerSubModel(ResourceDefinition).setOrdered(boolean)?
Thoughts?

  was:
Currently, a resource that has ordered child resources needs to define this logic in 3 places:
# The ResourceDefinition needs to indicate that it supports indexed adds (solely for adding the appropriate add-index description) by overwriting SimpleResourceDefinition.isOrderedChildResource()
# The add operation handler of the parent resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that dictates which child types will be ordered
# The add operation handler of the ordered child resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that indicates that the resource supports add-index.

IMO, this seems like poor encapsulation.  If we added a ImmutableManagementResourceRegistration.isOrderedChildResource() method, then the AbstractAddStepHandler can query the resource registration to determine whether the current resource supports the add-index parameter, and to see which child types are ordered.  This would eliminate the need for subsystems to do #2 and #3 - based solely on the information provided by #1.
Also, indicating this behavior (i.e. #1) via overriding a protected method also seems a little hacky/tacked-on.  This method is only read by the SimpleResourceDefinition constructor - which means that this information is more appropriately provided by the constructor.  I assume it was done this way since the SimpleResourceDefinition constructors are already overly polluted/complex.  Why not instead define this behavior by a ManagementResourceRegistration.registerOrderedSubModel(ResourceDefinition) method?
Thoughts?



> Improve encapsulation of logic for handling ordered resource children
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-759
>                 URL: https://issues.jboss.org/browse/WFCORE-759
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha4
>            Reporter: Paul Ferraro
>            Assignee: Kabir Khan
>
> Currently, a resource that has ordered child resources needs to define this logic in 3 places:
> # The ResourceDefinition needs to indicate that it supports indexed adds (solely for adding the appropriate add-index description) by overwriting SimpleResourceDefinition.isOrderedChildResource()
> # The add operation handler of the parent resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that dictates which child types will be ordered
> # The add operation handler of the ordered child resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that indicates that the resource supports add-index.
> IMO, this seems like poor encapsulation.  If we added a ImmutableManagementResourceRegistration.isOrderedChildResource() method, then the AbstractAddStepHandler can query the resource registration to determine whether the current resource supports the add-index parameter, and to see which child types are ordered.  This would eliminate the need for subsystems to do #2 and #3 - based solely on the information provided by #1.
> Also, indicating this behavior (i.e. #1) via overriding a protected method also seems a little hacky/tacked-on.  This method is only read by the SimpleResourceDefinition constructor - which means that this information is more appropriately provided by the constructor.  I assume it was done this way since the SimpleResourceDefinition constructors are already overly polluted/complex.  Why not instead define this behavior by:
> ManagementResourceRegistration.registerOrderedSubModel(ResourceDefinition)
> or
> ManagementResourceRegistration.registerSubModel(ResourceDefinition).setOrdered(boolean)?
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)