Day 2 of the RichFaces skinning and we have the first approach for tablet devices. Tablets are a little harder to design for because of a few reasons:

1) Your design sits on the fine line between desktop and mobile. You are designing your app for a max 1024 pixel resolution (in landscape mode) but you must also take advantage of mobile usability (which you will see in page2)

2) Similar to the iPad Mail.app, it‘s almost like you are designing 2 different UI‘s for landscape and portrait modes. For portrait you need more drop down menus, and for landscape you can try to fit everything on one page without the drop downs.

Day 2: About The Design

Notice how, unlike the iphone design from Day 1, I left the browser button overrides within the app itself. Tablet web apps are completely use case driven so this will vary. But since we have so much more real estate, we can play around with standard navigation options that keep the user's attention focused on the app itself.

The second page is what you see after selecting a menu item from page 1 (click to enlarge). Here we have the title bar at the top left with a built in back button which takes the user back to the first screen.

To the right of the title you see the secondary menu represented by rounded rectangles. Next is the main content of the page broken out into content and actionable panels.

And finally you have the big arrows to the right and left. These arrows are “thumb reachable” which is a common usability pattern in portrait mode tablets. It provides an easy page flip access to all of the RichFaces components within the top level category.

The great thing about CSS3 transitions is that you can really make a UI like this scream and flow seamlessly. So you can imagine how tapping an arrow with your thumb will slide in a new component demo and gracefully highlight the secondary menu option at the top.

So this concludes our design for Day 2. As I said earlier, this is more of a use case driven design. WE could spawn a very minimalistic skin and component look and feel from this. However, It would be more to display the power behind RichFaces ajax and templating features as the user moves through the app.

Today marks an important day in the RichFaces project as we continue to head down the mobile web road. Since we have such a great community of users and followers, we want you to be involved with the design process.
So each day this week, I will come up with a new proposed design/theme for RichFaces Mobile and we want to hear your feedback.

I will announce each new design (both for tablet and phone) via twitter with a link back to this article. I will try my best to pick apart each design and describe why I did what I did, and hope you can give me some real world feedback. We want this project to actually make sense and be usable to what you guys are facing in the real world. Without further adieu....

Our first task is to tackle the RichFaces showcase of components. Classifying what is mobile ready and which components may need a little work.

Day 1: About The Design

In this design we have the standard browser “functionality take over” at the top header. The custom back button is essential to mobile web design and must be overridden here – following the pattern of previous designs.

Nothing too different about the standard menu options and detail options (center stage). Following convention here as well. One thing I am adhering too are the usability guidelines set forth by Jakob Nielsen‘s Usability of iPad Apps and Websites

To get the full tab bar at the bottom (and to replicate the native feel) the user must bookmark the application. I think it makes sense for this menu to be contextual to the app and provide other alternate routes.

About TweetStream

The Code...

We used infinispan in both instances, but our @TwitterLocal is a single node caching a direct twitter stream from Twitter4J.

Now that we have our types defined as follows…

We need not only an implementation of each, but also a deciding bean that tells us which type to use.

First, our implementation of each Type implements an interface:

And our implementations have a different usage of the init method. TwitterLocal starts the stream coming from twitter and updates the infinispan cache. TwitterServer starts a method which allows us to start receiving data from the keynote which uses complex event processing and a datagrid with 6–8 nodes.

So now, how do we decide which Type to use? There are a few different ways to do it, but in the case of this being a demo and not a lot of time on my part. I used this approach:

This is all in the source code. Feel free to pull it and make improvements or run it to see it in action. There are many more blog posts to come from this demo, so stay tuned…

Working with portlet technology is often discredited for it’s seemingly complex API and development hoops one must jump through. But if you have worked on a portlet project for a considerable amount of time, and then jump back to a servlet based project, you have a feeling that life just got easier.
This is all within the context of which servlet-based framework you might be working with, but overall things are a bit easier when dealing with one request and response.

What if you didn’t have to worry about portlet development gotchas anymore? What if you could develop portlets with the ease and hassle free life that you have with good ol’ servlets? Well, I’m here to tell you that this can be partly achieved with JSR-301 portlet bridge technology.

I encourage (actually I dare you) to those who have never even touched a portal to take the JBoss Portlet Bridge for a test drive. It takes 1 download (GateIn bundled with JBoss) and one maven archetype to get started. You can choose from any combination of plain JSF, Richfaces, and Seam with
mvn archetype:generate -DarchetypeCatalog=http://bit.ly/jbossportletbridge from the command line.

If you run into any questions or special usecases, we have 7 videos which demo and walk you through just about anything you could think up.

And for those that like to have a refcard by their side, you can get all the information you need about the story of portal technology and configuration drill downs here:

From “Mastering Portals with a Portlet Bridge” DZone Refcard:
“A portlet bridge allows you to run application frameworks like JSF in a portal environment without needing to know anything about the underlying portlet API or portlet concepts.”

