[
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.
