Ah, OK. That's different, then. ;-) On Jun 11, 2010, at 9:02 AM, aappddeevv wrote:
> 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. >> >