And if all that wasn’t enough, I will be giving a 50 minute talk at JBoss World titled "Making Portals Cool: The Compelling Advantages of a Portlet Bridge" where you can come and personally track me down and specifically tell me about your problems, pains, or happiness with the project or the world in general JBoss World will be located in Boston from May 3–6.
I think early bird pricing ends this Friday (April 8th), so you better hurry if you want to save a little cash.

I saw a tweet from(@maxandersen) the other day and decided to try adding Growl like messages in a standard JSF/Richfaces application using jGrowl. It is quite simple and my approach could definitely be improved upon.

This is really just javascript on the front end and can be used with any backend message generating system.

Code Used:

• RichFaces 3.3.1.GA
• jGrowl (latest)

Include the scripts in the head:

Note the loading of jquery in the Richfaces page...

 
 
 <a4j:loadScript src="resource://jquery.js"/> 
<link rel="stylesheet" href="/css/jquery-plugins/jquery.jgrowl.css" type="text/css"/> 
 <script type="text/javascript" src="/js/jquery-plugins/jquery.jgrowl.js"></script> 
 
  

Write a simple script to extract the message:

... and add any customizations you may need to jGrowl. One thing to take note of here is that you cannot use the $ sign for jQuery in a Richfaces app. This is because of the RF framework using prototype.js by default and it too uses the $ sign. So every 3rd party jQuery script that you use, you must s/$/jQuery/g (find and replace all usages of '$' with 'jQuery')

 
function showError() 
{ 
jQuery.jGrowl.defaults.position = 'center'; 
if (document.getElementById('errorMessage') != null) 
{ 
jQuery.jGrowl(jQuery('#errorMessage').html(), { 
sticky: false, 
life: 10000 
}) 
} 
} 

And tell the script to run after page load:

jQuery has a simple statement that checks the document and waits until it's ready to be manipulated, known as the ready event:

 
$(document).ready(function(){ 
showError(); 
}); 

Here is a live screen shot of the script in action using a generate h:message.

Read about it here: http://blog.jboss-portal.org/2009/01/jboss-portlet-bridge-beta-6-released.html

InfoQ just published the first in a series of 3 articles for the JBoss Portlet Bridge. The author of this series did an unbelievable job. I could write a whole post about how great his article(s) are, but I would hate to loose sight of this post topic :-) heh - just kidding... the author is me!

This first part is about basic JSF development with an easy to follow tutorial and real world development tips. The next one will be about RichFaces and the final (about Seam) will be published right after the release of Beta 4 in early September.

Enjoy!
http://www.infoq.com/articles/jsf-ajax-seam-portlets-pt-1

http://www.infoq.com/articles/jsf-ajax-seam-portlets-pt-2

We just released JBoss Portlet Bridge Beta3 along with some good supporting documentation and example projects. See the documentation for full details.

For those that want to jump right in, you can run the following archetype and have it deployed on JBoss AS + Portal in minutes:

 
mvn archetype:generate -DarchetypeGroupId=org.jboss.portletbridge.archetypes -DarchetypeArtifactId=1.2-basic -DarchetypeVersion=1.0.0.B3 -DgroupId=org.whatever.project -DartifactId=myprojectname -DarchetypeRepository=http://repository.jboss.org/maven2/ -Dversion=1.0.0.B3 

 
mvn install cargo:start -Premote-portal -Dpc20 

 
mvn cargo:deploy -Premote-portal -Dpc20 

• The EG is currently discussing a lot of significant clarifications and improvements. For example, working with the JSF 2.0 EG to allow certain needs and working on Portlet 2.0 areas of the spec.
• There is currently a lot of discussion about navigation between portlet modes. Once this is nailed down in the spec, we will implement it.
• The Portlet 1.0 version should be getting close to public review.

