Integrating GWT widget with vaadin 7 - gwt

I would like to integrate ganttchart GWT widget with vaadin7 application available at https://code.google.com/p/gwtgantt/
I went through some links which explores about integrating GWT widgets with vaadin7 but I don't think I understood.
Also, Do I need to write the connector and other stuff in vaadin to integrate GWT widgets? If yes then I am not quite sure what I will be writing in that.
Does anyone tried the same GWT widget with vaadin7 before?
Any pointers or Sample code will be really appreciated.
Regards,
Azhar

When you are able to use Vaadin 7, this wiki article should help you to get started:
https://vaadin.com/wiki/-/wiki/Main/Integrating%20an%20existing%20GWT%20widget
I believe it handles exactly what you are asking for.

Basically, you need to write the server side code for GWT widgets, and extends the GWT widgets with the communication capability. Here a good project for you to get start with https://github.com/360-Innovations/VaadinSmartGWT
A little example (for Vaadin 6):
1 use eclipse with Vaadin plugin installed to create a Vaadin project then create Vaadin widget unpon that project, Vaadin plugin will generate all the nuts and bolts.
2 write the code
a client class wrapper for GanttChart It implements Paintable interface to communicate with server side
public class VGanttChart extends GanttChart implements Paintable {
public void paint(PaintTarget target) throws PaintException {
}
public void requestRepaint() {
}
... ...
}
for use of each methods, please look at the source comments at Paintable.class
a server side corresponding class:
#ClientWidget(value = VGanttChart.class, loadStyle = LoadStyle.EAGER)
public class GanttChart extends AbstractComponent {
public void paintContent(PaintTarget target) throws PaintException {
}
public void changeVariables(Object source, Map<String, Object> variables) {
}
... ...
}
3 exporting as Vaadin Add-on Package, this is also provided by Vaadin plugin.
4 add the exported jar to your project /WEB-INF/lib, edit your XXXWidgetset.gwt.xml file by adding your add-on's widgetset like this:
<inherits name="package path to your add-on's widgetset def file"/>
if your widgetset def file is myWidgetset.gwt.xml, then the value for attribute name should be "package path to widgetset"/myWidgetset
5 Compile your Widgetset, this is also provided by Vaadin eclipse plugin, after compilation, new set of javascript, css, image resource was generated, now you can use your add-ons via the server side class.

Related

Mule with Jersey dynamic hyperlinks

Using mule 3.7 with a RESTful application and a design which calls for using dynamic links. The Jersey documentation and examples call telling the application about the package to use links, and registering the DeclarativeLinkingFeature class on that package, then use #InjectLink annotation on the field of the class to receive the link.
This is problematic with Mule, and the Application structure is internal to Mule. Without this registration, they #InjectLink has no effect, jersey does not populate the link.
Does anyone have a solution or work around, or even know if Mule has any provisions for implementing Dynamic Linking. We have been able to find no information in the Mule documentation nor examples of Mule applications utilizing this feature. Any hints would be appreciated.
If the feature you want to use is not annotated with #Provider like this one: https://github.com/jersey/jersey/blob/master/incubator/declarative-linking/src/main/java/org/glassfish/jersey/linking/DeclarativeLinkingFeature.java
Create a class that implements Feature and that is annotated as #Provider and then register the features needed:
package com.package.features;
import javax.ws.rs.core.Feature;
import javax.ws.rs.core.FeatureContext;
import javax.ws.rs.ext.Provider;
import org.glassfish.jersey.linking.DeclarativeLinkingFeature;
#Provider
public class MyFeatures implements Feature {
#Override
public boolean configure(FeatureContext context) {
return new DeclarativeLinkingFeature().configure(context);
}
}
Then try to register the feature as so by scanning the package:
<jersey:resources>
<component class="com.package.SomeResource"/>
<jersey:package packageName="com.package.features" />
</jersey:resources>

Vaadin GWT RPC setup?

