so I defined a Part in my e4 RCP application (inside Application.e4xmi) and assigned it an ID. How can I get a reference to this Part in code. I need a reference to be able to execute a methode on it.
Inject the model service EModelService and the application MApplication and call
modelService.find(id, application);
You can use other parts instead of MApplication but the application should always work.
Related
I am trying to create a plugin which monitors the change in a document.
I am interested in adding a marker in the text editor when the document is changed.
I observed that for the class - IDocumentListener the method documentChanged is getting called whenever there is a change.
However, I am unable to implement this as plugin as this interface does not have an extension point.
Can you help me with extending IDocumentListener ?
It's instructive to look at an existing open-source plugin to see how it does a similar task. Let's look at Bracketeer as an example.
The starting point is a class that implements org.eclipse.core.runtime.Plugin. For plugins that have a UI, it's useful to implement org.eclipse.ui.plugin.AbstractUIPlugin which provides additional functionality. This class is commonly called the "activator", and indeed in Bracketeer it's called Activator. It's registered as the plugin's activator class in the MANIFEST.MF file using a line like:
Bundle-Activator: com.chookapp.org.bracketeer.Activator
The Activator class overrides Plugin.start(), which will be called by the runtime when the plugin is loaded. The overridden start() method sets up a part listener.
The part listener is a class that implements the IPartListener2 interface. In Bracketeer, it's called PartListener. On setup, it calls PlatformUI.getWorkbench() to get a hold of the IWorkbench, and IWorkbench.getWorkbenchWindows() to get a list of currently open windows (at the time the plugin starts). It then registers itself with each window via IWorkbenchWindow.getPartService().addPartListener().
In addition, to handle new windows being opened after the plugin is loaded, PartListener also implements IWindowListener, and registers itself as a window listener via IWorkbench.addWindowListener(). This allows the PartListener to handle new windows opening by overriding IWindowListener.windowOpened(), and register itself as a part listener for the new windows.
As a part listener, PartListener overrides IPartListener2.partActivated() and partOpened() to handle workbench parts (which include editors) being opened or activated. In those methods, it checks whether the part is an IEditorPart; if so, it gets a hold of the editor part's document (see PartListener.getPartDocument()), which is an IDocument.
Finally, having an IDocument, it can register any IDocumentListener it wants via IDocument.addDocumentListener(IDocumentListener).
(There are some details I'm glossing over, such as manually calling partActivated() for every workbench part that's already open at the time the plugin is started. See the Bracketeer code for the full details.)
All of these are public APIs, and none of this requires any extension point to be implemented.
I have an Eclipse RAP 2.3 application with two entry points, say /first and /second.
In the GUI of the first entry point, there is a button with which I would like to open the second entry point in a new browser tab. The event handler of that button is currently
UrlLauncher launcher = RWT.getClient().getService( UrlLauncher.class );
launcher.openURL( "/second");
This already doesn't work when the application is deployed as myapp.war in a Tomcat web server (should then be /myapp/second).
My questions:
What's the best way to determine the URL to open within the event handler?
Do I have to fetch the HttpServletRequest, get the context path and so some string manipulation?
Is it actually safe to call RWT.getRequest() at this point?
Update
According to Rüdiger's comment I can acquire the context path in two different ways.
The first approach is
RWT.getRequest().getContextPath();
where RWT.getRequest() is documented with
This method is not recommended
Secondly, I could obtain it with
ApplicationContextImpl ac = (ApplicationContextImpl) RWT.getApplicationContext();
String contextPath = ac.getServletContext().getContextPath();
where the IDE displays the warning
Discouraged access: The type ApplicationContextImpl is not accessible due to restriction on required library ...\org.eclipse.rap.rwt_2.3.2.20150128-1013.jar
Despite the warning, it still works when deploying a WAR file with OSGi bundles to Tomcat.
So, in both cases there is some kind of warning, which makes the solutions look rather like workarounds.
Using RWT.getRequest() is not recommended because usually RWT would shield you from the lower-level servlet API and certain direct interactions with the request could even interfere with RWTs life cycle and yield funny responses.
While in your case it would be safe to access the ServletContext via RWT.getRequest(), I recommend to use
RWT.getUISession( display ).getHttpSession().getServletContext();
to access the servlet context.
The second approach accesses internal classes that aren't part of the public API and therefore shouldn't be use. The accessed classes may change or be (re)moved in the future without further notice and break your application.
I've been busily getting with the future and migrating an old eclipse 3.7 application over to Eclipse 4 and whilst I'm happy with the application model for porting all the views I have a number of source providers that I am unsure about porting wise. I've been using a few tutorials on Eclipse 4 including this Tutorial from good old Lars but none seem to cover this particular element.
For a small amount of Context my existing application has a few classes extending AbstractSourceProvider that are registered in the org.eclipse.ui.services extension point. My views register themselves as listeners to these services using the ISourceProviderService.getSourceProvider(key) function from the workbench and update themselves if that source fires a sourced changed event. I also have a few providers that reference each other some times too so I'm wondering if this will still work with injection.
What sort of model is used in Eclipse 4?, should I just use the same old extension point? Can these extension point services be injected in to the views in the new cool anotationy way?
What gives?
You can create a service in a number of ways:
Create an instance of your service class and put it in the IEclipseContext. This is often done in an 'Addon':
public class MyAddon
{
#PostConstruct
void postConstruct(IEclipseContext context)
{
MyService myService = ContextInjectionFactory.make(MyService.class, context);
context.put(MyService.class, myService);
}
}
The 'Addon' is declared in the application.e4xmi file.
You could also create the service like this in the LifeCycle class for the RCP.
An OSGi service will automatically be added to the Eclipse context.
You can use a Context Function which uses an OSGi service but doesn't create the actual service until it is needed.
In all cases you reference the service by injection:
#Inject
MyService myService;
Note that injection is only done on objects created by Eclipse from objects described in the application.e4xmi. It is possible to do injection on other objects using ContextInjectionFactory.
I’m trying to create a backend for a homepage with GWT. I created a Google Web Application in Eclipse without sample code and now I would like to add the service, but the developer Google guide doesn’t help me. I’m not sure, where to add the interface and how it exactly works.
If I understand the google documentation correctly, I have to add a module and an entry point class, is that correct? It would be great if you could give me some tips and help how to create a rpc service.
If you create a new GWT project in the Eclipse "New Project" wizard, with "Generate project sample code" checked, it will include a fully functioning RPC service with a sample method, which you can then adapt or copy according to your needs.
Out of memory, don't have eclipse in front of me.
First do create a test project with generated testcode, you can delete it afterward.
Yes you will have to add a module.
Create in client the two interfaces for the async calls, inherit it on server side.
Hope I understood your question right.
I'm not sure what would help you the most. Google developer guide was enough for me (at least when I started using it on version 1.6) to create RPC services for my GWT application.
General APP
Module: is the .gwt.xml file. Yes, you'll need it. The GWT compiler will find it automagically and try to compile all the GWT code (the <source> element will tell which subpackage contains Java code that will be converted to JS). It will tell also which class implements the EntryPoint interface. The onModuleLoad will be the code executed when javascript runs in the client page.
RPC
Well, you should first try UI things and only then, when you're confident enough, try the server thing. Anyway the scheme is:
interface MyService extends RemoteService {
List<String> doSomething(String sample, int other);
}
#RemoteServiceRelativePath("../path/to/servlet") // see later
intercace MyServiceAsync {
void doSomething(String sample, int other, AsyncCallback<List<String>> callback);
}
These are the interfaces. Later is the async one. That's what you'll use from client side. Always calling and passing an implementation of AsyncCallback which will receive (sometime later, you don't know when) the result.
First interface is the syncrhonous one. That is what you need to implement on server. You must inherit from RemoteServiceServlet class (it is an implementation of servlet that already does all the values handling), and implement your interface. GWT code does the rest (almost).
public class ServiceImpl extends RemoteServiceServlet implements MyService
{
// implement the method normally
}
From client you'll need to create the service proxy:
private static MyServiceAsync MY_SERVICE = GWT.create(MyService.class);
Yes. I know it's weird how GWT knows MyserviceAsync and MyService work together. Don't worry about that. It works :)
Just use the service like this:
MY_SERVICE.doSomething("value", 111, new AsyncCallback<List<String>>() {
// note that this code executes some time in the future when response from server is back
public void onSuccess(List<String> result) {
Window.alert("Server answered with " + result.size() + " elements!");
}
public void onFailure(Throwable t) {
Window.alert("Server failed: " + t.getMessage());
}
}
Path to server
You'll have to configure your app to make that servlet implementation listen to URL indicated in #RemoteServiceRelativePath. That's the way client knows where to make the request, and the server knows which servlet attends that request. I'd suggest using:
../my-service.gwt as relative path (GWT module gets published in <ROOT>/module_name
and
configuring your web app to use the servlet for /my-service.gwt
But it's entirely upon your preferences :)
Anyway I think Google tutorials are the best. So please copy&paste. Try&modify until you get to understand the whole thing.
I'm working on a GWT project and I find it very tedious to have to add a function to my servlet, then copy and paste the function signature into my Service interface, then copy and paste it into my ServiceAsync interface and change the return parameter to be a callback. Is there a tool or a setting where I can just add public methods to my class and they can get copied into the other interfaces? Even if its not automatic it would be nice to be able to select specific methods and have them copied automatically.
I'm using eclipse and ideally it would update my interface each time I save implementation since thats when it checks my code and complains that my changes break the interface.
If you add the method to your *Service interface, then Eclipse can auto-generate the method ("Add unimplemented methods...") in your *ServiceImpl servlet, which you can then just fill in. Also, if you've got the Google Eclipse plugin installed, it will underline the new method in your *Service interface and complain that it's not in the *ServiceAsync. It might have a CTRL + 1 option to generate it in that interface as well.
You don't really need a tool. Just factor out the many RPC methods by just one method that takes a Request/Response. all you need to do is create subclasses of Request/Response and you don't need to think about adding new methods in the 2 interfaces.
You can use Google Guice on the server side to map the incomming request to a class handling the call... or you could use a visitor approach to forward the incoming request to the code handling the request (without resorting on a big instanceof construct).
Instantiations WindowBuilder GWT Designer does exactly what you are looking for.
The RemoteService Wizard will create all three files at the same time as well as keep them in sync as you make changes.
http://www.instantiations.com/windowbuilder/gwtdesigner/index.html
FWIW - I am only a user/purchaser of this product. I am not employed or in any other way related to Instantiations.