• Namespacing In situations where you need to use the id of an element in your JSF/xhtml markup, you would normally see something like 'form1:myBtn' in the rendered markup. But now with the bridge namespacing you will see something similar to:

  jbpns_2fdefault_2fNews_2fStories_2fStoryTemplateWindow12snpbj:_viewRoot:form1:myBtn

  To overcome this, you can use the following expression in your Facelets page to prepend the namespace to your javascript code:

  document.getElementById('#{facesContext.externalContext.response.namespace}the_rest_of_JSF_ID

  since this uses the portletResponse, once you try to view this page on the servlet application side, you will get an exception. To avoid this, you need to check for the type of response in your backing bean and assign a new "safe" namespace variable for the UI.
• Excluding Attributes from the Bridge Request Scope When your application uses request attributes on a per request basis and you do not want that particular attribute to be managed in the extended bridge request scope, you must use the following configuration in your faces-config.xml. Below you will see that any attribute namespaced as foo.bar or any attribute beginning with foo.baz(wildcard) will be excluded from the bridge request scope and only be used per that application's request.

   
  <application> 
  <application-extension> 
  <bridge:excluded-attributes> 
  <bridge:excluded-attribute>foo.bar</bridge:excluded-attribute> 
  <bridge:excluded-attribute>foo.baz.*</bridge:excluded-attribute> 
  </bridge:excluded-attributes> 
  </application-extension> 
  </application>

It has been quite a while in the making (a couple months) and we finally have a beta release of the portlet bridge.

The JBoss Portlet Bridge is an implementation of the JSR-301 specification to support JSF within a portlet and with added enhancements to support other web frameworks. Currently the bridge supports any combination of JSF, Seam, and RichFaces to run inside a portlet.

See the project page for more details and a live demo.

Before I begin, let me say thank you! thank you! thank you! for the extended EL in Seam. On a previous project, I was using straight JSF 1.1/1.2(Myfaces) and the extended EL alone, makes Seam a worthwhile choice.

This article is about an application that is relatively simple (to start). A report with customer information that has pretty charts and graphs and is printable to PDF. Since I didn't have any requirements to start, I thought I would list a few of my own here ;)

• JSF & Seam
  • RESTful URL's
  • EJB3/Hibernate
  • Local, rapid, development
• Maven 2
• Charts
• Html 2 PDF functionality

JSF & Seam

When I started development, Seam was at v.1.2, Embedded EJB (aka Embedded Jboss) was at RC9, and Jetty was being used for local dev and testing. I was able to get a jump start from the guys over at http://softeu.cz for the jetty/ejb/war deployment and I found a rouge project on the seam boards called JBossSeamDVDStore that gave me the ejb Maven archetype ideas/best practice.

I went through some good (and bad) code getting the embedded RC9 stuff working with Jetty. It boiled down to this post showing why and what I did.

The good and bad news now is that Embedded EJB3 is now Embedded Jboss and Embedded Jboss only works with Tomcat (for now) and here is a post explaining why it's this way. But this could also be a blueprint for creating the same thing for Jetty, I just don't have the time to do it right now.

Here is a list of resources I found useful while researching.

RESTful URL's

The #1 biggest complaint using JSF is no RESTful urls, and Seam does a great job of solving it. The only problem I have now is double execution when the user does a postback to a page that has a action mapped in pages.xml. The form I'm submitting calls the same action as the url I have mapped for REST support. I haven't spent alot of time with it and it may be total user error, but it would be nice if double action execution did NOT happen naturally.

EJB3/Hibernate

Using seam-gen, in Oracle, a few tables had null id fields and no primary key - The generated entity bean was genned as a object with one member (an ID) and I guess it was considering the entire record (all columns) as a unique. Being new to EntityBean/Generated hibernate code, it took us a few hours to figure this out, but once we saw that the data model was screwed up and how seam-gen handled it, the fix was easy.

Local, rapid, development

This was mentioned a little in the first paragraph. I wanted a faster, local build environment than what was currently offered by the company I'm working for. They are heavily tied to ant and there were 0 projects using Maven. So, being the completely crazy person that I am, I introduced a new build method with Maven 2, a new Framework wrapper (Seam), and a local build on the developers laptop with hot deploy. I know Jboss AS offers hot deploy, but I really wanted to use Jetty with Embedded Jboss. Since, that isn't currently implemented, I went with the next best thing and used Tomcat. My current company gives every developer a Solaris box to build on, all builds/projects are tied to building on Solaris. When one tries to use IntelliJ Idea over a Samba mount, you will quickly see how much it brings down overall performance and speed. There are other pluses that I could go into on local dev opposed to a remote *nix box, but I will stop here.

Maven 2

When you have 100's of projects on Ant and everyone in the company is pro Ant because so much time has been invested into the current build environment, you really feel like your going against the grain. However, most of us in the open source world, that are consultants, have seen the light on other projects and we bring new things into whoever we are working for. This is what I did. I eventually gained a few supporters, because everyone knows what happens when you are close minded to innovation.

Charts

I think using the Trinidad Charts are what WOW'd the upper management the most. Since this company has a distributed computing environment with no admin rights, we had to get the security/network folks on board with the Adobe SVG plugin. I heard the Renesis viewer is pretty good also and we will probably move to it later since Adobe is killing support on their plugin.

Html 2 PDF functionality

PD4ML: I started with this HTML2PDF renderer. It was super easy to get hooked up to the app. I structured my xhtml and css for both screen and print media types, but due to lack of CSS 2.1 support and very limited subset of css and html support, the output was terrible and required alot of rework just for this PDF to render half way decent. And it costs money :(

With the output coming out horrible in PD4ML, I took a look at a pure xhtml renderer, Flying Saucer.

FS Almost instantly rendered all of my XHTML correctly on the first render. I had to make a few adjustments for things like CSS page-break properties and border-collapse. And, before I could even get the page to render I had to clean up the legacy HTML that some JSF renderers output (I ran tests with both Jtidy and NekoHTML) - both did the trick and I couldn't tell a difference. All the JSF folks that I have talked to welcome feature requests for XHTML compliance.

This demo shows some pretty cool stuff from Flying Saucer and what it can do. It is basically the same concept of iTunes web browser/desktop app. PDF isn't the end of the road either - they have examples on rendering the exact same XHTML content to PNG, SVG, and Excel - I'm sure there will be more.

There are probably a million more things in Seam that I could talk about here, that I completely can't live without. This article just touches on the real world stuff that I encountered while developing.