16 Feb
2006
16 Feb
'06
1:09 a.m.
Thinking more about this, I would actually go for a
:-) It would be nice if
other developers could use your framework to make *any* description they
like, without needing to modify the core framework. Below I outline how it
could be done:
[snip]
Ok, I understand. a might be a good approach indeed, if you actually
want to modify existing behavior/visitors. By dispatching trough your
owner-ship hierarchy this will be easily possible without the need to
modify the core. I only thought about adding an extra attribute as a
class-extension, but now I understand that you need to modify existing
functionality as well ... ;-)
I would not expect that the core framework would need
many modifications in
order to get this working. The added value would be large. Other developers
could simply subclass Description, and use these.
If you think the ownership (or something else that is missing) should
go into the core, you can directly modify the framework and submit to
my repository. If you register at <http://mc.lukas-renggli.ch>, I will
add you as a developer to the Magritte project.
Cheers,
Lukas
On 2/15/06, Runar Jordahl <runar.jordahl(a)gmail.com> wrote:
> Thank you for your answer. Please read my comments below.
>
>
> On 2/14/06, Lukas Renggli <renggli(a)gmail.com> wrote:
> > > a - Subclass ElementDesc and add a Ownership hierarchy.
> > >
> > > b - Add some new property on RelationDesc to store type of ownership.
> >
> > I would go for b, as I don't see a reason why to introduce a new
> > Ownership hierarchy.
>
>
> Thinking more about this, I would actually go for a :-) It would be nice if
> other developers could use your framework to make *any* description they
> like, without needing to modify the core framework. Below I outline how it
> could be done:
>
>
> Page 24 of
> http://www.lukas-renggli.ch/seaside/annecy/Magritte.pdf
> shows how Container has many "children" of type ElementDesc. Now, this
leads
> me to think (or hope) that Magritte can create a Description being type
> "Container" for a single method (Accessor).
>
> Below I give an example of how a description for phone numbers could be
> marked being private using a new description class named
> MAOwnershipDescription. (Note that this class could have been added outside
> the core framework.)
>
> RunarPersonModel class>>descriptionPhoneNumbers
> ^(MAOneToManyRelationDescription auto: 'phoneNumbers'
> label: 'P. Numbers')
> classes: (Array with: RunarPhoneNumber);
> default: Array new;
> yourself) ,
> (RunarOwnershipDescription isPrivate: true)
>
> Just like "ZeroDivide , RangeError" creates an ExceptionSet (at least in
> VisualWorks), the message #, in the statement above will create a Container
> having two children. If this was used, developers could combine various
> descriptors for a *single* property. They could mix the descriptions in the
> core framework with their own, specialized descriptions.
>
> Accessing the descriptions will need specialised methods to get only one (or
> a set of) types. This is similar to how handling exceptions is done. An
> example could be accessing all ElementDesc (and subclasses), and sending
> #validate to them:
>
> aDescption on: ElementDesc do: [:anElementDesc | anElementDes validate]
>
I would not expect that the core framework would need
many modifications in
order to get this working. The added value would be large. Other developers
could simply subclass Description, and use these.
>
>
> Kind regards
>
> Runar Jordahl
>
--
Lukas Renggli
http://www.lukas-renggli.ch