We really inundated JavaOne with Errai this past year. Here's a collection of booth talks we gave at the conference:
Errai UI
Errai JPA and JAX-RS
Errai CDI (In the Browser!)
Errai UI
Errai JPA and JAX-RS
Errai: The browser as a platform
Tuesday, March 12, 2013
Sunday, February 17, 2013
Errai JavaOne talk on YouTube
If you haven't seen our JavaOne talk on Errai yet. Here's another chance. All JavaOne videos have been posted to YouTube. This means you can sync it to your phone or tablet for offline viewing or embed it in your own blog *hint* *hint*!
Taming the Spaghetti: Rich Web Applications with Errai
In this talk, you will learn
- how to create and send push messages (CDI events) from server to client and back
- how to use the same JPA entities in the browser and on the server
- how to create typesafe, refactorable JAX-RS clients in the browser
- and about the underlying technologies within Errai that make all this possible
Friday, February 15, 2013
RPC batching
Today's spotlight is on yet another new feature in Errai 3: RPC batching.
Only after sendBatch is called will the remote methods get executed. An additional RemoteCallback can be provided to the sendBatch call which will be invoked when all remote calls have completed in success. Consequently, an additional ErrorCallback can be provided which will get executed for all remote calls that have completed in failure.
The credits for inspiring this feature go to our invaluable community member Josh Blinick. The API might still change as we're looking for feedback! If you have ideas or any feedback, please comment. Here's the link to the JIRA.
GWT and Errai shine in big web applications that implement complex use cases. These use cases often require multiple interactions with the server. RPC batching allows for batched invocations of remote methods that will be executed using a single server round-trip. This is useful for reducing the number of simultaneous HTTP connections and at the same time allows for reusing and combining fine-grained remote services.
Errai offers a lightweight and boilerplate-free RPC mechanism. All details can be found here. Simply inject a BatchCaller instead of a Caller<T> to make use of batched remote procedure calls. The rest of the API should be familiar if you already use Errai. Here's an example:
Only after sendBatch is called will the remote methods get executed. An additional RemoteCallback can be provided to the sendBatch call which will be invoked when all remote calls have completed in success. Consequently, an additional ErrorCallback can be provided which will get executed for all remote calls that have completed in failure.
The credits for inspiring this feature go to our invaluable community member Josh Blinick. The API might still change as we're looking for feedback! If you have ideas or any feedback, please comment. Here's the link to the JIRA.
Monday, February 11, 2013
Style bindings
Yet another feature finds its way into the 3.0 branch today. And that feature is called style bindings; a feature designed to make your Errai UI-based apps even easier to work with.
When developing moderately-complex web applications with Errai, you may find yourself needing to do quite a bit of programmatic style changes. A common case being: showing or enabling controls only if a user has the necessary permissions to use them. One part of the problem is securing those features from being used, and the other part -- which is an important usability consideration -- is communicating that state to the user.
That's where style bindings come in.
Let's start with the example case I just described. We have a control that we only want to be visible if the user is an admin. So the first thing we do is create a style binding annotation.
That was pretty simple. All we did was create an annotation named Admin, and annotate it with the new @StyleBinding annotation.
This now means that @Admin is a style binding. Let's see how we can apply it.
Consider the following Errai UI template class
Here we have a contrived example of a button that deletes something. In this case, if the user is not an admin, which we're checking using a call to SessionManager.isAdmin(), we hide the button from view.
Although, we can potentially refactor this to reduce code re-use. If we're using the @Admin binding throughout our application, we can actually move the applyAdminStyling() method to a common location. Let's move it to the SessionManager.
When we remove that method from our Errai UI component, we get a far more elegant set of code:
Now, when we apply the @Admin rule to any Errai UI @DataField, we automatically inherit this functionality.
The additional bonus comes when using this in conjunction with Errai Databinding. Any Errai UI component which uses @AutoBound, will get live updating of the style rules for free, anytime the model changes. Allowing dynamic styling based on user input and other state changes.
As always, if you're interested, checkout Errai 3.0-SNAPSHOT if you're ready to try and get dirty with the latest and greatest features
When developing moderately-complex web applications with Errai, you may find yourself needing to do quite a bit of programmatic style changes. A common case being: showing or enabling controls only if a user has the necessary permissions to use them. One part of the problem is securing those features from being used, and the other part -- which is an important usability consideration -- is communicating that state to the user.
That's where style bindings come in.
Let's start with the example case I just described. We have a control that we only want to be visible if the user is an admin. So the first thing we do is create a style binding annotation.
That was pretty simple. All we did was create an annotation named Admin, and annotate it with the new @StyleBinding annotation.
This now means that @Admin is a style binding. Let's see how we can apply it.
Consider the following Errai UI template class
Here we have a contrived example of a button that deletes something. In this case, if the user is not an admin, which we're checking using a call to SessionManager.isAdmin(), we hide the button from view.
Although, we can potentially refactor this to reduce code re-use. If we're using the @Admin binding throughout our application, we can actually move the applyAdminStyling() method to a common location. Let's move it to the SessionManager.
When we remove that method from our Errai UI component, we get a far more elegant set of code:
Now, when we apply the @Admin rule to any Errai UI @DataField, we automatically inherit this functionality.
The additional bonus comes when using this in conjunction with Errai Databinding. Any Errai UI component which uses @AutoBound, will get live updating of the style rules for free, anytime the model changes. Allowing dynamic styling based on user input and other state changes.
As always, if you're interested, checkout Errai 3.0-SNAPSHOT if you're ready to try and get dirty with the latest and greatest features
Saturday, February 2, 2013
Work those cores!
A brand new feature to find it into the 3.0 branch these past few days is our new generator parallelization system. That's right; all the code generating magic of Errai can now be split across those idle cores of your computer to greatly increase compile and development mode speed.
Right now only three generators support this parallelization: IOC/CDI, Marshalling and RPC. But we'll get them all plugged in soon.
The new approach also reduces the amount of redundant work that was previously done as each generator ran. On my development laptop, we're seeing improvements in code generation time of up to 60%.
This optimization also comes on the heels of some fixes to the caching behaviour in our internal class scanning API which should also greatly benefit devmode speed.
ErraiBus Improvements
The performance optimization train is in full swing all around the framework. The new ErraiBus V3 Protocol is now fully implemented and working in the 3.0 branch. It provides a new ultra-lightweight association protocol (apps load faster), less management traffic (less chatty), and a streamlined RPC protocol (less call latency).
Another feature under development is ErraiBus support for SSE (Server-Sent Events) which will also significantly reduce bandwidth usage on the bus.
SSE is essentially a standardization of COMET built right into the browser. It allows servers to keep a port open and return a stream of responses without the needless overhead of repeated GET and response headers.
Look for this feature showing up in the coming weeks.
Right now only three generators support this parallelization: IOC/CDI, Marshalling and RPC. But we'll get them all plugged in soon.
The new approach also reduces the amount of redundant work that was previously done as each generator ran. On my development laptop, we're seeing improvements in code generation time of up to 60%.
This optimization also comes on the heels of some fixes to the caching behaviour in our internal class scanning API which should also greatly benefit devmode speed.
ErraiBus Improvements
The performance optimization train is in full swing all around the framework. The new ErraiBus V3 Protocol is now fully implemented and working in the 3.0 branch. It provides a new ultra-lightweight association protocol (apps load faster), less management traffic (less chatty), and a streamlined RPC protocol (less call latency).
Another feature under development is ErraiBus support for SSE (Server-Sent Events) which will also significantly reduce bandwidth usage on the bus.
SSE is essentially a standardization of COMET built right into the browser. It allows servers to keep a port open and return a stream of responses without the needless overhead of repeated GET and response headers.
Look for this feature showing up in the coming weeks.
