Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epsilon-dev] Concordance Model object creation

Hi Maarten,

Apologies for the radio silence. Please see comments below.

On 10 February 2014 12:39, Maarten Bezemer <maarten.bezemer@xxxxxxxxx> wrote:
> Hello,
>
> As no one responded, I suppose I'll commit this (soon). We can always change
> some things later, if they could have been implemented better, I suppose.
>
> Cheers,
>   Maarten
>
> On Thursday 30 January 2014 14:06:03 you wrote:
>> Hello Louis (and others),
>>
>> As you might know I have some changes lines up for Concordance. Especially
>> for the Model object.
>> My application uses the EMF EditingDomain to share the model between
>> multiple tools. And I feel that concordance should use them as well, so by
>> performing some changes to the Model class (and classes using the Model
>> class), the EditingDomain implementation can be dynamically added to
>> concordance.
>>
>>
>> First to add an interface describing all Model methods, named IModel. This
>> is nothing spectacular. See
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=419001 BTW, I assume that
>> IModel is a good enough name for the interface?
>>

To avoid confusion I'd suggest calling it an IConcoranceModel instead
as there's already an IModel in Epsilon

http://dev.eclipse.org/svnroot/modeling/org.eclipse.epsilon/trunk/plugins/org.eclipse.epsilon.eol.engine/src/org/eclipse/epsilon/eol/models/IModel.java

>>
>> Next thing is to be able (as an user of Epsilon/Concordance) to provide a
>> custom implementation of the Model interface.
>> Currently, I used an extension point to register my custom factory
>> (implementing a new IModelFactory interface) which creates my custom
>> implementation of IModel.
>>
>> This works nicely and is least intrusive I think.
>> By default the ModelFactory implementation is used creating the
>> default/current Model objects. So nothing changes for existing users.
>>
>> But, (mis)using an extension point to 'configure' the ModelFactory seems
>> wrong? Instead a public static method could be called to register the
>> factory, although this does not seem very nice as well and might result in
>> the default factory being used until the call is made (which might also be
>> the case using extension points...)
>>

One option would be to introduce a preference page that would allow
users to select the model factory they'd like to use (extenders would
still contribute model factories through the extension point).

>> Any additional thoughts on this, or should I just commit my current
>> implementation using the extension points?
>>
>> Cheers,
>>   Maarten
>
> _______________________________________________
> epsilon-dev mailing list
> epsilon-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epsilon-dev

Cheers,
Dimitris

-- 
Dr Dimitris Kolovos
Lecturer in Enterprise Systems
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos

EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm


Back to the top