[TransWarp] first experiences with Transwarp
Ulrich Eck
ueck at net-labs.de
Tue Mar 19 07:01:28 EST 2002
Hi Philip
> [jumping up and down and exclaiming with joy]
>
> I'm absolutely amazed... First, that someone got this far with only the
> reference documentation and perhaps the code. Second, that so many
> things I have never even tested worked so darn well. :) Third, and
> perhaps most surprising of all, that you fixed the few bugs that did
> exist by using module inheritance.
:-)) thanks ...
>
> By the way, may I ask:
>
> * How long have you been playing with this?
hmm .. I watch the cvs-sources of TransWarp for a few months now ..
but I have never found a way into it, till i took the sources on my
psion-pda
on holiday and read entirely through them and thought i understood it.
After I came back, you had finished merging back the simplification-branch
and I started again at zero .. but the new-style API helped to grok it
much faster :)
At the beginning i was not able to transfer the Examples from the Wiki but
one of your messages helped at this point.
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??)
>
> * What did you read? Was the documentation adequate for you to get
> started, or was it necessary to read the code? (I realize you had to
> read the code to debug it, I'm just wondering if you needed to in order
> to get started.)
>
Like above said .. i read mainly through the code (especially: Database.*,
API.* and SEF.*)
after getting a rough big-pic .. the Modules-docs and the outdated Wiki
helped as well.
> * Are you working from the release package or from CVS?
i work with cvs-sources
MyLDAPModel.py:
>> def _loadDataFor(self, record, typeName=None):
>>
>> """Define in subclasses to read data into record"""
>>
>> [snip]
>>
>> ## wrong error-msg if no result
>> assert results is not None, ("No LDAP entry found for %s" %
>> record)
>
> I don't understand why you did this. Are you getting a 'None' return
> from the LDAP search? If so, that's a bug in LDAPConnection; please let
> me know. Also, note that getting no results means that the record
> doesn't exist, not that there's an error.
>
you say: assert len(results)<2 "More than one Entry found ..."
which produces an TypeError: len() of unsized object,
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 have a few questions on this:
>> - Did I use the Database-package as you think that it is the right way ?
>
> Pretty much, yes. The main change I would have made, would be that
> test.py would look more like this:
>
> from TW.API import *
>
> class MyApp(SEF.App):
>
> # apps which use transactions will need a Transaction Manager!
> from TW.Database.Transactions import TransactionManager
>
> # by making this an attribute, it is created automatically when
> # we access it:
> from MyDataLayer import MyDatabase
>
> def __init__(self):
> accounts = self.MyDatabase.Accounts # note that I don't call
> anything record = accounts.getItem([('uid','jack')]) # current
> API uses items if record.exists():
> ...etc.
>
> def __init__():
> if __name__=='__main__':
> MyApp() # create and run the application object
>
> setupModule()
>
>
> Notice that the above module is extensible using module inheritance... :)
>
Yes .. I used SEF.App as well for my Tests with wxPython.
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 ??
>
>> - How would this application look like if it would make use of the SEF
>> Model ?
>
> You'd have a module with your domain layer, which would consist primarily
> of Specialists and Elements, e.g.:
>
> class User(SEF.Element):
>
> class userid(SEF.Value):
> ...
>
> ... other features of User element
>
> class Users(SEF.Specialist):
>
> ...domain-specific methods
>
> And then a module with your dispatch (implementation) layer, with the db
> interaction code:
>
> import MyDomainLayer
> __bases__ = MyDomainLayer,
>
> class User:
>
> class userid:
> # implementation to read/write data from records/fields
> def _setData()...
> def _getData()...
>
> etc...
>
>
> class Users:
> elementClass = User
> recordManager = SEF.bindTo('MyDatabase.Accounts')
> requiredType = 'PosixAccount'
> keyField = 'uid'
>
> ...plus db-specific implementations of any needed methods
>
>
> And finally, your main app class would now look more like this:
>
> class MyApp(SEF.App):
>
> from TW.Database.Transactions import TransactionManager
>
> from MyDataLayer import MyDatabase
>
> from MyDispatchLayer import Users
>
> def __init__(self):
> user = self.Users.getItem('jack') # or self.Users['jack']...
> if user is not None:
> ...etc.
>
> Maybe that makes a bit more sense now. As you can see, this will be
> quite a bit easier to develop with than ZPatterns...
>
> I would advise holding off for a bit on digging too deep into the use of
> Elements and Features, however, as I'm about to redo their API entirely.
> After that's done, it should be possible to make some simple "dispatch
> wiring" objects to connect the domain and data layers. These objects
> will be at the field-mapping level, for the most part. E.g., to convert
> record fields to object fields and vice versa. There will also at some
> point be mappers that use a field value as a key to look up in another
> Specialist, and mappers that call a query on a Specialist to retrieve a
> collection of related objects. In general, these mappers will be used in
> the dispatch layer to link Features to their underlying implementation in
> the data layer. But you can always write custom dispatch methods
> directly in Python; the mappers will just be convenient shortcuts for
> specification.
>
I'm really excited too :))
I was a big fan of ZPatterns .. but i need an alternative that is not
bound to Zope w/WebInterface (Zope3 might help in long term).
right now we are designing a Distributed System, that will communicate
through omniORBpy (Corba),use an LDAP-Database for Storage
and wxPython for the UserInterface.
I will watch all your steps ;-) and evaluate Transwarp for this Project.
>
>> I also build a small logger based on TW.API to learn AOP Basics, which i
>> can provide as example as well.
>
> That might be interesting. Are you using metaclasses to do it? My
> theory regarding AOP is that AOP = SOP + metaclasses. TransWarp does SOP
> using module inheritance, so by throwing in Python metaclasses, one
> should be able to do just about anything...
>
so .. I 'only' used SOP .. for my first steps ..
i still work on understanding metaclasses completly ..
the example that i attached, is a Logging Module that makes use of TW's
ability to combine Aspects to achieve different versions of a component
without rewriting the whole module.
Thanks for your reply and push forward this really interesting package.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LoggerExample.tgz
Type: application/x-compressed
Size: 2446 bytes
Desc: not available
Url : http://www.eby-sarna.com/pipermail/peak/attachments/20020319/0221bb71/LoggerExample.bin
More information about the PEAK
mailing list