You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by "Appddevvv (JIRA)" <ji...@apache.org> on 2010/06/03 16:57:58 UTC
[jira] Created: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
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.6
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.
[jira] Commented: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877447#action_12877447 ]
Greg Brown commented on PIVOT-513:
----------------------------------
Why is the ID value passed along to the object factory method? I assume this is necessary for your use case, but I'd just like to understand it a little better.
> 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.6
>
> 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.
[jira] Commented: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875573#action_12875573 ]
Greg Brown commented on PIVOT-513:
----------------------------------
OK, that helps - but I'd still like to understand more about the specific problem you are trying to solve with this approach. Why combine Spring serialization and WTKX serialization? Why not simply use one or the other? They both work pretty well on their own.
> 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.6
>
> 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.
[jira] Commented: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875312#action_12875312 ]
Greg Brown commented on PIVOT-513:
----------------------------------
This change seems fairly benign but I'd like to understand the use case better. What is it that you are trying to do that the existing serializer does not support? Perhaps there is another way to accomplish it via existing means?
> 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.6
>
> 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.
[jira] Updated: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Appddevvv (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Appddevvv updated PIVOT-513:
----------------------------
Attachment: serializer.patch
Patch with the changes.
> 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.6
>
> 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.
[jira] Resolved: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Brown resolved PIVOT-513.
------------------------------
Fix Version/s: 1.5.1
(was: 1.6)
Resolution: Fixed
I have applied a slightly modified version of this patch, but it should work fine for you. Let me know if you run into any issues.
> 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.
[jira] Commented: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Appddevvv (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875510#action_12875510 ]
Appddevvv commented on PIVOT-513:
---------------------------------
In order to use other frameworks for managing instance creation, you have to intercept the instance creation. So with the change you can use a spring context (or anything else for that matter) to create the instance. This allows you to inject data access classes or other elements, etc. right into the controller as needed depending on how you are implementing your classes. Pivot has a small injector using match-by-name so imagine being able to tap into something a bit more if you need to. The pivot injection should still be there of course. I wrote a spring serializer subclass and have a context created when some components are instantiated that contain a significant amount of configuration e.g. injecting a variety of data classes and other things into a component derived from a tree view automatically.
The create method for the serializer allows you to maintain your subclass version as the serializer as you recurse.
> 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.6
>
> 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.
[jira] Commented: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Greg Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876074#action_12876074 ]
Greg Brown commented on PIVOT-513:
----------------------------------
Thanks for the detailed description. I'm wondering if you could accomplish this with Bindable. The initialize() method could potentially be your hook into the serialization process - you could call out to your other framework(s) here.
> 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.6
>
> 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.
>
Re: [jira] Commented: (PIVOT-513)
Posted by Greg Brown <gk...@mac.com>.
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.
>
[jira] Commented: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Appddevvv (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Appddevvv (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876073#action_12876073 ]
Appddevvv commented on PIVOT-513:
---------------------------------
The specific problem to solve is object initialization using complex resource object graphs, such as with ORM, services and other application elements that are part of the controller tree. DI is suppose to be non-intrusive which means that you should not be wiring these objects inside your objects, but have the DI-container wire them together. Because the serializer as actually acting like a very light version of a DI-container (object instantiation, some initialization and object access), there are some lifecycle tasks that can only be intercepted inside the serializer class itself. I've noticed that the wpf xaml serializer is starting to look alot more like a DI-container and allow finer-grained control over object instantiation and lifecycle management. This makes any serializer more of a full lifecycle manager versus a straight serializer.
Whether its was intentional or not, the WTKX serializer has elements of a DI-container. Some of the demos already suggest this. One of the demos and some recent pivot user list posts asked about getting data into the component. One solution was to create it in code (not great) other said to use an object that in the constructor (or other tricks) will initialize the data (which was also a bit clumsy). Even in that simple scenario, potentially creating and initializing the object in a custom way could make sense for a specific application. That was for a simple list. For more complex data and data access methods, the small internal API change proposal allows you to support more complex scenarios using different composition technologies and different ways of implementing. Wpf has found that their simple "create a object data provider" and other approaches is not realistic or helpful for corporate production applications and that the data context has to be set using code because the objects behind the scenes have complex initialization requirements.
The reason that you need the hook is that you need fine grained control over when objects are created (and how) and how they are initialized before used--this allows clients to implement their application using their design approaches. Think about the WTKX annotation. It performs initialization of an element after the WTKX is loaded and in the processEndElement method. This initializes the objects bottoms-up, post-traversal order (I think) in the tree--which is fine for UI components but not necessarily correct for non-UI components.
In addition, deserialization is highly specialized especially when the conventions and practices of constructing the UI tree: there are mini-DSLs programmed into WTKX deserializer such as with styles, ids, or attached properties.
In one scenario, a tree branch model is created using about 10 collaborating objects (it accesses a couple of backing databases using hiberate) many of which I don't have control over or can modify the source. The collaborating objects, however, are wired together in a DI container and the tree branch model is wired with those collaborating objects in a DI container. The tree branch model sits in a view/controller that has multiple components to handle communication with a small workflow and event handling facility.
So rewriting serialization in another container environment is a large task and not using the WTKX deserializer is a huge productivity hit. Adding these simple hooks I have in the patch allow *some* flavors of integration (the patch allows different kinds to be created) and is sufficient for the moment and less intrusive on the pivot serializer. It doesn't force things on clients that don't want them but allows hooks for those who need to intercept and enables more client flexibility--they don't have to write code that exactly conforms completely to a specific instantiation and initialization approach. There are many ways to do all of this and this approach enables a number of other ways that can meet a range of application needs.
They both work well on their own but a small meeting in the middle is sometimes needed. This is also why pivot has its own application context class, to control the creation, lifecycle and access of objects relevant to it. Although in the case of DesktopApplicationContext as near as I can tell, it too does not need to assume that it creates the Application instance but does and hence, external objects cannot create it and will make it less easy to add additional client initialization flexibility e.g. preference getting/setting or app icon setting, OSGi starting, creating the Application in a WTKX file, etc.
> 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.6
>
> 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.
[jira] Commented: (PIVOT-513) allow instance creation customization
when reading WTKX files by creating an instance creation factory method
inside the serializer class
Posted by "Appddevvv (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876083#action_12876083 ]
Appddevvv commented on PIVOT-513:
---------------------------------
The intent is to not have to call out to anything else. That's pretty much
the point of DI and the method of decoupling using these techniques. By
placing my creation&init protocol into a serializer subclass, the approach
applies to all objects that you want it to apply to and there is no
interface or other requirements on the objects that receive the service.
This makes it also less intrusive and less coupled. If you use Bindable you
then have to get all the resources that are already defined elsewhere into
the resource dictionary.
Besides my use case, the patch allows other pivot clients to define their
creation and initialization protocol regardless of whether Bindable is used
for those objects or not and allow for non-pivot specific initialization
needs.
Its generally applicable and not specific only to my use-case. That's why I
recommended it as a patch versus just copying the serializer code into
another java file and maintaining it that way. It is for advanced use though
and is not something that every client would consider doing--in which case
the patch has no impact on them anyway.
> 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.6
>
> 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.
[jira] Issue Comment Edited: (PIVOT-513) allow instance creation
customization when reading WTKX files by creating an instance creation
factory method inside the serializer class
Posted by "Appddevvv (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PIVOT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876073#action_12876073 ]
Appddevvv edited comment on PIVOT-513 at 6/6/10 2:52 PM:
---------------------------------------------------------
The specific problem to solve is object initialization using complex resource object graphs, such as with ORM, services and other application elements that are part of the controller tree. DI is suppose to be non-intrusive which means that you should not be wiring these objects inside your objects, but have the DI-container wire them together. Because the serializer as actually acting like a very light version of a DI-container (object instantiation, some initialization and object access), there are some lifecycle tasks that can only be intercepted inside the serializer class itself. I've noticed that the wpf xaml serializer is starting to look alot more like a DI-container and allow finer-grained control over object instantiation and lifecycle management. This makes any serializer more of a full lifecycle manager versus a straight serializer.
Whether its was intentional or not, the WTKX serializer has elements of a DI-container. Some of the demos already suggest this. One of the demos and some recent pivot user list posts asked about getting data into the component. One solution was to create it in code (not great) other said to use an object that in the constructor (or other tricks) will initialize the data (which was also a bit clumsy). Even in that simple scenario, potentially creating and initializing the object in a custom way could make sense for a specific application. That was for a simple list. For more complex data and data access methods, the small internal API change proposal allows you to support more complex scenarios using different composition technologies and different ways of implementing. Wpf has found that their simple "create a object data provider" and other approaches is not realistic or helpful for corporate production applications and that the data context has to be set using code because the objects behind the scenes have complex initialization requirements.
The reason that you need the hook is that you need fine grained control over when objects are created (and how) and how they are initialized before used--this allows clients to implement their application using their design approaches. Think about the WTKX annotation. It performs initialization of an element after the WTKX is loaded and in the processEndElement method. This initializes the objects bottoms-up, post-traversal order (I think) in the tree--which is fine for UI components but not necessarily correct for non-UI components.
In addition, deserialization is highly specialized especially when the conventions and practices of constructing the UI tree: there are mini-DSLs programmed into WTKX deserializer such as with styles, ids, or attached properties.
In one scenario, a tree branch model is created using about 10 collaborating objects (it accesses a couple of backing databases using hiberate) many of which I don't have control over or can modify the source. The collaborating objects, however, are wired together in a DI container and the tree branch model is wired with those collaborating objects in a DI container. The tree branch model sits in a view/controller that has multiple components to handle communication with a small workflow and event handling facility.
So rewriting serialization in another container environment is a large task and not using the WTKX deserializer is a huge productivity hit. Adding these simple hooks I have in the patch allow *some* flavors of integration (the patch allows different kinds to be created) and is sufficient for the moment and less intrusive on the pivot serializer. It doesn't force things on clients that don't want them but allows hooks for those who need to intercept and enables more client flexibility--they don't have to write code that exactly conforms completely to a specific instantiation and initialization approach. There are many ways to do all of this and this approach enables a number of other ways that can meet a range of application needs.
They both work well on their own but a small meeting in the middle is sometimes needed. This is also why pivot has its own application context class, to control the creation, lifecycle and access of objects relevant to it. Although in the case of DesktopApplicationContext as near as I can tell, it too does not need to assume that it creates the Application instance but does and hence, external objects cannot create it and will make it less easy to add additional client initialization flexibility e.g. preference getting/setting or app icon setting, OSGi starting, creating the Application in a WTKX file, etc.
I know this was too long.
was (Author: aappddeevv):
The specific problem to solve is object initialization using complex resource object graphs, such as with ORM, services and other application elements that are part of the controller tree. DI is suppose to be non-intrusive which means that you should not be wiring these objects inside your objects, but have the DI-container wire them together. Because the serializer as actually acting like a very light version of a DI-container (object instantiation, some initialization and object access), there are some lifecycle tasks that can only be intercepted inside the serializer class itself. I've noticed that the wpf xaml serializer is starting to look alot more like a DI-container and allow finer-grained control over object instantiation and lifecycle management. This makes any serializer more of a full lifecycle manager versus a straight serializer.
Whether its was intentional or not, the WTKX serializer has elements of a DI-container. Some of the demos already suggest this. One of the demos and some recent pivot user list posts asked about getting data into the component. One solution was to create it in code (not great) other said to use an object that in the constructor (or other tricks) will initialize the data (which was also a bit clumsy). Even in that simple scenario, potentially creating and initializing the object in a custom way could make sense for a specific application. That was for a simple list. For more complex data and data access methods, the small internal API change proposal allows you to support more complex scenarios using different composition technologies and different ways of implementing. Wpf has found that their simple "create a object data provider" and other approaches is not realistic or helpful for corporate production applications and that the data context has to be set using code because the objects behind the scenes have complex initialization requirements.
The reason that you need the hook is that you need fine grained control over when objects are created (and how) and how they are initialized before used--this allows clients to implement their application using their design approaches. Think about the WTKX annotation. It performs initialization of an element after the WTKX is loaded and in the processEndElement method. This initializes the objects bottoms-up, post-traversal order (I think) in the tree--which is fine for UI components but not necessarily correct for non-UI components.
In addition, deserialization is highly specialized especially when the conventions and practices of constructing the UI tree: there are mini-DSLs programmed into WTKX deserializer such as with styles, ids, or attached properties.
In one scenario, a tree branch model is created using about 10 collaborating objects (it accesses a couple of backing databases using hiberate) many of which I don't have control over or can modify the source. The collaborating objects, however, are wired together in a DI container and the tree branch model is wired with those collaborating objects in a DI container. The tree branch model sits in a view/controller that has multiple components to handle communication with a small workflow and event handling facility.
So rewriting serialization in another container environment is a large task and not using the WTKX deserializer is a huge productivity hit. Adding these simple hooks I have in the patch allow *some* flavors of integration (the patch allows different kinds to be created) and is sufficient for the moment and less intrusive on the pivot serializer. It doesn't force things on clients that don't want them but allows hooks for those who need to intercept and enables more client flexibility--they don't have to write code that exactly conforms completely to a specific instantiation and initialization approach. There are many ways to do all of this and this approach enables a number of other ways that can meet a range of application needs.
They both work well on their own but a small meeting in the middle is sometimes needed. This is also why pivot has its own application context class, to control the creation, lifecycle and access of objects relevant to it. Although in the case of DesktopApplicationContext as near as I can tell, it too does not need to assume that it creates the Application instance but does and hence, external objects cannot create it and will make it less easy to add additional client initialization flexibility e.g. preference getting/setting or app icon setting, OSGi starting, creating the Application in a WTKX file, etc.
> 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.6
>
> 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.