I've been using smartGWT for a few years but have started looking at Vaadin. I've got the example running but am stumped when it comes to writing the RPC call.
I have a connector:
public class MyComponent2Connector extends AbstractComponentConnector {
And add this to my UI:
#SuppressWarnings("serial")
#Title("StyleSuite Title")
public class MyVaadinUI extends UI
{
private final MyComponent2Connector c = new MyComponent2Connector();
But when I visit the site it says:
java.lang.NoClassDefFoundError:
com/example/suite_local/client/mycomponent2/MyComponent2Connector
The gwt.xml is very plain and just has:
<inherits name="com.vaadin.DefaultWidgetSet" />
I'm clearly doing something wrong - anyone have any pointer for setting this up or have an exampe project?
Vaadin is a server-side framework, which uses GWT in the client-side to render widgets. Normally you only code serve-side stuff and you don't need to worry about RPC or other communcation between server and client because Vaadin takes care of it under the hood. But if you implement your own widget, then you need RPC (or shared state).
Your problem is that you are trying to use a client-side GWT class (MyComponent2Connector) from a server-side class (MyVaadinUI), that doesn't work (as you see). Vaadin 7 mini tutorials is good reading and also Book of Vaadin to understand how Vaadin works.

How to include 3rd party JavaScript libraries in a reusable gwt library/widget?

I'm trying to get my feet wet with GWT to see if migrating will work out. I usually try the more difficult parts first to make sure I can finish the project. The most difficult part of my project(s) is referencing 3rd party JS libs. In this example I'm trying to use PubNub as much of our platform uses it.
What I'd like to do is create a reusable object that can be used in other GWT projects in need of PubNub. I've got a simple little test running successfully (ie, I've got the basics of JNSI working), but my question is -> where do I put the reference to the 3rd party script in order to create the library/module properly?
Right now I just put the reference to the external scripts in the HTML page in the project, but I'm pretty sure this is incorrect from a reusability perspective, as this lib would be used in other projects, each of which would have their own base HTML page.
I tried putting the reference in the gwt.xml file, but this seems to lose the references (ie my test project no longer works as it did when the scripts were in the HTML page)
Do you have any tips on how to include 3rd party libraries in a reusable GWT library/widget?
Here you have an example using client bundles and script injector, you can use either synchronous loading or asynchronous.
When using sync the external js content will be embedded in the application, otherwise it will be include in a different fragment which will be got with an ajax request.
You can put your api in any server and load it with the ScriptInjector.
public class Example {
public static interface MyApiJs extends ClientBundle {
MyApiJs INSTANCE = GWT.create(MyApiJs.class);
#Source("my_api.js")
TextResource sync();
#Source("my_api.js") // Should be in the same domain or configure CORS
ExternalTextResource async();
}
public void loadSync() {
String js = MyApiJs.INSTANCE.sync().getText();
ScriptInjector.fromString(js).inject();
}
public void loadAsync() throws ResourceException {
MyApiJs.INSTANCE.async().getText(new ResourceCallback<TextResource>() {
public void onSuccess(TextResource r) {
String js = r.getText();
ScriptInjector.fromString(js).inject();
}
public void onError(ResourceException e) {
}
});
}
public void loadFromExternalUrl() {
ScriptInjector.fromUrl("http://.../my_api.js").inject();
}
}
[EDITED]
A better approach is to use a new feature in gwtquery 1.4.0 named JsniBundle. We introduced this feature during the GWT.create conferences at San Francisco and Frankfurt.
With this approach you can insert any external javascript (placed in your source tree or hosted in an external host) as a JSNI block. It has many benefits:
Take advantage of GWT jsni validators, obfuscators and optimizers.
Get rid of any jsni java method when the application does not use it.
The syntax is actually easy:
public interface JQueryBundle extends JsniBundle {
#LibrarySource("http://ajax.googleapis.com/ajax/libs/jquery/1.8.1/jquery.min.js")
public void initJQuery();
}
JQueryBundle jQuery = GWT.create(JQueryBundle.class);
jQuery.initJQuery();

Create a GWT RPC Service

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.

Server-side GWT events; alternative to Vaadin

I'm wondering is there a similar framework like Vaadin built on top of GWT which wraps the original GWT components but with server-side only event handling? (I know that Vaadin is built on top of GWT. I'm looking for an alternative solution.)
Vaadin is nice because of it's precompiled nature. I found compile times with GWT horrific the last time i've worked with it. Also it's a bit easier to maintain security if event handling code runs on the server. It would be nice if the standard GWT could be used in a similar way.
I don't think there is another like vaadin. and vaadin is already server-side..
see this http://vaadin.com/learn for more info
Have you seen this? - http://code.google.com/p/gwteventservice/
For server-side alternative, you might take at a look at ZK too.
Notice that its client side is based on jQuery, not GWT. However, you won't notice it at all since they both are server-side solutions and using pure Java.
Event handlers that you normally deal with are in server-side Java code. Consider this:
final Button testButton = new Button("Test Button");
testButton.addListener(new Button.ClickListener()
{
#Override
public void buttonClick(ClickEvent event)
{
mainWindow.showNotification("I am server-side code!");
}
});
As you said, you need to compile GWT code only when adding a custom component to your code. Vaadin's built in components are already compiled and put in the jar file. Although sometimes your IDE might detect your project as a GWT project and try to compile the widgetsets every time you change the code, when you might want to ask it to ignore.
If you look for alternatives to Vaadin you might have a look at Echo2.