1. castor
  2. CASTOR-1336

Allow property listener registration per element/attribute to be required in the getter.


    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0 M2
    • Fix Version/s: None
    • Component/s: XML code generator
    • Labels:
    • Environment:
    • Number of attachments :


      The request is to enhance the binding file such that each element or attribute can have code generated so that the method signature for the getter would include the property listener input parameter. This would be useful in an environment that has data collected and shared with mulitple editors or threads. The shared parts of the data would be unobtainable without the creation of a property change listener. This will enforce the design to the users without having to remember to call the addPropertyChangeListener directly.

      The reason for this request is described in the email trail below. It tells a little bit about our usage of castor to collect the data for a gui interface.

      > Ralf:
      > Thanks for you quick response.
      > I was thinking that the binding file could be enhanced to allow for
      > specification of the listener at an element level. We are using castor
      > to hold the model for our editors. The editors share some of the model
      > data, but not all of it, so they only want to be notified of changes
      > to the shared items.
      > My suggestion is that instead of having to call the
      > addPropertyChangeListener when getting an item, the shared pieces
      > would require the listener when calling the getter... In other words,
      > the getter would call the addPropertyChangeListener. This could be
      > used to enforce the writers of the editors to use a listener when
      > asking for shared data from the model. It would avoid the possibility
      > that they would forget to call the listener registration method, and
      > thus avoid the debugging session when the shared data is not being
      > used properly.
      > I was just wondering if Castor had the ability to do this and if there
      > were any enhancements in the works to do this. I think Castor has lots
      > of features that are useful, I thought this might be useful to others
      > as well. I would love to be the one to dig through the code and modify
      > it to do this, but we have a very intense schedule for the product
      > that we are developing. There is a way around this as stated above.
      > Just thought I would add the suggestion. Without it we will still be
      > using Castor. I think it is a great product.
      > Barbara
      > ----Original Message----
      > From: Ralf Joachim
      > Sent: Monday, February 27, 2006 5:50 PM
      > To:
      > Subject: Re: [castor-user] Code generation format
      > Hi Barbara,
      > without a closer look at your enhancement request, 2 questions came to
      > my mind:
      > 1. How would you specify that Castor should create a getter with a
      > PropertyChangeListener for sharedItem but one without for notSharedItem?
      > 2. Where should Castor get the PropertyChangeListener from when
      > unmarshalling?
      > Having said that this seams to be a very special enhancement that may
      > not be of help to much other people in my opinon. If other committers
      > share this opinon we would refuse that enhancement. Another point, if we
      > agree to add this feature, is, if you would be in a position to
      > provide
      > us with a patch to add this.
      > Regards
      > Ralf
      > Castor JDO, committer
      > Barbara Prechtl schrieb:
      >>To whom it may concern:
      >>I have been working with Castor for generation of code from a schema.
      >>This has been working very well. I really appreciate all the work that
      >>has gone into this project. My question is related to the code that
      >>gets generated.
      >>In the environment I am working in, I need to enforce that certain
      >>objects are registered for. It is nice that Castor has the ability to
      >>generate the property change listeners for an object. I was just
      >>wondering if there is a way to ensure that the item getter has the
      >>property change listener in the getter method signature.
      >>For instance:
      >> <xsd:complexType name="DataObject">
      >> <xsd:sequence>
      >> <xsd:element name="sharedItem"
      > type="xsd:string"></xsd:element>
      >> <xsd:element name="notSharedItem" type="xsd:string"></xsd:element>
      >> </xsd:sequence>
      >> </xsd:complexType>
      >>For the above schema type, I would like to be able to specify to
      >>castor to generate the class so that the getter for the "sharedItem"
      >>property has a listener required and the getter or the "notSharedItem"
      >>does not. For instance the class would be generated as such:
      >>public class DataObject {
      >> String sharedItem = null;
      >> String notSharedItem = null;
      >> public String getSharedItem(PropertyChangeListener pc)

      { >> sharedItem.addPropertyChangeListener(pc); // or what >>ever is needed >> return sharedItem(); >> }

      >> public String getNotSharedItem()

      { >> return notSharedItem; >> }

      >>We are using this data as the model for a gui interface. There are
      >>multiple editors on the gui so some of the data is shared between
      >>editors. We would like to enforce that when shared data items are
      >>obtained they require that the listener is registered via the method
      >>The option that we have come up with is to wrap each of the castor
      >>classes with our own implementation classes that enforce our
      >>requirements on shared data. This may be a big effort, as most of the
      >>data is embedded into the schema model elements, and the schema may
      >>change as the project evolves.
      >>I was just wondering if castor has any support for this type of
      >>generation. I reviewed the user documentation, but have not come
      >>across an answer.



          • Assignee:
            Barbara Prechtl


            • Created: