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 protected]/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 >> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
