[TransWarp] first experiences with Transwarp

[Phillip J. Eby]

At 01:01 PM 3/19/02 +0100, Ulrich Eck wrote:
>Alltogether it took me one week of playing with code to find my way into it.
>right now I built the Logger, that i mentioned (it is attached for anyone 
>interested),
>the Database Example. Right now I try to design a wxPython GUI with 
>Transwarp ..
>I will post my experiences (there were some comments, that something like this
>is also planned for Transwarp's future releases .. any thoughts on this 
>already??)

I hadn't thought it through a lot, but here's the gist of how I'd do 
GUI's...  I'd create GUI classes based on SEF.Element and SEF.Service, 
depending on whether the windows in question were independent or not.  That 
is, independent windows such as a MDI document window would be an Element, 
and dependent windows like buttons would be SEF.Service subclasses.

Parent windows would have attributes that were 'SEF.bindToNames()' lists of 
their children, that they would reference in order to set them up during 
initialization.  Or, I'd use an metaclass mixin for window classes that 
would detect and activate contained subwindow classes automatically.  Or 
maybe just use a variant of ActiveDescriptor(s).  Anyway, I find having to 
write code to create subwindows and all that sort of thing dreadfully 
tedious, so being able to describe the window tree with a code tree is the 
main idea here.

Binding buttons to commands, or GUI elements to other GUI elements of 
course is trivial, using SEF.bindTo, bindToNames, bindToParent, etc.



>when i used it with the wrong Filter the LDAPConnection that returned 
>None, which
>is not sizeable .. so you're probably right, that this should be fixed
>in the Connections Module.

I'll check it out as soon as I can.



>How would you implement a larger application, that has several (independent)
>parts (that should be able to communicate with each-other)??
>
>would it look like:
>
>class AppComponentA(SEF.App):
>         ...
>class AppComponentB(SEF.App):
>         ...
>
>class MyApp(SEF.App):
>
>         newAppComponentA = AppComponentA
>         newAppComponentB = AppComponentB
>
>         ....
>
>         def start_component_a(self):
>                 self.componenta = self.newElement('newAppComponentA')
>
>         ...
>
>this is the only way i found, to interlace components and be able to
>make use of .getService/.getSEFparent/SEF.bindTo ...
>
>any comments on this ??

Yes.  Try:

class AppComponentA(SEF.Service):
     ...

class AppComponentB(SEF.Service):
     ...


class MyApp(SEF.App):

      AppComponentA = AppComponentA
      AppComponentB = AppComponentB


And now if you reference things they will work correctly.  Only items which 
are subclasses of SEF.DynamicBinding are auto-instantiated by 
reference.  Service is a subclass of DynamicBinding, App is not.  App is 
designed to be a top-level component, which is manually instantiated.  I 
suspect, however, that I could do away with the distinction between App and 
Service.  It is largely artificial, in order to have a place to stick 
'newElement()' and 'loadFromXMI()'.  These are holdovers from when the 
primary purpose of TransWarp was going to be managing UML and MOF 
models!  I'll take a look at cleaning this up when I'm able.