From users-return-99661-apmail-cocoon-users-archive=cocoon.apache.org@cocoon.apache.org Wed Feb 15 18:36:35 2012 Return-Path: X-Original-To: apmail-cocoon-users-archive@www.apache.org Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 374CC95F1 for ; Wed, 15 Feb 2012 18:36:35 +0000 (UTC) Received: (qmail 93544 invoked by uid 500); 15 Feb 2012 18:36:34 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 93166 invoked by uid 500); 15 Feb 2012 18:36:33 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 92941 invoked by uid 99); 15 Feb 2012 18:36:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2012 18:36:33 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [76.96.62.64] (HELO qmta07.westchester.pa.mail.comcast.net) (76.96.62.64) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2012 18:36:26 +0000 Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id aJbW1i0041ap0As57Jc5rT; Wed, 15 Feb 2012 18:36:05 +0000 Received: from Christophers-MacBook-Pro.local ([69.143.109.145]) by omta22.westchester.pa.mail.comcast.net with comcast id aJc51i00N38FjT13iJc5dV; Wed, 15 Feb 2012 18:36:05 +0000 Message-ID: <4F3BFB14.8040006@christopherschultz.net> Date: Wed, 15 Feb 2012 13:36:04 -0500 From: Christopher Schultz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: users@cocoon.apache.org Subject: Re: Using I18NTransformer with Dynamic Locales References: <4ED7B012.2080608@christopherschultz.net> <4ED93D76.2060105@anyware-services.com> In-Reply-To: <4ED93D76.2060105@anyware-services.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cédric, On 12/2/11 4:04 PM, Cédric Damioli wrote: > Le 01/12/2011 17:49, Christopher Schultz a écrit : >> All, >> >> I'd like to start using the I18NTransformer so I can localize >> the output of my XSLTs. We have what I believe to be a somewhat >> unique situation with regard to the actual source of the locale >> information. >> >> Here goes: >> >> We have Cocoon set up as a webapp all by itself, separate from >> our "real" webapp. Our pipelines take incoming HTTP requests and >> essentially forward them, with modifications of course, to our >> "real" webapp that produces XML for consumption by Cocoon. The >> Cocoon webapp does not maintain session state of any kind: it >> merely forwards requested session ids from the incoming request >> through the outgoing request to the "real" webapp. >> >> The "real" webapp knows what the user's preferred Locale is, and >> can provide that information back to Cocoon if necessary. We have >> lots of options: HTTP response headers, something in the XML >> document returned, etc. >> >> Unfortunately, I'm not sure how to get any of those data when >> calling the I18N transformer itself. >> >> Can anyone offer any suggestions? >> >> If I can't come up with anything else, I'll have to encode the >> locale in each request's URL which, while doable, will likely be >> fragile and a total PITA to actually accomplish. >> >> Thanks, -chris > > The locale of the I18nTransformer may be set a sitemap parameter : > value="XXXX"/> > > In this cas, the actual locale value may be computed in a > surrounding action : > > > > > where the "proxy" action actually proxy the request to your "real" > webapp, get the responses header you mentionned and put it in the > result map. I've considered this approach and I definitely think it will work. However, I'm wondering if I can avoid another round-trip to the original server that is producing the XML document currently being processed. I can alter this XML document to contain the locale itself if that's any help. Is there a way to extract a piece of information from the event stream and use *that* as a variable for the pipeline? Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk87+xQACgkQ9CaO5/Lv0PB9RACeJbi86fHX4xA2HyYipOcnBxtk ohoAn0+btE5WUBwcW7E8LXVUi4DdST3T =Pnci -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org For additional commands, e-mail: users-help@cocoon.apache.org