Notes on the part package
mcconnell at dpml.net
Thu Jan 26 01:03:01 EST 2006
Have completed the reshuffle of the parts api. Basically this has involved
moving internal management APIs out of the parts package and into the metro
APIs following which I've folded the part apis back to a single package.
Impact on anyone working on head should be minimal - just rename imports to
"net.dpml.part.local" and "net.dpml.part.remote" to "net.dpml.part". Here
is a patch target for convenience.
> -----Original Message-----
> From: dev-dpml-bounces at lists.ibiblio.org
> [mailto:dev-dpml-bounces at lists.ibiblio.org] On Behalf Of
> Stephen McConnell
> Sent: Wednesday, 25 January 2006 1:34 AM
> To: 'DPML Development'
> Subject: Notes on the part package
> As mentioned earlier I've been working on improving the part
> API. After working over things during this last week I think
> we have three distinct concerns with the parts package - two
> of these belong where they are and a third that needs to be moved.
> Here is a summary of the three:
> 1. the 'part' datatype management - this includes datatypes that
> associate a component definition with a controller. The classes
> include Part, PartHeader, and Directive.
> 2. the controller classes that deal with the loading of parts and
> the establishment of Component instances. The classes include
> Controller, Component, Provider etc.
> 3. classes dealing with local operations on component and provider
> instances include the Handler and PartsManager.
> The first two groups are in effect closely related in that
> the controller is the application used to load arbitrary
> parts as components and handles potential binding of foreign
> components to their associated foreign controllers. The
> third group IMO needs to be moved to the Metro model API as
> it is concerned with functional management of component
> instances that are a part of a component implementation. In
> particular a component implementation dealing with its
> internal "parts" is already aware of the respective component
> model(s) of the contained components.
> Overall impact is restricted to imports by component
> implementations that are programmatically manipulating
> internal sub-components. Relative to the DPML codebase this
> is minimal impact - however - I think once the API is sorted
> out properly its usage will be more prominent - hence the
> sorting out of this now instead of later.
> Cheers, Steve.
> Stephen McConnell
> mailto:mcconnell at dpml.net
> dev-dpml mailing list
> dev-dpml at lists.ibiblio.org
More information about the dev-dpml