[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