Thursday, November 29, 2012

Polyglot Widgets

JBoss Developer Framework

The JBoss JDF project shows Java EE developers how to build state-of-the-art applications using the JBoss implementations of the Java EE stack. Specifically, the JDF View Frameworks section identifies a number of alternative approaches one can take when developing the view layer of your application. We in the RichFaces project have been working towards better supporting this effort by redesigning our JSF component architecture to allow the javascript part of our components (what we call our “widgets”) to be used independent of JSF, either in a standalone manner or coupled with another web framework.

By isolating the client-behaviour into widgets, we are able to achieve both a faster turnaround on new JSF component development, while at the same time enabling users to achieve a uniform look and feel in their heterogeneous application environments. To demonstrate the impact of this, I’ve prepared a demo application that demonstrates using our standalone javascript widgets in JSF with RichFaces, GWT with Errai, and a plain HTML 5 page with Aerogear.

Polyglot widgets demo

polyglot-widgets

The polyglot-widgets demo takes the RichFaces Sandbox pickList component and builds a GWT and plain HTML5 application using the standalone javascript pickList widget.

Some key points of the demo to call out:

Consistent L&F

Imagine writing “polyglot” web applications with both a consistent Look & Feel, and access to the rich set of enterprise-grade widgets that you’ve come to expect from the RichFaces project. In the demo, the same RichFaces Sandbox pickList widget is used in a JSF, GWT and HTML 5 application. The widget and the demo pages themselves use the Bootstrap project for styling, which is what enables us to achieve a consistent L&F across the pages backed by different web technologies. This common L&F is taken one step further to deliver a consistent user experience by using the same javascript widget implementation across all the demo pages.

CDI Programming model

In the demo, we use the pickList component to make a selection on one of the demo pages, then click the submit button. On navigation to one of the other demo pages, you’ll notice the state persisted. This demonstrates how we can leverage CDI to provide a common programming model across all our web frameworks.

Integrated Ajax Push

Open each page of the demo in a separate window to witness selection updates synchronizing the pages in real time. Taking advantage of RichFaces push, the Errai CDI bus, and HTML 5 Server-Sent-Events (via the Atmosphere project) in each of the respective frameworks provides incredible power in keeping our “polyglot” web-apps in a coherent state.

Screencast

I created a screencast of the demo, to make it easier to see the above points in action. Watch the screencast below, then head off to play with the demo yourself. Even better, fork the demo on github, and see what cool things you can do with it.

Next Steps…

I put this demo together as a proof-of-concept to help me illustrate what I mean when I talk about “standalone widgets” and polyglot/poly-framework applications. The RichFaces team will ramp up development on these new standalone widgets as we wrap up our RichFaces 4.3 effort and shift gears into RichFaces 5. So stay tuned for further development in this area!


Tuesday, October 30, 2012

RichFaces 4.3.0.M2 Release Announcement

RichFaces

The second milestone release of RichFaces 4.3 (4.3.0.M2) is now available. Another significant milestone for the project, this release incorporates a number of new features, bug fixes, and component upgrades. Read on for some highlights of the release, or go straight to the Release Notes for a complete list of what’s been addressed.

To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.3.0.20121024-M2. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Community involvement

I’d again like to thank RichFaces community members for their contributions to this release. In total there are 7 community members who have contributed this milestone release! This is a number that makes me incredibly proud to share, and demonstrates how the RichFaces community is truly thriving. So together, as a community, let’s have a collective shout-out to:

Keep the pull requests coming guys!

UIRepeat support in Toggle Panels

With the resolution of RF-9443, the RichFaces increases support for the <a4j:repeat> component to dynamically define repeating child panels of components that extend AbstractTogglePanel class. This includes:

While it has always been possible to use the JSTL <c:forEach> tag to define child panel components, this did not meet all use cases, as the JSTL tags are evaluated before the component tree is built, and hence don’t play nice when the underlying data model changes without performing a full page reload. With the new support for defining child panels using the <a4j:repeat> syntax, evaluation is deferred until render time, making the child panels “truly dynamic”.

The implementation of this leans heavily on the RichFaces UIDataAdaptor, which forms the basis for all repeating RichFaces components. stay tuned for a blog demonstrating <a4j:repeat> usage to dynamically define repeating toggle panel items, and be sure to test this feature out in this milestone release, to be sure the feature meets your requirements for dynamic repeating panel components – let us know if it doesn’t!

Note: this feature does not yet support the use of the <a4j:repeat> tag for defining dynamic columns. That issue is being addressed as part of RF-7882.

CDK incremental build

With this second 4.3.0 milestone, we’ve carried on with some of the CDK improvements we saw in our first milestone. This time we’ve added support for incremental build with the RichFaces CDK, greatly reducing the time it takes to build RichFaces components, as the CDK now only processes CDK templates and resources that have been touched since the previous build.

