Re: [epsilon-dev] Concordance Model object creation

[Maarten Bezemer <maarten.bezemer@xxxxxxxxx>]

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