[Zope3-Users] Re: User preferences for languages- possible?
Giovannetti, Mark wrote: Hi, This stuff is crazy. I just want to implement a user preference for a language (because I have to). I've read all the user pref. documentation (skinpref, apidoc prefs and zope.app.preference) until I'm blue in the face. Nothing seems to work and there is no help via google and so forth. I know that UserPreferences() wants an ILocation object. I can't seem to get one inside the BrowserFormLanguages class. I am only given the request object. What do I need to do? Getting a root site is insane the way I found to do it via a mailing list message. Not to mention it had issues racking up db connections, then failing on close. Help! Please! Thank you! Preferences seem to work since I can edit them using the http://.../++preferences++/ form. The zope.app.preference stuff stores the info in principal annotations, in a weird way. I personally find that stuff a bit convoluted. The key, as you've correctly identified, is write your own IUserPreferredLanguages adapter (or a variant thereof). I would store the user's preferences in a cookie or a session. This makes things much easier. Simply adapt the request to ISession(request). Note that this might not always work, e.g. when the request is instantiated and the request's locale is first created (because local utilities to store the session data in aren't available at that point). It seems you're hitting that exact problem with the preference stuff as well. The trick here is to stub this out when the adapter is first called, and then later during traversal, when you know the local components are there, you revisit it all again by calling request.setUpLocale() or whatever it is. The ++lang++ implementation might give some pointers. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
RE: [Zope3-Users] Re: User preferences for languages- possible?
Hi Philipp, You are a great resource, thanks for helping. See below. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philipp von Weitershausen Giovannetti, Mark wrote: Hi, This stuff is crazy. I just want to implement a user preference for a language (because I have to). I've read all the user pref. documentation (skinpref, apidoc prefs and zope.app.preference) until I'm blue in the face. Nothing seems to work and there is no help via google and so forth. I know that UserPreferences() wants an ILocation object. I can't seem to get one inside the BrowserFormLanguages class. I am only given the request object. What do I need to do? Getting a root site is insane the way I found to do it via a mailing list message. Not to mention it had issues racking up db connections, then failing on close. Help! Please! Thank you! Preferences seem to work since I can edit them using the http://.../++preferences++/ form. The zope.app.preference stuff stores the info in principal annotations, in a weird way. I personally find that stuff a bit convoluted. If you find it convoluted, then how are us mere mortals supposed to deal with it? ;-) The key, as you've correctly identified, is write your own IUserPreferredLanguages adapter (or a variant thereof). I would store the user's preferences in a cookie or a session. This makes things much easier. Simply adapt the request to ISession(request). I'll end up having to do something like this, I suppose. It really sucks, though, because I *want* to use the preferences machinery. Why was it built if it can't be used in certain places - and why aren't the places it can't be used documented? Arrg. Note that this might not always work, e.g. when the request is instantiated and the request's locale is first created (because local utilities to store the session data in aren't available at that point). How am I supposed to deal with what you say above? I don't even understand most of it! ;-) It seems you're hitting that exact problem with the preference stuff as well. The trick here is to stub this out when the adapter is first called, 'stub this out ... ' - I don't understand, sorry. and then later during traversal, when you know the local components are there, you revisit it all again by calling request.setUpLocale() or whatever it is. I don't know what you mean. How is a noob supposed to deal with this? The ++lang++ implementation might give some pointers. The ++lang++ implementation (and ensuing errors when I tested using it) told me that I needed to change BrowserFormLanguages to use IModifiableUserPreferredLanguages. Since I had to do that in order to allow language preferences I decided to get the UserPreferences machinery running for the app. Now I have this problem. The *must* be a common use case. Why isn't this already solved and documented as a 'best practice' example? Mark ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
RE: [Zope3-Users] Re: User preferences for languages- possible?
Hi Giovanni Subject: RE: [Zope3-Users] Re: User preferences for languages- possible? [...] The *must* be a common use case. Why isn't this already solved and documented as a 'best practice' example? It's all done and implemented. Use the z3c.language package, there you'll find a INegotiator implementation, language session and views for switch the language. As Philipp already said, it's simpler to use a session for store user releated infos. The Preference is only needed if you like to store user related data over the time of a session. Regards Roger Ineichen Mark ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: User preferences for languages- possible?
Giovannetti, Mark wrote: The key, as you've correctly identified, is write your own IUserPreferredLanguages adapter (or a variant thereof). I would store the user's preferences in a cookie or a session. This makes things much easier. Simply adapt the request to ISession(request). I'll end up having to do something like this, I suppose. It really sucks, though, because I *want* to use the preferences machinery. Why was it built if it can't be used in certain places - and why aren't the places it can't be used documented? Arrg. Well, it's pretty simple, I've tried to outline it to you: No matter whether you're going the route with sessions or the route with the preferences machinery: Both need to store their information persistently somewhere. That's why they employ local, persistent utilities. Those are only available after certain things have happened: the database has been opened and the publisher has successfully traversed over the sites that contain registered versions of such utilities. Then and only then the getUtility calls work. The ComponentLookupError you were quoting in your original email is, I bet my ass on this, due to the fact that the languages adapter is invoked right when the request is instantiated, at which point none of the steps I outlined above have happened. Note that this might not always work, e.g. when the request is instantiated and the request's locale is first created (because local utilities to store the session data in aren't available at that point). How am I supposed to deal with what you say above? I don't even understand most of it! ;-) I'm sorry if I haven't been clear. I also suggest picking up a copy of my 2nd edition and reading through the chapter on local sites. It explains the concepts of local components. It seems you're hitting that exact problem with the preference stuff as well. The trick here is to stub this out when the adapter is first called, 'stub this out ... ' - I don't understand, sorry. and then later during traversal, when you know the local components are there, you revisit it all again by calling request.setUpLocale() or whatever it is. I don't know what you mean. How is a noob supposed to deal with this? The ++lang++ implementation might give some pointers. The ++lang++ implementation (and ensuing errors when I tested using it) told me that I needed to change BrowserFormLanguages to use IModifiableUserPreferredLanguages. Since I had to do that in order to allow language preferences I decided to get the UserPreferences machinery running for the app. Now I have this problem. I'll try to be a bit clearer now: * Your custom language adapter needs to gracefully deal with an absent preference machinery. In other words, you should catch that ComponentLookupError and fall back to whatever mechanism you want to fallback (I suggest you simply fall back to the super class's implementation). * If the preference stuff is correctly set up, normal views invoking the translation machinery will get your adapter, there will be no ComponentLookupError (because the local site with the persistent utilities is active). * The only problem lies in request.locale which has been initialized too early, when the local site wasn't active and when we caught that ComponentLookupError and simply ignored it. This should be revisited now. I recommend to write an event handler for IBeforeTraverseEvent for ISites that re-initializes request.locale. It would look something like this: from zope.component import adapter from zope.app.component.interfaces import ISite from zope.app.publication.interfaces import IBeforeTraverseEvent @adapter(ISite, IBeforeTraverseEvent) def reinitializeRequestLocale(site, event): event.request.setupLocale() Register that using subscriber handler=.reinitializeRequestLocale /. HTH -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
