You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2010/06/11 14:45:02 UTC
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.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877799#action_12877799 ]
>
> 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.
>
Re: [jira] Commented: (PIVOT-513)
Posted by Greg Brown <gk...@mac.com>.
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:gkbrown@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.
>>
>
RE: [jira] Commented: (PIVOT-513)
Posted by aappddeevv <aa...@verizon.net>.
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:gkbrown@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.
>