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)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
