[jira] Issue Comment Edited: (PIVOT-514) create an annotation to specify the default "child" property of a component used by the serializer to attach children objects

["Appddevvv (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PIVOT-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875967#action_12875967 ] 

Appddevvv edited comment on PIVOT-514 at 6/6/10 8:23 AM:
---------------------------------------------------------

Well I created the code for the default property and it seems to work well.  I only had to modify a few lines in the serializer class to add in some code that I had to deal with this already. Everything works as expected. However, I noticed a few areas of concern that affects the "safety" of using the serializer.

a) The current tree of wtk components often inherit from container. The container implements sequence. The serializer already automatically added elements to the sequence if no property was found. That's fine. However, I noticed (and tested) that illogical elements could be added to the sequence and that elements could be added to the sequence (if no property was specified) that did not make sense or produce the wrong listener behavior. That is, adding a component to a container would be allowed in the serializer but would be improper use of the parent.

Take SplitPane. It needs to have the left and right property set in order to fire listeners but if they are added to the sequence parent directly, the split pane listeners are not fired. The serializer and the user would never know until they debugged the situation and realized that they need to set the properties explicitly event though the serializer may not care. This is an inherent usage danger with the serializer. Obviously, if the split pane observed or intercepted the sequence mutating calls it could of course, fire the listeners regardless of how the components were added to the "container."

b) By adding a default property, it is possible to always have the right property set and further "safety checks" could be made.

c) Relying on the sequence in a container parent has less type safety versus a contained component list embedded in the object.

I think that relying on the sequence in container for the parent-child tree during tree construction can lead to confusing use by clients and I am raising this issue.  The only way to easily change this is to separate out the current container-component tree and create a tree based on the default property and/or a contained component list (which would be set as the default property).

I'm not proposing that we start constructing a different tree at this point but wanted to raise this as a discussion point. Its not clear that this is causing pivot clients alot of grief at the moment.  Creating a different tree structure has complexity all on its own, but the use of the serializer can lead to unexpected behavior if not used correctly.  Perhaps this could be a 2.0 discussion point and I'll think about raising this as a separate issue.

I'll submit the patch on the original intent of this issue (the default property) shortly. I was looking into the parser to see if I could easily (without major changes) allow free text as a child element and have that automatically added to the default property or text property as well.


      was (Author: aappddeevv):
    Well I created the code for the default property and it seems to work well.  I only had to modify a few lines in the serializer class to add in some code that I had to deal with this already. Everything works as expected. However, I did notice a few areas of concern that affects the "safety" of using the serializer.

a) The current tree of wtk components often inherit from container. The container implements sequence. The serializer already automatically added elements to the sequence if no property was found. That's fine. However, I noticed (and tested) that illogical elements could be added to the sequence and that elements could be added to the sequence (if no property was specified) that did not make sense or produce the wrong listener behavior. That is, adding a component to a container would be allowed in the serializer but would be the improper use of the parent object. 

Take SplitPane. It needs to have the left and right property set in order to fire listeners but if they are added to the sequence parent directly, the split pane listeners are not fired. The serializer and the user would never know until they debugged the situation and realized that they need to set the properties explicitly event though the serializer may not care. This is an inherent usage danger with the serializer. Obviously, if the split pane observed or intercepted the sequence mutating calls it could of course, fire the listeners regardless of how the components were added to the "container."

b) By adding a default property, it is possible to always have the right property set and further "safety checks" could be made.

c) Relying on the sequence in a container parent can also has less type safety versus a contained component list embedded in the object.

I think that relying on the sequence in container for the parent-child tree during tree construction can lead to confusing use by clients and I am raising this issue.  The only way to easily change this is to separate out the current container-component tree and create a tree based on the default property and/or a contained component list (which would be set as the default property).

I'm not proposing that we start constructing a different tree at this point but wanted to raise this as a discussion point. Its not clear that this is causing pivot clients alot of grief at the moment.  Creating a different tree structure has complexity all on its own, but the use of the serializer can lead to unexpected behavior if not used correctly.  Perhaps this could be a 2.0 discussion point and I'll think about raising this as a separate issue.

I'll submit the patch on the original intent of this issue (the default property) in a bit. I was looking into the parser to see if I could easily (without major changes) allow free text as a child element and have that automatically added to the default property or text property as well.

  
> create an annotation to specify the default "child" property of a component used by the serializer to attach children objects
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: PIVOT-514
>                 URL: https://issues.apache.org/jira/browse/PIVOT-514
>             Project: Pivot
>          Issue Type: Improvement
>          Components: wtk
>            Reporter: Appddevvv
>            Priority: Minor
>             Fix For: 1.6
>
>
> Add an annotation called @ContentProperty that specifies the default property to attach children to in the serializer. I found that I was making mistakes when creating WTKX that this annotation and a default "child attachment" approach could help. Benefits include:
> a) The client does not need to know which property to attach the children to. 
> b) To add objects to a collection the parent object does not need to extend from sequence. The sequence can be contained in the object instead of implementing the interface. Containment can be another approach to getting content into the parent objects versus inheritance.
> c) You can change some of the properties in the class where attachment occurs and your WTKX files do not have to change.
> The default mechanism would be similar to what exists today. It's a simple extension of it. The "attach child" search would be:
> a) If the content property is specified, use that property to add the child to. If the content property is a collection, add it to the collection.
> b) If the content property is not specified,
> b.1) If the parent object is a collection (this is how it is handled today) then add it to the collection using the List.add(Object) method.
> b.2) Add it to the property specified in the XML. This is also how it is handled today.
> I wrote this for a small modeled framework similar to pivot and could work up a couple of patches for this. This is very similar to how wpf handles child content specifications in XML. Thoughts?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.