[Catalyst] Multi-language and REST
I have been pondering how to take an existing Catalyst application and make it multi-lingual. I would prefer to use a RESTful method, so this would translate /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French respectively). The problem as I see it is how to do this. I don't want to move all my controllers, e.g. MyApp::Controller::Foo::Bar to MyApp::Controller::Lang::Foo::Bar What other alternatives are there? Regards Ian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
On Friday 25 April 2008 14:44:38 Ian Docherty wrote: I have been pondering how to take an existing Catalyst application and make it multi-lingual. I would prefer to use a RESTful method, so this would translate /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French respectively). The elegang solution is to make use of the request header Accept-Language, but not many users know how to change this setting in their browsers. http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12 The problem as I see it is how to do this. I don't want to move all my controllers, e.g. MyApp::Controller::Foo::Bar to MyApp::Controller::Lang::Foo::Bar What other alternatives are there? Regards Ian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Knut-Olav Hoven Systemutvikler mob: +47 986 71 700 Linpro AShttp://www.linpro.no/ signature.asc Description: This is a digitally signed message part. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
Ian Docherty wrote:
I have been pondering how to take an existing Catalyst application and
make it multi-lingual.
I would prefer to use a RESTful method, so this would translate /foo/bar
to /en/foo/bar or /fr/foo/bar (for English and French respectively).
The problem as I see it is how to do this. I don't want to move all my
controllers, e.g. MyApp::Controller::Foo::Bar to
MyApp::Controller::Lang::Foo::Bar
What other alternatives are there?
Regards
Ian
Well, I'm sure there's a somewhat elegant way to do this with Chained,
but it the other controllers don't use Chained now, that could get fun.
The brute force way is to inspect the request and rip out the language
portion before sending it on to get dispatched...just like the Flavour
plugin does with file extensions:
sub prepare_path {}
signature.asc
Description: OpenPGP digital signature
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
On Fri, Apr 25, 2008 at 01:44:38PM +0100, Ian Docherty wrote: I have been pondering how to take an existing Catalyst application and make it multi-lingual. I would prefer to use a RESTful method, so this would translate /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French respectively). The problem as I see it is how to do this. I don't want to move all my controllers, e.g. MyApp::Controller::Foo::Bar to MyApp::Controller::Lang::Foo::Bar I check if the prefix is a valid language (if it's one of the language files I loaded at startup), if so I then remove it from the request path and append it to the request base. -- Bill Moseley [EMAIL PROTECTED] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
Christopher H. Laco wrote:
Ian Docherty wrote:
I have been pondering how to take an existing Catalyst application
and make it multi-lingual.
I would prefer to use a RESTful method, so this would translate
/foo/bar to /en/foo/bar or /fr/foo/bar (for English and French
respectively).
The problem as I see it is how to do this. I don't want to move all
my controllers, e.g. MyApp::Controller::Foo::Bar to
MyApp::Controller::Lang::Foo::Bar
What other alternatives are there?
Regards
Ian
Well, I'm sure there's a somewhat elegant way to do this with Chained,
but it the other controllers don't use Chained now, that could get fun.
I have considered chained, and would be prepared to re-write the
existing controllers. A bigger decision would be renaming the
controllers or moving them.
e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar
To match against /lang/foo/bar either I can leave the controller where
it is (lib/MyApp/Controller/Foo/Bar.pm) or move it
(lib/MyApp/Controller/Lang/Foo/Bar)
The first approach is less work (only using chained) the second is more
work, but maps the URI namespace more logically to the Class names.
What would people do if they were writing a Catalyst App from scratch
with this feature? That would tell me what the 'best practice' is even
if it means a big re-write exercise.
The brute force way is to inspect the request and rip out the language
portion before sending it on to get dispatched...just like the Flavour
plugin does with file extensions:
sub prepare_path {}
One of my pet peeves is exemplified in the 'Flavour' plugin. It is such
minimal documentation that it neither tells you what it does or why it
does it. OK, I can look at the code, but it is too much effort unless I
think I have a good reason to do so. I assume in this case that it is
something to do with date strings in the URI (for blogging?). I can't be
ar**d!
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Dispatching based on path and host/domain
On Wed, Apr 23, 2008 at 10:56:07PM +0200, Aristotle Pagaltzis wrote:
* Matt S Trout [EMAIL PROTECTED] [2008-04-23 21:40]:
On Wed, Apr 23, 2008 at 03:25:47PM +0100, Curtis Fletcher wrote:
Digging around, is it a sane thing to have:
__PACKAGE__-_action_class('Catalyst::Action::MyAction');
At the top of a controller if I want all of the methods to
use the same non-default ActionClass? I'm nervous about using
anything that starts with _
It starts with _ because you should never call it from
-outside- the class.
You're fine calling it on your own class.
So if I want to use a particular Action class as the default for
all my actions, I can do that by creating my own controller base
class where I put that at the top and then have my controllers
inherit from that instead of directly from Catalyst::Controller?
Yes.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
On Fri, 25 Apr 2008, Ian Docherty wrote: http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12 Yes, I have done this previously, it is elegant, but not RESTful and does not make it easy for users to change their settings on a site-by-site basis dynamically, as you could if you provided a language selection box on each page. Why do you say it's not RESTful? I think it's very RESTful, but it depends on how you think about it. If the language of the content is basically an issue of formatting, then switching language based on a header is perfect. The client provides sufficient information to produce a correct response _on each request_ as part of HTTP. This is basically the essence of REST. OTOH, if you consider each language's content fundamentally separate things, then each language should have its own set of URIs. -dave /*== VegGuide.Org Your guide to all that's veg ==*/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Multi-language and REST
* Ian Docherty [EMAIL PROTECTED] [2008-04-25 16:25]: Knut-Olav Hoven wrote: The elegang solution is to make use of the request header Accept-Language, but not many users know how to change this setting in their browsers. http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12 Yes, I have done this previously, it is elegant, but not RESTful Please educate yourself about what “RESTful” means before you make more claims about things not being so. (Note I’m not saying Accept-Language is the right solution here. Personally I think content negotiation in HTTP is missing a few nuts and bolts to make it useful for non-trivial uses (which is basically synonymous with “in human-operated browsers”).) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
Dave Rolsky wrote: On Fri, 25 Apr 2008, Ian Docherty wrote: http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12 Yes, I have done this previously, it is elegant, but not RESTful and does not make it easy for users to change their settings on a site-by-site basis dynamically, as you could if you provided a language selection box on each page. Why do you say it's not RESTful? I think it's very RESTful, but it depends on how you think about it. If the language of the content is basically an issue of formatting, then switching language based on a header is perfect. The client provides sufficient information to produce a correct response _on each request_ as part of HTTP. This is basically the essence of REST. OTOH, if you consider each language's content fundamentally separate things, then each language should have its own set of URIs. Yes, this is exactly what I had in mind. I did not (and still don't) consider the language of the content as 'formatting', the content for each language is different (in my mind). I don't really want this to start another flame-war about RESTful etc. this point is outside of my original request so I won't respond (on list) to this off-topic subject any more. Regards Ian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
Dave Rolsky wrote: On Fri, 25 Apr 2008, Ashley wrote: I agree that it's content, not formatting. If CSS/client-side-JS can (in a practical fashion) change it, it's formatting, otherwise, it's content. I should have used the word representation. With REST, you'd have the same URI for one resource, but you might offer it as HTML, JSON, and plain text based on what the client requests. Given the Accept-Language header, you could do the same thing with language. -dave Could and should. I've taken the approach using the REST controller that if anyone wants to get at a resource easier (easier to alter the uri than the headers), then use the content-type query param. I think the same should be true for language. If changing Accept-Language is too much, (or people want to view a language other than their native), then look at language= in the query params first..if it's empty...honor Accept-Language... rather than forcing /lang/ at the front of all urls. signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
On Apr 25, 2008, at 10:28 AM, Christopher H. Laco wrote: If changing Accept-Language is too much, (or people want to view a language other than their native), then look at language= in the query params first..if it's empty...honor Accept-Language... rather than forcing /lang/ at the front of all urls. I like the idea (and you could even cookie language prefs instead of a query string solution which would be more expensive/complex with the URI rewrites) but giving up a large chunk of one's search engine results for a more purist interface is a pretty high price. As of last year (haven't checked recently) the googlebot couldn't even correctly index pages served as application/xhtml. Some bots might do the right thing with headers for their target language base(s) but I doubt it's many, if even a minority, of them yet. It's not a transport issue (like HTML/PDF/JSON/XML/etc) which makes perfect sense for header control because the clients and client-side stuff is being written now in tandem, it's different content and the target clients are laden with legacy behavior. I like PUT and DELETE too but I'm not going to abandon POST as their stand-in (or fall- back) any time soon. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Multi-language and REST
Christopher H. Laco wrote:
Ian Docherty wrote:
Christopher H. Laco wrote:
Ian Docherty wrote:
I have been pondering how to take an existing Catalyst application
and make it multi-lingual.
I would prefer to use a RESTful method, so this would translate
/foo/bar to /en/foo/bar or /fr/foo/bar (for English and French
respectively).
The problem as I see it is how to do this. I don't want to move all
my controllers, e.g. MyApp::Controller::Foo::Bar to
MyApp::Controller::Lang::Foo::Bar
What other alternatives are there?
Regards
Ian
Well, I'm sure there's a somewhat elegant way to do this with
Chained, but it the other controllers don't use Chained now, that
could get fun.
I have considered chained, and would be prepared to re-write the
existing controllers. A bigger decision would be renaming the
controllers or moving them.
e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar
To match against /lang/foo/bar either I can leave the controller
where it is (lib/MyApp/Controller/Foo/Bar.pm) or move it
(lib/MyApp/Controller/Lang/Foo/Bar)
The first approach is less work (only using chained) the second is
more work, but maps the URI namespace more logically to the Class names.
What would people do if they were writing a Catalyst App from scratch
with this feature? That would tell me what the 'best practice' is
even if it means a big re-write exercise.
The brute force way is to inspect the request and rip out the
language portion before sending it on to get dispatched...just like
the Flavour plugin does with file extensions:
sub prepare_path {}
One of my pet peeves is exemplified in the 'Flavour' plugin. It is
such minimal documentation that it neither tells you what it does or
why it does it. OK, I can look at the code, but it is too much effort
unless I think I have a good reason to do so. I assume in this case
that it is something to do with date strings in the URI (for
blogging?). I can't be ar**d!
It does just what just what Bill suggested.
I check if the prefix is a valid language (if it's one of the language
files I loaded at startup), if so I then remove it from the request
path and append it to the request base.
In prepare_path.. you inspect the requested path.. yank out the
language.. then pass along the remaining path...which should map to
your existing controllers just fine.
I have actually taken a look at the Flavour plugin (can't see for the
life of me why it is called that!) and it gives an example of yanking
off the //mm/dd at the start of a path, putting the values into
accessors of flavour (e.g. $c-flavour-year) leaving the rest of the
path to be processed as normal. This is pretty much what I want to do
for the language so thanks for pointing out the plugin to me.
I am pretty confident that I can now write a plugin to strip out a
language from the start of a path in the same way.
Looking at the Catalyst best practices, am I going to be polluting the
catalyst namespace by writing this as a plugin? I can't see any
alternative (making it a base Controller is actually what I am trying to
avoid).
Any suggestions as to a namespace for this? Catalyst::Plugin::LangURI
perhaps?
As far as chained goes... I thought there was an example floating
around that has Root::lang as Chained, then all other modules Chaine
against /lang as their root instead of /...
I should not need this if I do the above then I can leave my existing
controllers unchanged (and unchained).
-=Chris
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Multi-language and REST
* Ashley [EMAIL PROTECTED] [2008-04-25 22:20]: I like PUT and DELETE too but I'm not going to abandon POST as their stand-in (or fall-back) any time soon. http://search.cpan.org/dist/Catalyst-Request-REST-ForBrowsers/ autarch++ Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Multi-language and REST
On Fri, 25 Apr 2008, Aristotle Pagaltzis wrote: * Ashley [EMAIL PROTECTED] [2008-04-25 22:20]: I like PUT and DELETE too but I'm not going to abandon POST as their stand-in (or fall-back) any time soon. http://search.cpan.org/dist/Catalyst-Request-REST-ForBrowsers/ autarch++ Thanks. This module illustrates what I'm trying to adopt as a general principle of my REST development. Browsers suck, but that doesn't mean the internals of my app need to suck as well. You can design the core of your app using strict REST principles, and then put some shims around the edges to handle the real world. This has the side benefit of giving your app a nice clear internal structure. In my controllers, I still have methods like user_PUT, user_DELETE, users_POST, etc. If you know REST, you probably have a _really_ good idea of what those do. For the language stuff, you could do something like have a plugin that stripped out a language prefix from the URI early on, and then set something in the request. Better yet, you might do something like this: * check for a URI prefix * then check Accept-Language Of course, any sort of URI fixup scheme involves some burden on the part of the application to generate the right URIs. -dave /*== VegGuide.Org Your guide to all that's veg ==*/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Fri, 2008-04-25 at 15:53 +0100, Matt S Trout wrote: There's no written standard currently; I'd love to see somebody take a crack at writing one but I'm not sure what would need to go in it. I've attached a draft based on some of our company procedures to show the sorts of things that need to be addressed. I've changed a few things to reflect some of the Catalyst conventions that I am aware of but it will need your input, particular w.r.t. any conventions from PBP that you disagree with. having this interesting discussion. Can we put a timescale on it? What is the plan for release of 5.7013 and/or 5.80? Next week or two would be ideal; if you can't make time that soon then you need to say -now- so somebody else can fix this. I'd need 2-3 weeks as the next week and a half is out and I'm concerned about the time it will take to review the original code to check the subtleties, and then write new tests. The code itself is only a few minutes work... -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo (Proposed) Catalyst Coding Standards and Policies This document outlines the standards and policies for contributing to the Catalyst Project and attempts to capture the conventions that the project team has chosen to use to ensure that the quality and consistency of the code base is maintained. The project greatly benefits from the many contributors in the Catalyst community, and in turn the wider Catalyst community benefits from consistent and reliable code through adherence to these agreed standards. Any questions or clarifications regarding this document should be directed to the Catalyst mailing list. These standards are to be applied for core Catalyst development and are recommended for use with plugins and other contributed code. 1. Coding Standards 1.1. Perl Best Practices (Oreilly, Conway) should be followed unless otherwise noted here. 1.2. All code shall be clear of perlcritic warnings (at severity level 5), with the following exemptions: 1. Stricture disabled at line ... See page 429 of PBP. (Severity: 5) This warning is acceptable providing the 'no strict ...' is applied within the minimum scope necessary. (perlcritic does not seem to be able to reliably recognise minimum scope). 1.3 Indentation Use 4-space indentation. Hard tabs are prohibited. 2. Documentation Standards Please familiarise yourself with the Perl Best Practices description of types of documentation. 2.1 All User API functions shall have appropriate documentation suitable for end users of the API. These should appear in perldoc. 2.2 Documentation associated with functions and methods that are not part of the User API shall be as follows: - private functions and methods (as identified by a leading underscore in the function/method name) shall have any documentation in comments so as to not appear in perldoc. - internal functions and methods (meant for use within the same package only) shall be flagged as such and have documentation in comments so as to not appear in perldoc. - internal functions and methods that are not for general users buy may be used by extensions (which may be packaged separately, such as derived classes or plugins) should appear in perldoc, clearly identified as Developer API methods. 3. Testing Guidelines Write the documentation for your API functions to adequately define the inputs and expected outputs. Then write tests that match. * Each module should have at least one corresponding file in the 't/' test directory. Permissible exceptions: o where the module is trivial, such that it can be adequately tested by code inspection o where the module requires external infrastructure (e.g. a remote website) which is unreasonable to duplicate; in this case it may be more appropriate to add a working example into the 'examples/' subdirectory. Make sure that everything that can be reasonably tested through a regression test, is; this might mean splitting the module, placing the reusable, testable components in their own modules and keeping the application level code that requires the external infrastructure separate. o modules which only include configuration data for a suitably tested parent class may not need their own tests * All public methods (user and developer API methods) should be tested. Permissible exceptions: o where the method is inherited and suitably tested in the parent class o where the method is created through configuration of a suitably tested parent (such as accessors created using Class::Data::Inheritable or Class::Accessor) * Testing of private/protected methods may be appropriate when sufficient test coverage is difficult to achieve when testing
