| Re: [e4-dev] Difficulties determining possible methods + arguments |
e4-dev-bounces@xxxxxxxxxxx wrote on 12/18/2009 05:29:13 PM:
> [image removed]
>
> [e4-dev] Difficulties determining possible methods + arguments
>
> Brian de Alwis
>
> to:
>
> e4-dev
>
> 12/18/2009 05:32 PM
>
> Sent by:
>
> e4-dev-bounces@xxxxxxxxxxx
>
> Please respond to E4 Project developer mailing list
>
> 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" deleted by Boris Bokowski/Ottawa/IBM]
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev