[TransWarp] peak.model refactoring coming

[Ulrich Eck]

--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 ?

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