[TransWarp] HowTo TreeBased Storage with RecordManagers /
ueck at net-labs.de
Fri May 10 12:19:42 EDT 2002
>> I'm working on my Workflow Engine, that should store it's data in an
> I'm curious why something as complex as an LDAP directory, as opposed to
> something simple, like text files. :)
Why do something simple .. if there is a more complex way to do it :)))
.. no .. this is just some exercise for our Active-Directory-Management
System, where we will need the features described below ...
I already have XML Import/Export and DataStorage in StandaloneZODB right
now. We want to build a system where Workflow's can be modified/extended
dynamically .. so there would be much effort to to this with plain text
>> so i would place Specialists into Elements, and the behaviour of them
>> would depend on the Element's
>> data. I would need to modify the Specialists code to make the
>> keyConstants dynamic .. which should not be too hard i think.
>> Is there a better way to achieve Tree-like storage using TW.Database
>> (especially LDAPModel) ??
> Yes, definitely, if by better you mean "preserves the abstraction of the
> storage layer".
yes .. that was what i meant.
> Set up the specialists in the conventional way using unique keys (either
> generated, or the DN). Define features that refer to collections of
> child items. Add "domain-specific query" methods to the specialists and
> to the LDAPModel that return a list of items which are the child of some
> other item. Have the feature call the Specialist's method to return its
> collection, and the Specialist of course will call the LDAPModel.
> More specifically... Let's say you want to get field definitions for a
> process. Add to your RecordType a method getFieldDefsForProcess() which
> takes the DN or unique ID of the process, and searches for records in the
> LDAP directory. It can then map each result into a Record object, using
> the same techniques as a single-record query does. It then returns a
> collection of Record objects.
> The specialist for field definitions will also have a
> getFieldDefsForProcess() method, which will call the LDAP model and wrap
> the records in Elements, using its cache to ensure that it returns
> existing Elements if available.
> Finally, create a collection feature "dataFields" in the Process element
> class which retrieves its value by calling the specialist's
> getFieldDefsForProcess() method.
> Admittedly, this process probably involves a bit more coding than you had
> in mind. This is mainly because I haven't done any of these myself yet,
> and so I haven't yet added helper methods to Specialists, Features, and
> RecordTypes to do the grunt work of these things for you.
This sound's doable to me .. but I still have one open question:
- Would your solution be the same if i would store data in an RDBMS using
tables with muliple fields as key ?? (e.g.
I really want to build all these Services Storage-independent as fas as
thanks for comments .... (p.s. if there is anything i can help you, getting
closer to 0.2 (except testing .. what I'm doing day by day) , please let me
i'll try to spend some time for this if I'm able to)
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
email: ueck at net-labs.de
More information about the PEAK