Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[e4-dev] Difficulties determining possible methods + arguments

Hello everybody.  I've been playing around with e4 (0.9, M1, and M2) on a project and have been lurking on this list in that time.  I'm building an app with several modes which I plan to implement using perspectives.  I thought I'd give some feedback.

First, I should say that I like e4.  I considered at one point to switching back to building my project as an RCP app, but didn't.

At a high-level, I'm finding it hard to tell where e4 is trying to lead me.  It seems like e4 is a reinvention of everything from E3.x, and so it's not as clear to me what parts of the framework I should continue to use as is.  I've gone back and looked over the e4 whitepaper and the web pages, and remain a bit puzzled.  A transition guide would be useful, even if it only said: these bits are the same, the rest you'll need to relearn. I wish I had written down the questions that have come to me over time, but I do remember an epiphany when I realized that e4 is mostly changing the workbench model, and not involving the platform (mostly), SWT, JFace, etc.

The questions I still have are:

  * what is the relationship between the Modelled UI, XWT, and the Toolkit Model?  I think it's something like: XWT is the part designer to fit within the Modelled UI.  I'm still not certain where TM fits in.

  * should we be moving towards using OSGi declarative services?

  * what is the story with preferences?  Especially w.r.t. UI preferences such as fonts, styling, etc.
  

In terms of development, I've mostly restricted myself to fairly basic UI stuff as I've been focusing on the underlying infrastructure for my own project.  So I can't provide feedback on the other components like SFS, XWT, etc.


If I have a peeve with e4, it would have to do with the use of dependency injection and the move away from standard interfaces.  Although the use of dependency injection is admittedly powerful, it's exceedingly difficult to figure out what API-ish items can/need to be implemented.  In implementing a command handler, there's no single place (at least that I've found) where I can see the possible methods or the possible injectable argument. 

With e4's moving away from compulsory interfaces, discovery is now a pain: it's hard to figure out how to find various necessary bits.  How does a handler implementation find its corresponding tool bar item to change the item's appearance?  With E3.x, I can follow the call chains; with e4, I'm left to combing through the photo and contacts demo and hoping to find a relevant example.

[There also seems to be some inconsistencies with the use of annotations for marking injections: some methods and constructors require an @Inject (I believe predominantly on contributed classes for MParts) but not on others (handler implementations, I believe).]

I wondered if a possible solution might be to provide an equivalent to Smalltalk-like protocols by providing a @noimplement interface for each model class type that describes all the possible methods, with javadoc explaining the possible injections that can be provided.  For example:

/**
 * Command handlers in e4 provide the implementation 
 * to enact a command.  As there may be multiple handlers
 * for a command, the handler is the first handler from the list
 * responding with 'true' to {@link #canExecute()}.
 * Injectable fields include:
 * <ul>
 * <li> ...
 * </ul>
 */
public interface e4CommandHandler {
	/**
	 * <p>Return true if this command can execute at this point.
	 * <p>Optional injectable arguments include:</p>
	 * <ul>
	 * <li> etc
	 * </ul>
	 */
	void canExecute();

	/**
	 * <p>Cause the command to be executed.  This method may return an
	 * object that will be used as the result of executing the command.</p>
	 * <p>Optional injectable arguments include:</p>
	 * <ul>
	 * <li> {@link IEclipseContext} the e4 context
	 * <li> The active selection type (e.g., <code>Contact</code> in
	 * 		the <code>org.eclipse.e4.demo.contacts</code> example). 
	 * <li> {@link IProgressMonitor} to obtain a progress monitor
	 * <li> {@link IExceptionHandler} to obtain the exception handler
	 * <li> {@link IWorkbench} for the workbench instance
	 * <li> {@link IWorkspace} for the active workspace
	 * <li> {@link Shell} for the active window shell
	 * <li> {@link MApplication} for the current application
	 * <li> {@link IPresentationEngine} for the rendering engine
	 * <li> {@link IStylingEngine} for the rendering engine
	 * <li> {@link MApplication} for the current application
	 * <li> The context for a named element (e.g.,
	 *     <code>@Named(IServiceConstants.ACTIVE_PART) MContext context</code>
	 * </ul>
	 */
	Object execute();
}

Hope this helps in some way.

Brian.

--
On bike helmets: "If you think your hair is more important than your brain, you're probably right."  (B. J. Wawrykow)

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Back to the top