pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Appddevvv (JIRA)" <j...@apache.org>
Subject [jira] Commented: (PIVOT-513) allow instance creation customization when reading WTKX files by creating an instance creation factory method inside the serializer class
Date Sun, 06 Jun 2010 18:50:56 GMT

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


Mime
View raw message