Re: [Catalyst] Multilanguage application

2006-08-25 Thread Daniel McBrearty
sub lang : Chained('/') CaptureArgs(1) PathPart(''){
  my ($self, $c, $lang) = @_;

  # need to check that $lang is valid and handle that here
  if (valid($lang)) {
} else {
}

}

sub doit : Chained('lang') Args(0) {
my ($self, $c) = @_;
}

this now matches /*/doit, and doit needs to be able to rely on the
language being in the stash.

in fact there are a number of ways the language can be detected. For
me, these are (highest priority first) ... :

1. the uri
2. the session (maybe, i'm thinking about this ... the argument is
that the user shouldn't have to manually set the language twice while
a cookie persists).
3. the browser settings.

so we need to try these in turn ... as soon as we get a valid value,
set it in the session/stash where all downstream actions get it.



On 8/10/06, Matt S Trout [EMAIL PROTECTED] wrote:
 Renaud Drousies wrote:
  On Thu, August 10, 2006 4:39 pm, Matt S Trout said:
  sub lang :Chained('/') :CaptureArgs(1) :PathPart('') {
 my ($self, $c, $lang) = @_;
 set lang appropriately
  }
 
  sub foo :Chained('/lang') :Args(0) { # /en/foo etc.
 
  Chained was designed to support this sort of stuff without the need for
  prepare_path hacks, which I've used before but always found a tad ugly.
 
 
  But then I am not sure to understand how to dispatch actions correctly to
  different controllers. This looks like all actions must be defined in the
  same controller.

 No, that sub foo could be in any controller.

  If I have that 'sub lang' in my Root controller, how can I reach my
  original 'sub index: Private' in MyApp::C::Foo (or any other action
  defined there) so that the Foo controller is used when I request /en/foo?

 read the Catalyst::DispatchType::Chained POD first. If you still have
 questions, ask 'em then :)

 ___
 List: Catalyst@lists.rawmode.org
 Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
 Dev site: http://dev.catalyst.perl.org/



-- 
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com : the multi - language vocab trainer
BTW : 0873928131

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Multilanguage application

2006-08-25 Thread A. Pagaltzis
* Daniel McBrearty [EMAIL PROTECTED] [2006-08-25 12:10]:
 in fact there are a number of ways the language can be
 detected. For me, these are (highest priority first) ... :
 
 1. the uri
 2. the session (maybe, i'm thinking about this ... the argument
 is that the user shouldn't have to manually set the language
 twice while a cookie persists).
 3. the browser settings.

Using the session and browser settings are fine; but best is if
you implement them using redirection.

Ie. when someone visits the site, and their session says they
want French, you redirect them to `/fr/$whatever`.

Ideally, only the front page of the site has a language-less URI,
and only there do you redirect. Then whatever other URI they
might bookmark will always have a language code, so on subsequent
pages the problem doesn’t come up at all.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Multilanguage application

2006-08-25 Thread Daniel McBrearty
that's what I'm thinking AP. cheers.

lang Chained('/) looks in the uri. If it succeeds, it sets
stash/session too. If it fails it redirects to /default which checks
session and redirects, or browser then set session and redirect. If
all else fails show a chooser page.



On 8/25/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
 * Daniel McBrearty [EMAIL PROTECTED] [2006-08-25 12:10]:
  in fact there are a number of ways the language can be
  detected. For me, these are (highest priority first) ... :
 
  1. the uri
  2. the session (maybe, i'm thinking about this ... the argument
  is that the user shouldn't have to manually set the language
  twice while a cookie persists).
  3. the browser settings.

 Using the session and browser settings are fine; but best is if
 you implement them using redirection.

 Ie. when someone visits the site, and their session says they
 want French, you redirect them to `/fr/$whatever`.

 Ideally, only the front page of the site has a language-less URI,
 and only there do you redirect. Then whatever other URI they
 might bookmark will always have a language code, so on subsequent
 pages the problem doesn't come up at all.

 Regards,
 --
 Aristotle Pagaltzis // http://plasmasturm.org/

 ___
 List: Catalyst@lists.rawmode.org
 Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
 Dev site: http://dev.catalyst.perl.org/



-- 
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com : the multi - language vocab trainer
BTW : 0873928131

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] [ANNOUNCE] Catalyst::Plugin::ConfigLoader 0.13

2006-08-25 Thread Brian Cassidy
Hello All,

I've just put out a new release of the ConfigLoader plugin. Nothing on 
the surface has changed. Underneath, however, the guts of the config 
file loading has been extracted out into a separate module: Config::Any. 
Hopefully other apps and/or modules will find this new package useful.

Special thanks goes out to Joel Bernstein who did the work on 
ConfigLoader and Config::Any, and Portugal Telecom for sponsoring this work.

Changes file:

0.13  Fri Aug 25 2006
- loading code factored out into Config::Any [EMAIL PROTECTED]
  sponsored by Portugal Telecom

-Brian

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Special characters and MySQL issue

2006-08-25 Thread Tobias Kremer
I have my content-type header set to ISO-8859-1 because I'm dealing with
legacy data from a latin1 encoded MySQL database (otherwise data from the
database is not displayed correctly in the browser). There's a form on my
site for searching users by attribute. Now here's the problem:

Doing a search where, for instance, firstname = Müriam (note the
German umlaut) the search result contains users with a firstname of
Myriam (note the y instead of the german umlaut). I tried to trace down
the problem but was unable to really figure out what is going wrong. The
data from the form is URL-escaped correctly to M%FCriam. I tried putting
the following in the controller handling the request:

$c-log-warn( $c-request-param( 'value' ) );

and it spits out:

[warn] M
(note that everything after the german umlaut is missing - maybe just a
console problem?)

I access the model like this:

my $rs = $model-search_like( {
  $c-request-param( 'attribute' ) = $c-request-param( 'value' )
} );

The mysql query log shows the search string as:

SELECT [...] WHERE [...] LIKE 'M\xfcriam'

Entering a query with this search string manually into the mysql console
client yields no results - as expected because there is no user with a
firstname of Müriam.

Any ideas on what's going on here? :)

Thanks in advance for any help!

Toby

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Special characters and MySQL issue

2006-08-25 Thread Jonathan Rockway
What happens if you 'use encoding iso-8859-1' at the top of the script
that accepts this data?

BTW my suggestion is to not send latin-1 to the browser.  Use the
Encode module to convert from latin-1 bytes to perl characters, and
then use the C::P::Unicode module to send UTF-8 to the browser.  When
the request comes in, it will be in UTF-8, and C::P::Unicode will decode
the UTF-8 octets to perl characters.  When you're talking to the
database, use Encode to encode perl characters to latin-1.  This will
throw an exception when you get invalid characters (like the umlaut).
Since your database can't handle umlauts, I think this is a better
result than returning random rows (or no rows at all).

I can be more detailed if you want, just let me know.

Relevant documentation:

perldoc utf8
perldoc encoding
perldoc Encode
man perluniintro
man perlunicode
man perllocale

Good luck.  And remember that utf8::encode decodes, and utf8::decode
encodes.  That took me a while to understand.

(decode takes UTF-8 octets and encodes them to perl characters)
(encode takes perl characters and decodes them to UTF-8 octets)

Regards,
Jonathan Rockway

Tobias Kremer wrote:
 I have my content-type header set to ISO-8859-1 because I'm dealing with
 legacy data from a latin1 encoded MySQL database (otherwise data from the
 database is not displayed correctly in the browser). There's a form on my
 site for searching users by attribute. Now here's the problem:

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/