Making use of the incremental build for the “RichFaces Components” project reduces the project build time from 2m18s to 1m00s — a 56% decrease in build time. A further reduction in project build time is seen with the proposed new build structure, where we do away with the independent artifacts, and their associated assembly steps.

This is an important achievement, as reducing the turnaround time from IDE to browser improves developer productivity, and let’s RichFaces developer’s more quickly and efficiently deliver bug fixes and new features.

Component Upgrades

A number of libraries within the project have been upgraded in this milestone. This includes upgrading:

In addition, upstream changes in Mojarra required some significant changes to jsf-test, and the jQuery upgrade necessitated upgrading some of the jsf-test libraries as well:

While we currently use jsf-test to mock the faces context and execute our RichFaces unit tests, I’ll take this opportunity to plug the Arquillian extensions Graphene and Warp which the RichFaces Dev and QE teams are developing to allow us to take advantage of the Arquillian revolution, and unit test our components in real containers. Head on over to the Arquillian site to learn more about using these extensions to test your own JSF/RichFaces applications.

Noteworthy fixes

In addition to the above features, RichFaces 4.3.0.M2 delivers a number of additional features and bug fixes, including the fixes released with RichFaces 4.2.3.Final. Some noteworthy fixes include:

RF-12360
The onchange behaviour of the <rich:pickList> has been changed to fire whenever the picked value list changes, rather than waiting until the component loses focus.
RF-12397
A MyFaces profile has been added to the RichFaces showcase build
RF-12457
The <rich:validator> has two new attributes onvalid and oninvalid that can be used to trigger a javascript callback when validation succeeds/fails. Thanks for this addition Bernard!
RF-12492
A visual improvement, the <rich:inputNumberSlider> gets a new handle, in the style of the progress bar.

Moving forward

As per the RichFaces road map, we have one final milestone scheduled for RichFaces 4.3. Work has already begun on RichFaces 4.3.0.M3 after which there will be a CR1 release, followed (hopefully!) by the Final release. Then it’s on to RichFaces 5 where we will implement the new RichFaces build. Tune in to the RichFaces developer forum, where we will soon start the discussion and planning of what will be in RichFaces 5 in addition to this build re-structure.


Thursday, October 18, 2012

RichFaces 4.2.3.Final Release Announcement

RichFaces

RichFaces 4.2.3.Final has been released. This Final release is a re-tag of the 4.2.3.CR1 release as no blocking issues were found by either our QE team, nor by the community.

The RichFaces 4.2.3.Final release is purely a bug-fix release, with a focus on compatibility between RichFaces and the JBoss Portlet Bridge. I’ll refer you to the RichFaces 4.2.3.CR1 release blog for details of the release, with a special highlight paid to the contributions from the JBoss Portal Bridge team, and contributions from community members.

To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.2.3.Final. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Release Notes:

To re-cap, the changes in the 4.2.3.Final release compared to the 4.2.2.Final release include:

Bug

  • [RF-10758] – Input fields in popupPanel lose focus
  • [RF-10980] – Impossible to set tabindex of input inside rich:popupPanel
  • [RF-11051] – a4j.version does not work
  • [RF-11104] – rich:inputNumberSlider slider position is affected by css position attribute of containing element
  • [RF-12113] – rich:inputNumberSpinner minValue and maxValue being ignored after second request
  • [RF-12114] – Richfaces 4.2 rich:autocomplete don't fire ajax on blur event
  • [RF-12221] – rich:orderingList: fix VDL-DOC of @listHeight, @maxListHeight, @minListHeight, @listWidth
  • [RF-12256] – DragAndDrop + position: absolute results in broken positioning
  • [RF-12273] – rich:fileUpload does not work in portlets because it does not utilize javax.faces.encodedURL for the XmlHttpRequest URL
  • [RF-12424] – Showcase contains Servlet specific code
  • [RF-12425] – Showcase fails to load SyntaxHighlighter scripts when Require.js is present
  • [RF-12476] – Resource Name in mapping for two menu images is incorrect

Enhancement

  • [RF-12343] – Problem when saving form with rich picklist inside composite component

This is very much a community driven release. Thanks guys, you rock!

Stay Tuned for 4.3.0.M2

The QA process for the 4.3.0.M2 release is about to begin, with a release as soon as QA is done. So stay tuned, as there is lots more great stuff to come!


Friday, October 12, 2012

RichFaces Bootstrap Quickstart

I’m excited about the buzz the RichFaces Bootstrap sandbox initiative is generating. It’s also exciting to see other projects offer a bootstrap style/theme. This can only help inter-op and component compatibility, marking life easier for all JSF developers. This post is meant to help those looking to build a custom application using the RichFaces Bootstrap components.

