[TransWarp] usage of adviseModule('<module>') and other TW News

[Ulrich Eck]

Hi Phillip,


i think my partner and myself a fairly fascinated of
what can be done (with so little code) with TW .. it's indeed amazing :)


I have played around a lot and read the book you suggested
(Building Business Objects) during the last weeks.

right now I'm trying to implement the basics for a BOF (Business Object 
Facility)
like it is described in the book using Pyro.

they say in the book:
" .. one can add packages (most likely at runtime) that contains 1..n DC 
Classes.
     these DC Classes are then visible/usable within the BOF-Framework .."

this is the point where my question begins:

how do i use adviseModule()

untested code .. just what i think i've understood till yet:

I have one global Module, let's call it PackageConfig, that is imported
from the Application. Every package will be installed in a seperate
directory and is imported (via dir-list) at startup/reloadPackages.

i would like to avoid the need of a global config-module for packages.
they are in the right directory .. so they will be loaded.

could i use the following code to achieve this ??

::PackageConfig.py
from TW.API import *

class AllPackages(SEF.Service):

	from BasePackage import BasePackage

setupModule()
::

::<pathToPackages>/FirstPackage/Config.py
from TW.API import  *

class AllPackages:

	from FirstPackage import FirstPackage

adviseModule('PackageConfig')
::

::<pathToPackages>/SecondPackage/Config.py
from TW.API import  *

class AllPackages:

	from SecondPackage import SecondPackage

adviseModule('PackageConfig')
::

the importer is easy to write: for each dir in packagedir import 
<module>.Config

after all i should have a result like:

AllPackages:
	BasePackage
	FirstPackage
	SecondPackage


Is this basically correct ??

the following questions i have:
- can this be done at runtime?
- if yes: how does this affect instances of package-classes, that already 
exist ??

- when are meta-classes executed (e.g. if DCClasses of Packages are 
ActiveDescriptors
  that register their Type within the network .. actually doing this ..)
  a. when i advise a module, is it somehow interpreted again?  -> this 
could end in multiple
     registrations of a Type which is bad ..
  b. best would be, if only new ActiveDescriptors are activated .. is this 
possible ??

- what else should i take care of when trying this?


.. so as we really consider to use TransWarp for our project:

- Are any major changes scheduled for 0.2 (e.g. Database/SEF)
- Would you use TransWarp for a Project (mid-size UserManagement for 
Win/Unix Networks)
  that should reach first usable state end of summer ?? (without TransWarp 
this would
  probably not be doable ;-)

We have agreed, to open all sources of our basic services we implement in 
Transwarp.
We are basically interested in sharing work with others that have similar 
aims.

actually planned are:

- Distributed TransactionMonitor	Prototyping
						A TransactionMonitor using the COSTransactions
						Specification

- TransWarpWorkflow			Prototyping
						An activity-based Workflow system with persitent
						Backend (ZODB/LDAP/SQL) to store ProcessDefinitions etc.
						It will be an implementation of the WfMC Model
						i use openflow as sample-implementation

- TransWarpNet				Prototyping
						A BOF implementation using Pyro (evtl. CORBA in future)
						that cares about threading/concurrency/lifetime/events/
						messaging/net/transaction/workflow/data-access

- TransWarpGUI				FirstPreview (where it all began :))
						A Model for a wxWindows GUI-Application that will
						go under heavy refactoring to make use
						of the UDO/WDO concept

- TransWarp??Database??			Samples Exist
						ADSI/ADODB-Connection + Model (read/write)
						ZODB-Connection + Model (uses ZODB only for persistence
										but is quite handy for testing)
						improved LDAP/DataModel.

						if would be fine to see them in TW.Database if they reach
						stable state .. possible ??

RDO/EDO Objects are managed in DC Classes and use SEF and TW.Database.


BOF Shortkeys explained :-)
DC	DistributableComponent
DO	DistributableObject (instance of DC)

UDO->WDO->EDO->RDO

RDO	ResourceDO	(manages persistence)
EDO	EnterpriseDO	(has business logic)
WDO	WorkspaceDO	(provide data/events for UDO)
UDO	UserinterfaceDO	(a panel/window)


This is all work in progress ... nothing is ready yet, allthough the 
examples
usually run. there are no unit-tests yet ... but we're making progress.
						

anyone interested, have a look at:
http://cvs.net-labs.de 		(ViewCVS)


again .. if you'ld like us to use module-names that do not contain 
"TransWarp" please let
us know soon ;-)




thanks for your reply


Ulrich Eck
---------------------------------------------------------------------------
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
fon:   +49-8121-4747-11
fax:   +49-8121-4747-77
email: ueck at net-labs.de
http://www.net-labs.de