Re[2]: German Umlaute
Christoph Kutzinski wrote: ISO-8859-1 should be no problem since it contains all german umlauts. True. But I have standardized on UTF-8 for all text output in my applications, since I sometimes also have to deal with cyrillic stuff, and I don't want to adjust my encodings and the input filter all the time. Going directly to UTF-8 solves all that. Is there any good reason not to use UTF-8 by default? -- Carl-Eric Menzel * OpenPGP KeyID 808F4A8E * Encrypted Messages Preferred Der Beginn aller Wissenschaften ist das Erstaunen, daß die Dinge sind, wie sie sind. - Aristoteles
Re: German Umlaute
Hi, I.m currently facing a weired problem. I use a form to provide a search function. When I do not use any special character in this form everything is fine. As soon as I enter e.g. Rö the corresponding form value is set to Rö If an umlaut appears in the search result it is display correctly. So, the problem seems to occur only in the request. What browser are you using? I had the same problem, and I more or less solved it by outputting only UTF-8 pages, with the proper header set. This causes most browsers to respond in UTF-8. The default encoding that the servlet classes use is ISO-8859-1, however, so I also use a filter to force the servlet to treat the incoming request as UTF-8. So far this has worked nicely. With Struts 1.2 you can now also use the acceptCharset attribute of the html:form tag. I don't know how well this is supported by the current crop of browsers, but it should give them another hint what you want them to do. HTH Carl-Eric -- Carl-Eric Menzel * OpenPGP KeyID 808F4A8E * Encrypted Messages Preferred It is seldom that liberty of any kind is lost all at once. - David Hume
Re: character encoding
I'd like to hear how others have solved this problem. I can see that one solution is to replace the RequestProcessor and hardcode the setEncoding on the Request to UTF-8, or subclass the whole ActionServlet. Are there any cleaner solutions? I can't believe I'm the only one to have run across this problem! I'm not THAT unlucky! :) I am using a Filter (from the Servlet API) that gets the request before anything else in the chain and calls setEncoding() on it before passing it on. What would be great, just to get a little more consistency into this, would be if the html:form-tag would finally support the accept-charset attribute as specified in HTML4.01. HTH Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: character encoding
Carl-Eric, Yes, I tried the charset on the form but found it didn't do any good. But what do you force the Encoding to in your Filter? How can you know with any certitude how the browser encoded the data values before sending it to you?? It probably works well if the browser is setup to auto-select the encoding, but what do you do if they have it explicitly set to something other than what you are assuming? Then I'm out of luck. That's the biggest problem with Strut's lack of support for the accept-charset attribute. *Most of the time* it works that if you send the response in UTF-8 the next request will come in as UTF-8 too. That's what I'm doing now - I send out only UTF-8 forms and assume that I get the same back. It's an ugly hack, but the only way that seems to work at the moment. I asked a few weeks ago if there was any way for me to extend the form tag to support this attribute, or whether there is any good reason why it is not implemented. So far I haven't received an answer. Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[3]: character encoding
Then I'm out of luck. That's the biggest problem with Strut's lack of support for the accept-charset attribute. *Most of the time* it works that if you send the response in UTF-8 the next request will come in as UTF-8 too. That's what I'm doing now - I send out only UTF-8 forms and assume that I get the same back. It's an ugly hack, but the only way that seems to work at the moment. I asked a few weeks ago if there was any way for me to extend the form tag to support this attribute, or whether there is any good reason why it is not implemented. So far I haven't received an answer. PS: While searching for a solution I found that the HTTP spec actually provides the browsers with a way to *specify* the encoding they're sending, which would completely solve this issue. It appears that the only browser that supported it *was* Mozilla. They found out that this extended (but conforming to the spec!) Content-Type header made so many broken CGI-scripts puke that they removed this feature again. *sigh* Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
form accept-charset
Hi, is there any special reason why the html:form tag doesn't support the accept-charset attribute defined in HTML 4.01? I would very much like to use this to make my charset handling at least a little bit cleaner. Right now I'm sending all responses in UTF8, and am assuming that the browsers send the same charset back. Is this planned for Struts? If not, is there any way I can add it myself? Thanks Carl-Eric -- Antwort: Weil es das Lesen des Textes erschwert. | Carl-Eric Menzel Frage : Warum ist das so schlimm? | PGP ID: 808F4A8E Antwort: Antworten oben zu schreiben. | Bitte keine HTML- Frage : Was ist die schlimmste Unsitte in Emails? | Mails schicken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Hibernate Session to User Session
I was reading in the Hibernate forums that when you have a WebApp DAO Hibernate DB design, and you open/close each Hibernate session at every single DAO method call (what I do now) its actually quite expensive, This is fairly expensive, but not that much. The *SessionFactory* is expensive, a single Session isn't that bad. and is suggested that you attempt to maintain a Hibernate Session in conjunction with a user Session to increase performance. You have definitely misread something. This is not officially recommended anywhere. I had a question for anyone that has done this (without using SpringFramework). My gut-reaction to this was to add a HttpSessionListener to my webapp that created and stored a Hibernate session in the user's session, and then close it when the Session expired... will this not work? Anyone else have a good solution for this? No, this is not going to work. A Session is similar in its scope to a transaction - it is what the Hibernate developers call an Application Transaction, i.e. a unit of work from the application's point of work, that may span several database transactions, but should NOT be kept open during user think-time, i.e. across requests. The biggest problem with this is that you would keep a db connection open with this as well. If you use the disconnect()/reconnect() methods, you wouldn't have the open connection, but since the Session is also a local cache you would very quickly see stale data. The best way to do it, IMO, is to use for example a request filter and generate a fresh Session when the request begins, and close it at the end of the request. That way you always have fresh data and don't unnecessarily keep open connections. HTH Carl-Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: Hibernate Session to User Session
Riyad Kalla wrote: I believe that is what I am using now (it seems to be quite popular) but I don't quite understand the reasoning behind the ThreadLocal approach (I've actually never used 'ThreadLocal')... can you shed some light on this? What the mapping between Hibernate Sessions and Users (or Threads) becomes? The preferred mapping is still one Hibernate Session per HTTP Request. You would also still need a Filter that instantiates the Session when the request comes in and closes it when it is finished. But instead of putting it into the request as an attribute, you can put it into a ThreadLocal. That way, all methods that need the Session can simply use the ThreadLocal to get it and you don't have to pass around request attributes. Carl-Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