Along with the new approach we are taking in the development of these new components, the RichFaces project is incorporating a new LESS based approach to style/themes. With LESS we can take advantage of dynamic features such as variables, mixins, operations and functions. However, this requires us to make some changes to how we serve resources and is still in active development as we work through various prototypes in the RichFaces Sandbox.

The RichFaces Bootstrap Quickstart

We’ve added a RichFaces Bootstrap Quickstart project that you can use to build an application to test-drive these new components. This quickstart application has the sole intention of being a starting point, and is much simpler to grok than the demo application we’ve been providing that is more of a component showcase. As an added bonus, creating this quickstart served as a good driver to simplify the RichFaces bootstrap-ui project, making it easier to consume. Simplicity for-the-win!

Rest assured the complexity of this approach will ultimately disappear and usage of these components will become transparent as we move out of the prototyping stage and include these components in “RichFaces proper”.

A walk-through the Quickstart

The RichFaces Bootstrap quickstart is a maven project available on github in the RichFaces Sandbox repository. It includes the appropriate configuration in the web.xml deployment descriptor that, when coupled with a resource mapping file, allows us to activate the client-side LESS styling of the RichFaces Bootstrap components.

If you are not interested in working with the client-side LESS styling, but rather the CSS compiled at build time, then simply build the quickstart project as is:

mvn clean install

However, should you wish to work with the LESS approach to styling, change the org.richfaces.clientSideStyle context-param in the web.xml to true:

<context-param>
    <param-name>org.richfaces.clientSideStyle</param-name>
    <param-value>true</param-value>
    <!-- Note this will be overridden by PROJECT_STAGE = Production -->
</context-param>

You can then include your own .less files and they will be converted to CSS on the client-side with the provided less.js library. You will then want to convert your LESS files to CSS (at build time) when you go to production, but that will be the topic of another blog (or look at how we’ve done it with wro4j in the bootstrap-ui project).

We’re planning on pushing heavily on LESS/JSF integration in the coming few months, looking to simplify the process, and enable you to take advantage of the many LESS/Bootstrap themes available and apply them to your application. We’ll keep the “README” of the quickstart up-to-date with any changes required to consume the components in your own projects.

Disclaimer: RichFaces Bootstrap is a Sandbox project, and not yet meant for production use. API’s and component implementations will change.

Wednesday, October 10, 2012

RichFaces 4.2.3.CR1 Release Announcement

RichFaces

I am happy to announce that the first candidate release of RichFaces 4.2.3 (4.2.3.CR1) is now available. This is purely a bug-fix release, with a focus on compatibility between RichFaces and the JBoss Portlet Bridge.

To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.2.3.CR1. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Portlet Bridge Fixes

RichFaces aims to be a container agnostic project, working in Servlet containers, Java EE implementations, and Portals, all from multiple vendors. Of course keeping up with bugs and fixes across all these deployment environments is a lot of work, so we naturally tend to focus our efforts on certain specific environments. As such, nothing makes us happier then receiving github pull requests addressing compatibility issues between RichFaces and one of these deployment containers.

This is precisely what Ken Finnigan of the Portal Bridge team has done, identifying and resolving a number of issues with RichFaces when running in a Portlet environment. Unfortunately a number of servlet specific references leaked through in some of our implementations, but Ken has done an excellent job rounding these up, and replacing them with the appropriate JSF abstraction, ensuring RichFaces components work equally well in servlet and portlet environments. Great job Ken!

Community Contributions

I’d also like to call out , Bernard Labno, Christian Kaltepoth, and Luca Nardelli for the bugs they fixed and submitted as github pull requests. RichFaces is a very much a community project, and it’s in part contributions like these that keep the project healthy and moving forward. Thanks guys — and keep those pull requests coming!

Release Notes:

Specific issues resolved with this release include:

Bug

  • [RF-10758] – Input fields in popupPanel lose focus
  • [RF-10980] – Impossible to set tabindex of input inside rich:popupPanel
  • [RF-11051] – a4j.version does not work
  • [RF-11104] – rich:inputNumberSlider slider position is affected by css position attribute of containing element
  • [RF-12113] – rich:inputNumberSpinner minValue and maxValue being ignored after second request
  • [RF-12114] – Richfaces 4.2 rich:autocomplete don't fire ajax on blur event
  • [RF-12221] – rich:orderingList: fix VDL-DOC of @listHeight, @maxListHeight, @minListHeight, @listWidth
  • [RF-12256] – DragAndDrop + position: absolute results in broken positioning
  • [RF-12273] – rich:fileUpload does not work in portlets because it does not utilize javax.faces.encodedURL for the XmlHttpRequest URL
  • [RF-12424] – Showcase contains Servlet specific code
  • [RF-12425] – Showcase fails to load SyntaxHighlighter scripts when Require.js is present
  • [RF-12476] – Resource Name in mapping for two menu images is incorrect

