Re: [epsilon-dev] Concordance Model object creation

[Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>]

Hi Maarten,

I think I'd prefer the extension point.

Cheers,
Dimitris

On 12 February 2014 14:05, Maarten Bezemer <maarten.bezemer@xxxxxxxxx> wrote:
> Hi,
>
> True...
>
> It could check if it has been called earlier and throw an exception, so the
> developer is informed of the problem.
> Basically this means that the used plugins are incompatible, as they both
> required their own IConcordanceModel implementation, which is not possible as
> one *must* be chosen.
> In such a situation, other things are probably clashing between these two
> plugins as well, since the IConcordanceModel implementation is used when the
> models need to be managed a certain way (e.g. by using the EditingDomain(s) of
> the application).
>
> What would be your preference? using an extension point or the static method?
> (Both could throw an exception when used twice)
>
> Cheers,
>   Maarten
>
> On Wednesday 12 February 2014 11:46:48 Dimitris Kolovos wrote:
>> 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/plugi
>> >> > ns/
>> >> > org.eclipse.epsilon.eol.engine/src/org/eclipse/epsilon/eol/models/IMode
>> >> > l.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
>
> _______________________________________________
> 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