Re: [epsilon-dev] Concordance Model object creation

[Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>]

Hi Maarten,

Switching to a static method may not necessarily make the problem
disappear as two different plugins can still call the static method
and the order in which they do this may not be predictable.

Cheers,
Dimitris

On 12 February 2014 10:34, Maarten Bezemer <maarten.bezemer@xxxxxxxxx> wrote:
> Hi Dimitris,
>
> The last provided factory will be used...
> But, the order of plugin activation might be obscure/unknown, so which one is
> activated last is (probably) unknown by the user.
>
> This might be a reason to provide the static method instead of the extension
> point.
>
> Basically it does not make sense use the extension point twice, as this
> switches the IConcordanceModel implementation for newly created objects, while
> still having the existing object that use the old implementation...
>
> Currently, I have added a message/note to the extension point description to
> notify the user about this and that the extension point should be used only
> once (per application).
>
> I could add a warning/log message to notify the user when the extension point
> was used multiple times..?
>
> Cheers,
>   Maarten
>
> On Wednesday 12 February 2014 09:44:37 Dimitris Kolovos wrote:
>> Hi Maarten,
>>
>> What will happen then if two plugins provide extensions to the extension
>> point?
>>
>> Cheers,
>> Dimitris
>>
>> On 11 February 2014 12:26, Maarten Bezemer <maarten.bezemer@xxxxxxxxx>
> wrote:
>> > On Tuesday 11 February 2014 11:15:59 Dimitris Kolovos wrote:
>> >> 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.j
>> > ava
>> >
>> > I indeed noticed the other IModel interface, AFAIK there is also another
>> > Model class. I could also rename the concordance Model class to
>> > ConcordanceModelImpl.
>> >
>> >> >> 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).
>> >
>> > Letting the user choose the IConcordanceModel implementation does not make
>> >
>> > much sense:
>> >  * Without the correct implementation applications (might) break
>> >  (applications>
>> > must choose)
>> >
>> >  * Users do not care what model implementation is used, it just need to
>> >  work.>
>> > So, I do not think that a preference page is the way to go..?
>> >
>> > Another possibility (to circumvent extension points) would be to directly
>> > call a (static) method of the IConcordanceModel factory, to 'configure'
>> > the required model type. But personally I (slightly) like the extension
>> > point better, as this seems more 'natural' and less of a hack.
>> >
>> > Cheers,
>> >
>> >   Maarten
>> >
>> > _______________________________________________
>> > epsilon-dev mailing list
>> > epsilon-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/epsilon-dev
>
> _______________________________________________
> epsilon-dev mailing list
> epsilon-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epsilon-dev



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