Enhancement

  • [RF-12343] – Problem when saving form with rich picklist inside composite component

What’s next?

Be sure to take this candidate release for a spin, and report back any regressions. We are expecting the 4.2.3.Final release to simply be a re-tag of the CR1 release, barring any unforeseen blockers.

In the mean time we are hard at work on our the 4.3 release train, and are working on having a 4.3.0.M2 release available hot-on-the-heels of this 4.2.3 release.


Wednesday, October 10, 2012

Back From Java One

Last week I was at Java One, where I can easily say I thoroughly enjoyed the week of chaos that is JavaOne. The quality of people and content was truly astounding – I met a number of people I’d been wanting to meet for a while, and also spent some time getting to know more fellow JBoss developers. I spent the bulk of my time preparing my presentations, leaving little time to attend sessions. Hopefully this extra effort paid off ;)

JBoss Booth Sessions.

The first talk I gave was an impromptu one, filling in a last-minute vacancy in the schedule. I delivered a trimmed down version of the Mobile JSF talk I gave at JBW and JAX last June/July. The talk was well received, “trapping” a fair amount of traffic around the booth, and resulting in some interesting discussion at the end of the session. The slides from this session are available, and the session was filmed – I’ll follow up with links when the videos are available.

My second talk was also a booth session. This time I presented on Leveraging jQuery plugins to build JSF components. This talk demonstrates how to build custom JSF components using first the JSF 2 composite component feature, then the RichFaces CDK. Unfortunately this session was less well attended, which I think had a lot to do with the early morning-timing.

JavaOne Session

Hot dog at Pearl Jam party
Chili dog served at the JavaOne Appreciation Event

Finally I presented a JavaOne session with Lincoln Baxter III on the topic of Testing JSF Applications with Arquillian and Selenium. This slide was recorded, and the videos is available for online viewing. Additionally I’ve posted the slides on my website, and the source code used for the demos is available on github.

The JavaOne session went really well. I was not expecting the audience to be so unfamiliar with Arquillian, given how many times Arquillian was presented at JavaOne. As such we spent more time going over the Arquillian Basics, and this cut quite a bit into the time I wanted to spend on the JSF specific Arquillian Warp slides near the end of the presentation. Nevertheless, the message was well received, and we’ve successfully seeded the brains of a number of JSF developers with thoughts of testing with Arquillian.

Of course one can’t mention JavaOne without talking about the Oracle Appreciation Event. Words cannot express how supremely awesome it was to see Pearl Jam perform live! Larry Ellison’s going to have a tough time topping that next year!

All in all, I’d call the event a success. I’ll definitely be submitting a session abstract again next year!


Friday, September 28, 2012

JSF-Testing Session at Java One

I’ll speaking next week at Java One on the topic of “Testing JSF Applications with Arquillian and Selenium. The Session co-ordinates are as follows:

Testing JSF Applications with Arquillian and Selenium
CON7622: Thursday, Oct 4, 2:00 PM – 3:00 PM – Parc 55 – Cyril Magnin I

Unfortunately the Java One website truncated the abstract, and the bit that’s left doesn’t give you a good idea of what I’m talking about. Let’s correct that right away!

We’ll start with a review of Arquillian and Selenium, then look at the Arquillian extensions Drone, Graphene, and Warp and how we can use them to write effective JSF tests. These tools allow us to write “real” tests without the need for mocking the JSF environment, nor running in a crippled client container.

For the sake of completeness, here’s the abstract as originally submitted:

Abstract

In modern development environments, it’s a “must” to include testing of web applications as a standard part of the development life-cycle. Such tests can also be used as acceptance criteria in enterprise projects. While full-automation is possible, it is considered to be very expensive. As a result, in projects where testing is included as part of the project plan, it is also often the first requirement cut when the project schedule begins to slip.

JSF projects can be particularly difficult to test with basic tools. We’ve seen a revolution with Arquillian that has made integration testing a breeze. Similarly, Selenium helps in UI testing automation. However, neither Arquillian nor Selenium can save the world alone, as their are some outstanding problems that neither of these technologies address:

  • UI test development is slow and decreases developer productivity
  • Client/server co-operation lacks coverage, each is tested independently
  • Selenium tests only: page transitions, JavaScript interaction, and a portion of the DOM
  • The number of Selenium tests can increase quickly, leaving you with maintenance burden

In an effort to reduce the impact of these concerns, we will look at current best practices of how to achieve a rapid turnaround for test development. We’ll also investigate how to take a client-side test to the server and back, verifying state at both ends. Techniques will be shared for minimizing the effort required to write tests, thereby increasing productivity and making your tests future-proof.