Re: [epsilon-dev] Concordance Model object creation

[Maarten Bezemer <maarten.bezemer@xxxxxxxxx>]

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