"Dynamic" Domain Objects

Hi Rob,

Another solution, better IMHO, would be to use dynamic variables. Let me
explain a bit: If you store your custom variables in a dictionary, then
in Aida you can simply add an entry for each variable.

AObject>>dynamicVariables
   dynamicVariables isNil ifTrue: [self initDynamicVariables].
   ^dynamicVariables

AObject>>initDynamicVariables
  dynamicVariables := Dictionary new

To add a custom variable:

AObject>>addDynamicVariable: aString value: anObject
  self dynamicVariables at: aString put: [anObject]

AObjectApp>>viewMain
       ....
       self observee dynamicVariables do: [:each |
           e addtext: each key, ': ', each value; addBreak].
       ....

FWIW, I *would* use a dictionary. An "aspect" is nothing more than
a reader and a writer with "compatible" names. If your ArbitraryObject
has a dictionary 'properties' as instance variable, you can create
"aspects" of your ArbitraryObject like, e.g.

       name
               ^properties at: #name ifAbsent: ['unnamed']

       name: aString
               properties at: #name put: aString

If you don't care too much for speed, you could also avoid defining all
of these methods by yourself (or explicitly in code) and instead prevent
the MNU exception being raised by implementing (in VW)
Object's method 'doesNotUnderstand: aMessage' which gives you access
to the selector, which in turn would point to the property you're
interested in.

On Thu, 22 May 2008 19:31:28 -0400

"Rob Rothwell" <[hidden email]> wrote:

If I read your mind correctly, medidate about the following sentence:

You don't need to have a method defined for your objects, a receiver
only needs to be able to handle an incoming message.

In many other languages, this distinction does not exist, because of
static type checking and what not else. In Smalltalk (and friends, like
ruby), it's important.

Besides this, you're right. You have to define the accessors somewhere.

However, how about defining a method

       WebFormElement>>dynamicProperty:of:

similar to the way aspect:for: works, but instead of mapping the symbol
to an immediate accessor, use it to access the observee's property
dictionary.

OTOH, it gives me an idea: It would work out of the box, if the object
behind the form is a collection indexable by numbers. Can you put your
dynamic properties into an OrderedCollection and use this collection as
model for a "dynamic property editor" component?

This "aspect adapting" is done with help of AIDAAspectAdaptor (in Aida-Support). It is done by calling yourApp form #registerFormElementsIn: anElement. All form elements are then registered in instvar #fields in yourApp form.

Aspect adaptor is otherwise a pattern from MVC implementation in VisualWorks by which Aida design is heavily influenced anyway. See      
Smalltalk An Introduction to Application Development using VisualWorks, Chapter 29 (page 312): Introduction to Models, Views and Controllers:
http://stephane.ducasse.free.fr/FreeBooks/HopkinsHoran/HopkinsHoran.pdf

I would say that with extending that aspect adapting pattern you can actually achieve your goals easily. Even more because we already have auto converting of values supported already (see WebFormElement class auto type converting)

I would say that with extending that aspect adapting pattern you can actually achieve your goals easily. Even more because we already have auto converting of values supported already (see WebFormElement class auto type converting)