Re: [e4-dev] Difficulties determining possible methods + arguments

[Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>]

Apologies for sending an email without content, this was done without me clicking anything I believe. I also thought I had sent a reply to Brian's email in December but cannot find it. I'll try again tomorrow... :-)

Boris

Boris Bokowski---01/06/2010 12:00:29 PM---e4-dev-bounces@xxxxxxxxxxx wrote on 12/18/2009 05:29:13 PM: > [image removed]

From:	Boris Bokowski/Ottawa/IBM@IBMCA
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date:	01/06/2010 12:00 PM
Subject:	Re: [e4-dev] Difficulties determining possible methods + arguments
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

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_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev