[TransWarp] peak.model refactoring coming
ueck at net-labs.de
Fri Jan 31 04:29:17 EST 2003
--On Donnerstag, 30. Januar 2003 19:05 -0500 "Phillip J. Eby" <pje at telecommunity.com> wrote:
> * Classifiers (Classifier, DataType, Element, etc.) will know their Features, and be able to list them in various
> subsets and sequences according to specified order (via a feature "priority" attribute) and inheritance order.
fine .. I'm doing such a thing with my gui-model using a metaclass checking for IProperty-Interface of Features
to know the Properties of all of my GuiComponents (ordering is an issue here)
> * Collection and Reference features will support an aggregation kind (e.g. indicating that a feature is composite).
> This is needed to support XMI writing, where the spec requires composite links to be written in a separate batch from
> purely referential links. (It would also be useful for any other algorithm that wants to do recursive traversal of
> contained objects.)
Does that mean, that Tree-like structures then can be represented with Collection/Reference features ?
> * Mapping-style Features. I'd like to make it possible to define a feature that acts like a mapping, in the sense
> that you can store or retrieve items by key (possibly a tuple containing multiple field values). A graph-style
> feature (i.e. multiple items stored under each key) might also be nice. But implementing either of these has some
> interesting interactions with the items below...
yeah .. i've done this as well with transwarp a while ago, but it was a messy hack ...
> * Data manipulation API's and observer hooks. I'd like to (mostly) standardize the ways in which features that are
> collections or mappings can be manipulated, with a goal of making it easier to implement observability of objects'
> features. One tricky bit is the distinction between observing a collection at one end of an association, versus
> observing changes in the link set of the association! The latter is more useful for storage-ish things, and
> validation/business rules, while the former is more useful for GUIs. Whatever the approach, I'd also like to
> minimize overhead due to generating events when nobody is actually listening.
what about a concept of Subscribable and SubscriptionAware like it is basically done in Zope3 ?
> * Validation, constraints, and "business rules". I have some general ideas here, but I think I'm going to have to
> wait until the general refactorings have stabilized more before trying to put hooks for this in. Unfortunately, this
> has a sort of circular depenendency with the previous three items...
How would the be written - python or some sort of OCL ?
> Anyway, I think that about sums it up for now. So steer clear of peak.model for now, and if you have any ideas or
> suggestions about how to sort out any of the open issues above, *please* speak up, as I could use the help. ;)
for my refactoring i copied/modified some of the models modules (structural mainly) .. so i'll need to track your
steps closely :)
any timeframe for this ?
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
email: ueck at net-labs.de
More information about the PEAK