Home/Tag: xhtml

Displaying and Rerendering a RichFaces ModalPanel from a commandLink

Let’s say that when a user clicks on something, perhaps selecting something from a DataTable or DataGrid, you want to call some server side code, and then popup a modal panel which needs to show content based on the new state setup by your server side call. In my case I have a DataGrid showing a number of items, and when a user clicks on an item I want to set the current selected item on a Seam component on the server, and then popup a modal panel to display detailed information about the item, and provide the user some actions within the modal panel.

Looking at the solution it seems so simple, but for some reason it took me hours of trying different combinations, orders, tags, JavaScripts, etc… before I could get this to work correctly. I had the panel appearing with the old data, or appearing with the old data and then disappearing completely, only to show the so called new data the next time I clicked on an item, or rendering on the page itself below the footer, or not popping up at all, or popping up with null data, or…. So I’m posting it up here for myself and anyone else who runs into issues.

First, create your modal panel (rich:modalPanel). I do this in a separate .xhtml file, as I will use the same model panel in various pages throughout the site. In your modal-panel.xhtml file (or whatever you choose to name it), start with a tag, define your RichFaces xml namespace (and any other JSF libs you’ll be using), and then setup your

You need to give the modalPanel a unique id, in this case we’ll call it “myModalPanel”.

Inside your modalPanel tag, you need to define an inner div. This is the div which you will be rerendering after the server action is complete. I use tags, as I’m using Seam. Ensure that any references to backing beans or data that you want refreshed are within these div tags. You must give this div a unique id as well, in this case we’ll call it “myModalDiv”.

The one limitation that I’ve run into here, and if you know how to solve this, please let me know, is that the tags for your header text and controls can’t be inside this div, and you can’t put the div around the whole modalPanel (or it makes the panel disappear when you rerender). As such you can’t make anything from the s be updated on rerender. This is preventing me from having the modal panel header displaying the current selected item’s name. Not great, but not the end of the world.

So inside this div you have your dynamic output. I have lots of type entries in mine.

On your actual page where you will be displaying the modal panel from you need to include the modal-panel.xhtml file, I use a:

[code lang=”xml”] <a:include viewid="/modal-panel.xhtml">[/code]

Then, I have my page, which includes a rich:dataGrid, and inside it has an which creates the AJAX clickable item. This commandLink has to call the backend action, display the modal panel, and rerender your div.

Click Here!

This makes the panel display, and then the new content is rendered in the panel. It seems to work just how I wanted it to. With the minor annoyance of having to use a static modalPanel header.

How to get RichFaces to not crash Safari

RichFaces, a collection of open source JSF Components for building “rich” AJAXy interfaces, unfortunately makes Safari crash or hang or lock up with many of it’s components.

I’m not the one who figured this out, but I wanted to document it here.

You can solve this the same way you solve the JSF/Google Ad issue:

Add this just before the tag on your .xhtml pages or template file:

Firefox, xhtml, JBoss 4.2.0, JSF, and Google Ads

I upgraded the JBoss instance on my server just over a week ago from 4.0.5 to 4.2.0. Two things happened after that: Firstly, my google adsense revenue dropped by half, secondly I was contacted by two different people who were having some e-mails show a big error in Firefox, instead of showing up correctly. I don’t use Firefox myself, I use Safari about 98% of the time and Camino when I find a site that doesn’t render correctly in Safari. Today I discovered, while working on a new ad layout, that in Firefox the Google ads weren’t rendering at all, throwing this error in the Firefox error console:

Error: uncaught exception: [Exception... "Object cannot be created in this context" code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location: "http://pagead2.googlesyndication.com/pagead/show_ads.js Line: 4"]

Basically iframes can’t be programatically inserted into strict xhtml elements. I did some googling and discovered that there were some discussions around this, but most of them simply said “either ditch google ads, or use text/html instead.” But I WAS using text/html, both in the meta content tag in the pages, and then later (while working on this issue) in the JBossWeb web.xml mime type configuration for xhtml, just in case. Using wget with –save-headers didn’t show anything unexpected. However, Firefox kept getting the response header saying the page was application/xhtml+xml which caused it to perform very strict validation, both breaking the google ads, and not letting sloppy tags or duplicated tags into the page, which are inherently going to happen when you’re rendering html e-mail within a page.

The cause of the break was not moving to JBossWeb in 4.2.0, nor any JBoss code itself. It turns out that when the JSF implementation was changed from MyFaces to Sun’s JSF-RI as part of the JBoss and Seam upgrade I did, the default content mime type changed as well. JSF-RI sets it to application/xhtml+xml. The fix was simple, add the following tag just before the tag in each .xhtml faclets page:

Index page issues when putting JBoss behind Apache

So, if you’re using Seam, you usually have xhtml files which represent the pages, and then the Seam servlet takes care of rendering them. When I setup my latest project, I changed the web.xml to switch from using page.seam to page.html, to mask the back-end technology. When I did this, I also deleted the seemly unnecessary index.html that was sitting in my view directory. I then added this into my web.xml, just to be on the safe side: