I hear you on that. Not so much hypothetical as I did not have time to code the spring extension to create the spring bean definition using the class and id together. I have to do this in the near future. In other words, the use case was there for me, but I was lazy on the programming in this pass.
-----Original Message----- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Friday, June 11, 2010 8:45 AM To: dev@pivot.apache.org Subject: Re: [jira] Commented: (PIVOT-513) This is what I was getting at when I was asking you about why you wanted this feature. If I knew that your Spring integration did not actually depend on this, I may not have committed the change. In Pivot, we generally try to avoid creating features based on hypothetical use cases. We like concrete use cases because they help frame the problem better and help to ensure that we are applying the correct solution. Hypothetical use cases tend to produce larger, more complex solutions, because they aren't focused on solving a specific problem or set of problems. This often results in over-designed code, which we really try to stay away from. I'll leave this code as-is, but in the future, I would appreciate it if you would be specific as to whether you are describing an actual or a hypothetical use case. My apologies if you did mention it somewhere and I just missed it. Thanks. Greg On Jun 11, 2010, at 8:03 AM, Appddevvv (JIRA) wrote: > > [ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plug in.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877799#action_1 2877799 ] > > Appddevvv commented on PIVOT-513: > --------------------------------- > > I actually do not use it for my spring-based extension to the serializer, > however, I was thinking about it and envisioned that others could use it as > I could also have used if I had decided to build my spring serializer > extension differently e.g. create the actual definition of the object using > bean definitions then create the context. In that case, one would want the > id to be consistent. > > So I did not have an immediate use case for it but thought that others > could. It also possible that we should pass a resources map to the create > instance method because it could contain initialization data, however, my > thinking there was that pivot level initialization should use its normal > process. > > > > > > >> allow instance creation customization when reading WTKX files by creating an instance creation factory method inside the serializer class >> ---------------------------------------------------------------------------- ------------------------------------------------------------- >> >> Key: PIVOT-513 >> URL: https://issues.apache.org/jira/browse/PIVOT-513 >> Project: Pivot >> Issue Type: Improvement >> Components: wtk >> Reporter: Appddevvv >> Priority: Minor >> Fix For: 1.5.1 >> >> Attachments: serializer.patch >> >> >> In order to allow instance creation customization, change the serialization class by: >> a) Creating a protected instance creation method in the WTKXSerializer class. >> b) Change a private constructor to protected. >> c) Allow the creation of custom serialization instances when recursing into the tree by creating a protected serialization creation method. >> No client visible APIs are changed. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. >
