Re: Localization problem, hello world too [solved]
Re: Localization problem, hello world too [solved]
- Subject: Re: Localization problem, hello world too [solved]
- From: Ramsey Lee Gurley <email@hidden>
- Date: Sat, 26 Dec 2009 13:58:49 -0500
On Dec 26, 2009, at 6:16 AM, Johann Werner wrote:
>
> Am 24.12.2009 um 17:10 schrieb Ramsey Lee Gurley:
>
>> Hmm, beyond that, I'm not really sure. Maybe someone who does session-less WO apps has better advice.
>>
>> Since writing that bit of info, I've accepted that attempting to use WO without sessions is a practice in masochism. You lose all the real power of WO without sessions. No component actions, no D2W, no Wonder Ajax, etc. All the best parts of WO depend on a session, and in your case, you're already setting a cookie. Ask yourself, "What difference would it make to set a session cookie instead of (or in addition to) a language cookie?" Is that going to be worth the pain of hand crafting pages, battling accidental session creation, and managing page state entirely through DAs and cookies?
>
> Why use a session when you don't need one?
Why reinvent it when the work has been done already? (^_^) It is one thing to want to remember the language setting for a user when they return to your site later. It is an entirely different thing to want to manage the language setting on your own, in lieu of using a session that handles the job beautifully. It would appear to me that you do need one, but I won't dwell on that point any further. I've reinvented plenty of wheels too. (^_^) I've learned quite a bit the hard way. You are free to do so as well.
> Sessions will cost extra resources.
I was under that same impression initially. I asked the list and...
http://www.mail-archive.com/email@hidden/msg23743.html
The impression I got from that discussion, and from my own testing, is that sessions don't actually cost that much in resources. Sessions only require lots of resources when you have lots of real visitors filling up backtrack caches and such. And in that case, I'm sure sessions are still an order of magnitude more efficient than I could hope to produce with a homegrown solution.
> The behavior I see in WOContext to only rely on the browser languages is logical as ERXLocalizer is not part of the base WO but ERXWOContext should honor the current language of it. But before I put a patch on jira I am really curious what that _languagesAction ivar of WOContext is doing and how (as it is private), where or in what circumstances it gets changed respectively.
I'm still not sure why the original approach is not working for you, but if you want to set _languagesAction, call your direct action's setLanguages() method (Inherited from WOAction). It calls _context._setLangauges() which sets _languagesAction directly. I don't see why you would need to patch the ERXWOContext to do so.
Ramsey
> I didn't find any info on it anywhere.
>
> jw
>
>
>>
>> Naturally, those questions are rhetorical. Since I don't know what exactly you're trying to accomplish, I'm certainly not saying what you're doing is somehow wrong. I'm just afraid this little exercise in page state management is only the tip of the iceberg if you plan on doing much without a session.
>>
>> Ramsey
>>
>>
>> On Dec 24, 2009, at 10:16 AM, Johann Werner wrote:
>>
>>> Hi Ramsey,
>>>
>>> my default language is English. In my performActionNamed method I am already doing this:
>>>
>>> String lang = request().cookieValueForKey("language");
>>> NSArray<String> languages = null;
>>> if (lang == null) {
>>> languages = request().browserLanguages();
>>> } else {
>>> languages = new NSArray<String>(lang, "English");
>>> }
>>> ERXLocalizer.setCurrentLocalizer(ERXLocalizer.localizerForLanguages(languages));
>>>
>>> but when I invoke pageWithName the current localizer is ignored.
>>>
>>> jw
>>>
>>>
>>> Am 24.12.2009 um 15:59 schrieb Ramsey Lee Gurley:
>>>
>>>>
>>>> On Dec 24, 2009, at 9:20 AM, Johann Werner wrote:
>>>>
>>>>> Hi list,
>>>>>
>>>>> I have the same problem as described in this thread. I have an app that uses only direct actions (no sessions) but stores the current language in a cookie. By default I check for that language setting and set the current ERXLocalizer accordingly. But when calling pageWithName I get every time the German component (there is a German and an English component) even if I set the localizer to English.
>>>>
>>>> German is your default? Did you try
>>>>
>>>> http://wiki.objectstyle.org/confluence/display/WO/Web+Applications-Development-Localization+and+Internationalization
>>>>
>>>> Second paragraph from the bottom (under "Direct Actions"). Instead of just looking at the browserLanguages(), you could check for the cookie value first.
>>>>
>>>> Ramsey
>>>>
>>>>>
>>>>> The setting er.extensions.ERXApplication.fixCachingEnabled=false as mentioned by Ramsey didn't show any effect and digging inside the WOContext source I found the method _languages() that should return the language(s) to be used:
>>>>>
>>>>> If there is no session that method returns a _languagesAction array if non-null but this var and its setter are private so I don't see how to change its value.
>>>>> If it is null, which is its default value, then the browser languages are returned. I think there should be a check, if the localization is enabled in the app and return the language of the current localizer instead, shouldn't it?
>>>>>
>>>>> Any thoughts? I altered my ERXWOContext for now and could put a patch on jira.
>>>>>
>>>>> Happy Christmas,
>>>>> jw
>>>>>
>>>>>
>>>>> Am 02.12.2008 um 23:55 schrieb Ramsey Lee Gurley:
>>>>>
>>>>>>
>>>>>> On Dec 2, 2008, at 2:53 AM, Anjo Krank wrote:
>>>>>>
>>>>>>>
>>>>>>> Am 02.12.2008 um 08:04 schrieb Anjo Krank:
>>>>>>>
>>>>>>>> If it doesn't, rewrite the method so it re-orders the nsarray so that it still has all items from _expectedLanguages, but the ones from nsarray come first and in order and post a patch.
>>>>>>>
>>>>>>> I checked in an (untested) interim patch. See if the problem persists.
>>>>>>>
>>>>>>> Cheers, Anjo
>>>>>>
>>>>>> Nice patch :-) Oh, and for the record, what I was saying earlier about needing to return something from session languages() is complete garbage... I see you've already taken care of that in ERXSession's setLanguage(). The problem here was my test app was returning null from the updateLanguage() action instead of a page. [Are you listening to this Mike? :-) ] I think this must be different from Mike and Chuck's debate though, because even returning context().page() causes the contents of the current page object to be re-rendered instead of refreshing the localized component. I actually needed to do
>>>>>>
>>>>>> public WOActionResults updateLang() {
>>>>>> return WOApplication.application().pageWithName(context().page().name(), context());
>>>>>> }
>>>>>>
>>>>>> to get the right localized page component when changing languages. Perhaps there's another way to invalidate the page and cause the whole thing to refresh, but I'm satisfied with that for now...
>>>>>>
>>>>>> Ramsey
>>
>
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden