2013/11/21 Paul Webster <[email protected]>
>
> On Thu, Nov 21, 2013 at 10:00 AM, Laurent PETIT <[email protected]>
> wrote:
>>
>> Hello,
>>
>> I'm Laurent Petit, main developer of Counterclockwise, the open source
>> Clojure Plugin for Eclipse.
>
>
> Hi Laurent,
>
> I love your work :-)
Well, thank you :-)
>
> So I'm currently experimenting with an interactive Clojure Console to modify
> the Model on the fly.
>>
>> I've been successful in getting parts from the IEclipseContext, and from
>> them creating parts via MBasicFactory, etc.
>
>
> What version of eclipse are you targetting? If you are targetting Kepler and
> beyond, you can use
> org.eclipse.e4.ui.workbench.modeling.EModelService.createModelElement(Class<T>)
> to create model elements instead of tracking down each individual EMF
> Factory. If you need to support Juno as well, though, then you are correct
> to use the factories.
That's an open question. I'm doing this prospective work for the
development of Counterclockwise itself.
I'm hesitating between letting Eclipse 3 users stuck with the current
stable version, and embrassing Eclipse 4 from now on ... or add
dependencies on Eclipse 4 bundles via a fragment, and have only some
new features that would be usable from Eclipse 4.
I will conduct a Counterclockwise User survey in the next weeks to
know what position to adopt.
> My current problem is the apparent requirement for implementing Handlers to :
>>
>> - have the classes pre-compiled (as opposed to being dynamically created via
>> in-memory bytecode generation as Clojure does). I'm thinking this because of
>> the required "class URI".
>
>
> AFAICT for handlers we use the class URI if the contribution object has not
> yet been instantiated. If you create an instance from your class and call
> MHandler.setObject(theInstance) then set the URI to a string that provides a
> default failover NO-OP class just in case.
>
>
> There's also the runtime EHandlerService system. You can associate an
> handler instance object with a command using
> org.eclipse.e4.core.commands.EHandlerService.activateHandler(String, Object)
> and bypassing the model completely. This might be the way to go since if you
> add MHandler objects to the model, they'll be persisted (and how do you
> re-create the dynamic classes on the next startup? Not impossible, but you'd
> probably have to do extra work to save other information in the model).
That's true.
With Eclipse 3 model, I had created a generic
IExecutableExtension/IExecutableExtensionFactory implementation, which
could then delegate to Clojure factory handlers like this:
<class
class="ccw.util.GenericExecutableExtension">
<parameter
name="factory"
value="ccw.editors.clojure.nrepl-hyperlink-detector/factory">
</parameter>
</class>
Maybe I can simulate this with Eclipse 4 if I create a generic class
and I'm able to inject the E4 Model Element to it so that it can get
the clojure factory from its persistedState map ?
But I fear not: I haven't seen the equivalent of an
IExecutableExtensionFactory in E4. That would be the missing piece.
>>
>> - use @Execute annotation instead of implementing an interface.
>If you're generating the bytes for your classes on the fly, can you simply
>insert the runtime bytes >for @Execute and @CanExecute in front of those
>methods (I'm not that familiar with byte code >generation)?
I have found that I can declare annotation on Clojure types / records,
so maybe there's hope.
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
