[TransWarp] PROPOSAL: Split "SEF" into "CIS" and "SEF"
Phillip J. Eby
pje at telecommunity.com
Sat Jun 8 15:18:57 EDT 2002
I've been thinking about the outline of the new TransWarp tutorials, and I
have begun to realize that I have two altogether different sorts of things
in the SEF package. One part is Service-Element-Feature and associated
metamodel elements (such as fields, associations, ettc.). The other part
is the framework those elements fit into, or "Component Integration
Services", if you will. I think it will be a lot easier to teach TransWarp
if I separate them as follows:
==========================================================================
Component Integration Services
------------------------------
Package: TW.CIS, also accessible as "from TW.API import CIS"
Contents:
CIS.Component - currently SEF.Base. Attributes/methods will be renamed as
follows:
getService() --> lookupComponent()
getSEFparent() --> getParentComponent()
_setSEFparent() --> _setParentComponent()
_componentName --> getComponentName()
AutoCreatable, AutoCreated, bindTo, bindToNames, bindToParent, bindToSelf,
requireBinding, and any future binding-related facilities will migrate to
the CIS package. The TW.API.Meta module will probably become a module of
the CIS package, as its metaclasses are currently used almost exclusively
as part of the CIS framework.
There may also be a new class, 'CIS.RootComponent', designed for top-level
components, to integrate with global configuration services provided by
TW.Naming. (The long-term plan is to make the naming system a more
integrated part of TransWarp application development, so that component
bindings can reference objects in application configuration data and
naming-system contents.)
Service-Element-Feature
-----------------------
Package: TW.SEF, also accessible as "from TW.API import SEF"
Contents:
App, Service, Specialist, StructuralFeature, Field, Collection, Reference,
Sequence, Classifier, PrimitiveType, Enumeration, DataType, and Element
will remain in the SEF package. App will derive from SEF.Service and
CIS.RootComponent, if/when the latter winds up existing.
==========================================================================
These changes would also mean that it would be possible to change the
implementation of the CIS framework independently of one's implementation
of the SEF framework.
Last, but far from least, these changes will make it easier to compare and
contrast the CIS component architecture with the Zope 3 component
architecture, which offer different but potentially synergistic approaches
to component integration.
Comments and questions welcome, especially if anybody has any better ideas
for names of things. Also, if you're actively developing based on the
current preview releases or CVS, and your work would be painfully disrupted
by this, please let me know. I'd like to make this change *before* the 0.2
final release, because I can't write the 0.2 tutorials correctly otherwise.
More information about the PEAK
mailing list