<p:dataTable> internationalization problem

[vesuvius]

Hi,

I have a problem with the dataTable internationalization. More specifically, let's focus on the firstPageLinkLabel attribute. When I set some localized label there, on first display, the label is shown properly. However, after postback, all I'm getting are question marks (?????). I use something like the following:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
...
    <h:head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    </h:head>
    <h:body>
            ...
            <h:form>
                ....
                <p:dataTable id="theTable" firstPageLinkLabel="[[[some text in cyrillic here but if I put cyrillic, I get an error when I submit the topic to the forum]]]"...>
                    ...
                </p:dataTable>
                <p:commandButton value="Postback" ajax="true" update="theTable" actionListener="#{someBackingBean.postbackListener}"/>
...

The first time I display the page, it is displayed properly. After I click on the postback button, the firstPageLinkLabel is displayed as: ?????

The action listener on the button doesn't do anything. If I remove it, the label still turns into question marks. I guess the encoding of the Ajax response is not okay.

Can you give me some clue what I can do to prevent this?

(In the meantime, I will try to figure out what's wrong.)

[vesuvius]

One more observation:

The Ajax request contains:

Code: Select all

Host	localhost:8080
User-Agent	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Accept	application/xml, text/xml, */*
Accept-Language	en-us,en;q=0.5
Accept-Encoding	gzip,deflate
Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive	300
Connection	keep-alive
Content-Type	application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With	XMLHttpRequest
Referer	http://localhost:8080/TestApp-war/
Content-Length	194
Cookie	JSESSIONID=e4332a4180ec467b1a186d4eec02
Pragma	no-cache
Cache-Control	no-cache

The server response is:

Code: Select all

X-Powered-By	Servlet/3.0, JSF/2.0
Server	GlassFish v3
Content-Type	text/xml;charset=ISO-8859-1
Content-Length	5958
Date	Mon, 08 Feb 2010 15:54:20 GMT

Notice the ISO-8859-1 encoding in the request's Accept-Charset header and in the response's Content-Type header. Where did it come from?

I'm using the latest SNAPSHOT (from February 7th).

[monakhv]

One more observation:

The Ajax request contains:

......

Notice the ISO-8859-1 encoding in the request's Accept-Charset header and in the response's Content-Type header. Where did it come from?

I'm using the latest SNAPSHOT (from February 7th).

Did you setup default character set utf-8 for GlassFish?

[cagatay.civici]

Just an idea, i18n text are set via javascript, can you try using unicode characters instead to see if it makes a difference like \u00F6.

[vesuvius]

Did you setup default character set utf-8 for GlassFish?

Well, I can see the following in the GlassFish Developer's Guide:

Servlet Response

When processing a servlet response, the server uses the following order of precedence, first to last, to determine the response character encoding:

* The setCharacterEncoding() or setContentType() method
* The setLocale() method
* The default, which is ISO-8859-1

The first thing is the setCharacterEncoding() or setContentType() method. I have specified the UTF-8 encoding both in the XML header and in the HTML HEAD element (<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>). It seems that the Content Type is not explicitly being set when generating a response to an Ajax request.

The non-Ajax requests work okay. (<p:commandButton ajax="false".../>) Then the encoding is UTF-8. Only Ajax fails. Here's the non-Ajax response:

Code: Select all

X-Powered-By	Servlet/3.0, JSF/2.0
Server	GlassFish v3
Content-Type	text/html;charset=UTF-8
Transfer-Encoding	chunked
Date	Tue, 09 Feb 2010 12:18:08 GMT

I will try to find out more if time permits.

[vesuvius]

One more thing in addition to my post above:

When I use standard JSF2 Ajax, like the following:

Code: Select all

    <h:commandButton actionListener="#{someBackingBean.postbackListener}" value="Postback (Mojarra)">
        <f:ajax render="theTable"/>
    </h:commandButton>

then two interesting things happen:

1. The encoding is okay!!!!

Code: Select all

X-Powered-By	Servlet/3.0, JSF/2.0
Server	GlassFish v3
Cache-Control	no-cache
Content-Type	text/xml;charset=UTF-8
Content-Length	5894
Date	Tue, 09 Feb 2010 12:23:54 GMT

2. The table disappears. This makes me think that the <p:dataTable> component doesn't play nicely with standard JSF2 Ajax. But I'm still rather new to JSF2 to make definitive conclusions.

EDIT: I added a <h:dataTable> component and it did NOT disappear after a standard JSF2 Ajax. Only the <p:dataTable> disappeared. I think that, in order for PrimeFaces to be a truly compliant JSF2 library, it should support standard JSF2 Ajax without breaking. Furthermore, perhaps it would be good if the <p:commandButton> component supported the <f:ajax> nested tag instead of (or in addition to) the ajax="xxxxx" attribute. That would make it more JSF2-like.

[cagatay.civici]

JSF2 ajax is the basic implementation, PrimeFaces Ajax is more advanced than that. Most of the PrimeFaces components render simple Dom elements like <div> s and stuff and the rest of the related dom is generated by the client side widget. In this case, a PrimeFaces.widget.DataTable instance creates the actual datatable. It seems JSF2 ajax can't handle <script /> tags in partial output, but it is an implementation detail, I don't remember any statement like that in JSF spec.

Also I usually fix my encoding problems with a character encoding filter.

This will make sure everything is UTF-8.

http://www.jroller.com/mert/entry/utf_8 ... g_with_jsf

[vesuvius]

Thank you for the answer!

Actually, I was not really seeking for a workaround. I have been dealing with Filers and PhaseListeners heavily in the past. I'm pretty sure I can enforce the encoding through some hacking and workarounding.

My real issue is why PrimeFaces generates the response in ISO-8859-1. Or, rather, I suppose that PrimeFaces simply doesn't set any encoding and the server's default encoding is used.

However, the standard JSF2 Ajax response was sent back with UTF-8 encoding which makes me think that Mojarra's own Ajax explicitly sets the encoding to the one used on the JSF page. PrimeFaces, on the other hand, loses the encoding somewhere along the way. I was mainly interested in solving that problem in PrimeFaces, so that we can forget the hacks with Filters and PhaseListeners.

I haven't had any need to enforce the encoding with ADF Faces, for example. We were using the WINDOWS-1251 and still we didn't need to do any hacks whatsoever. It seems JSF was able to figure out the encoding by looking at the page itself.

Isn't something like that possible with PrimeFaces? Resorting to hacks should be the last possible step that we should take, only when everything else fails.

(By the way, if I have some pages that use UTF-8, other pages that use WINDOWS-1251, and still others that use ISO-8859-1, applying a Filter that enforces UTF-8 will simply destroy all the non-UTF-8 pages in the application. I know this example is quite contrived, but it's possible nonetheless.)

[vesuvius]

Ah, again, I thought of something after I had already posted a reply.

I'm not really familiar with the way PrimeFaces generates its Ajax request headers, probably via YUI's Connection Manager, but do you think it would be possible to set the Accept-Charset header's value explicitly to the current page's encoding? Something like:

Code: Select all

xmlhttp.setRequestHeader("Accept-Charset", (document.charset||document.characterSet)  + "...");

And then, on the server, to check the Accept-Charset header and, if available and valid, to send the response with the requested encoding?

[vesuvius]

...It seems JSF2 ajax can't handle <script /> tags in partial output...

I will add a third post in addition to the above two:

I did notice that you've commented here:
http://www.jroller.com/HazemBlog/entry/ ... ax_problem

However, about 4 months after your comment, Jim Driscoll has posted another comment:

Fixed in Mojarra now, and also MyFaces, and will be in the next rev of the spec.

Have you checked recently whether the problem with the <script> tags still persists?

I hope that eventually it will be possible for PrimeFaces to work okay with JSF's own Ajax mechanism. Otherwise, there might be various problems if we use anything other than PrimeFaces components on our pages. There won't be any interoperability between PrimeFaces components and components from other libraries (even standard JSF2 components), if Ajax is used on the page. Or... will the <p:commandButton> component, for example, be able to support all kinds of components, not only PrimeFaces components?

I think it's important to know what will happen if we mix PrimeFaces and non-PrimeFaces components on a page and if we use Ajax on that page. To me such information is crucial in deciding whether our next project will use PrimeFaces or not. Any interoperability problems will cost us dearly in the long run.