Re: [Catalyst] Re: Language selection in URLs

[Michele Beltrame]

Hello!


why shouldn't you use domain as the part of the language? like
en.example.com, cn.example.com and something like that?

Thanks.


Because each sub-domain would require another SSL key (or a special
group SSL key that can be used with more subdomains.


Moreover, I don't see that great advantage (not even in elegance) in using:

http://en-gb.mysite.com/resource/list

instead of:

http://mysite.com/en-gb/resource/list

If you're using the Chained dispatching, it's very straightforward to 
map the secondo URL to a language.


Michele.

--
Michele Beltrame
http://www.italpro.net/ - m...@italpro.net
Skype: arthas77 - Twitter: _arthas

___
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] Catalyst & E-Commerce

[goetz]

Hi,

just have a look at Interchange  (http://www.icdevgroup.org/i/dev).
I worked for some projects with this fantastic program and it has a very 
helpfull 
community - well its perl ;).
Maybe it would be possible for some perl gurus to link these projects together?

A marriage between Interchange and Catalyst would be very helpfull for perl ! 

Regards

Götz





Am 17.11.2009 um 16:03 schrieb J. Shirley:

> On Mon, Nov 16, 2009 at 11:09 PM, pro...@gmail.com  wrote:
> I asked this exact same question a couple of weeks ago: 
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg08108.html. I am 
> still hoping to glean some wisdom from more seasoned catalyst users on this 
> list! It would be wonderful to get some ideas/guidance on e-commerce+catalyst.
> 
> 
> On Tue, Nov 10, 2009 at 5:11 PM, Pavel O. Korovkin  wrote:
> Hello,
> 
> After looking around I've found Handel and built on top of it Mango.
> Is there any other e-commerce modules/solutions/etc based on Catalyst?
> Who uses Mango&Handel in their own project - can comment anything?
> Both projects seems to be non actively developed. Is it means dead-end
> or perfect solution? =) Well, anything on e-commerce and catalyst is
> very appreciated!
> 
> 
> Regards,
> Pavel
> 
>  
> I've never used Handel, or really looked into it (nor Mango).  I can tell you 
> that most people will just roll their own ecommerce implementation, and there 
> are plenty of CPAN modules to make it very easy to do so.
> 
> I think the general philosophy here, or at least one that I hold, is that it 
> is just as easy to build your own ecommerce site with the available tools 
> than it would be to customize a framework-based system.  If you don't need 
> customization there are also plenty of tools out there to build up a 
> store-front.
> 
> If you do opt to go the DIY route, here are some tips for building it:
>  * Use Catalyst::Action::REST for CRUD, simplifying your code by delegating 
> to _POST actions
>  * DBIx::Class for the ORM
>  * DBIx::Class::EncodedColumn for encrypting your credit card fields
> 
> Myself and gphat are working on Business::Payment, a Moose-y role based 
> implementation for processing credit cards.  I've written an Authorize.NET 
> handler that works quite well.  You can snag this from github at:
> 
> http://github.com/gphat/Business-Payment/
> http://github.com/jshirley/Business-Payment-AuthorizeNet
> 
> -J
> ___
> 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/

___
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] Catalyst & E-Commerce

[Tomas Doran]

goetz wrote:
A marriage between Interchange and Catalyst would be very helpfull for 
perl ! 


Well volunteered.

Cheers
t0m

___
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: Language selection in URLs

[Aristotle Pagaltzis]

* Joel Bernstein  [2009-11-15 16:30]:
> No no no! Allow the client and server to negotiate what content
> to serve for the resource identified. As a URI to a resource
> which may vary according to many dimensions,
> /path/to/some/content is fine.
>
> GET /path/to/content HTTP/1.1
> Accept-Language: en
> Accept: text/html

Conneg sucks. It’s a good idea for non-human-readable content
served in a variety of formats, but for variants of anything
that’s like a “page” you should have separate URIs, so that
people can reliably bookmark one of them, or send someone else
a link to talk about it and not have the other person see
a completely different page (or file or whatever), etc.

It’s OK to accept conneg on neutral URIs and then *redirect* to
specific URIs based on the Accept-* headers. But don’t make
conneg the *only* way to pick a specific version of a resource.

> They are different *representations* of the same *resource*.

They are almost never *exact* equivalents. There are almost always
slight differences in content depending on language. _The medium
is the message._

And there is no reason not to have more than one URI for the same
resource anyway. Yes, you should pick one of them as canonical,
and unless you have good reason for doing otherwise, all the non-
canonical URIs be redirects. But these are merely good ideas, not
hard and fast rules.

> If you really must stick it in the URL, I'd go for something like:
> /path/to/content/en
> /path/to/content/pt_BR
> etc

Worst of all worlds, IMO. The query parameter is easiest to
implement for the server, while the path prefix allows the user
to hack the URI conveniently (so the latter is what I would do).
Your suggestion is harder to implement than both and makes URIs
annoying to hack.

Regards,
-- 
Aristotle Pagaltzis // 

___
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: Language selection in URLs

[Bill Moseley]

On Wed, Nov 18, 2009 at 9:55 AM, Aristotle Pagaltzis wrote:

> * Joel Bernstein  [2009-11-15 16:30]:
> > No no no! Allow the client and server to negotiate what content
> > to serve for the resource identified. As a URI to a resource
> > which may vary according to many dimensions,
> > /path/to/some/content is fine.
> >
> > GET /path/to/content HTTP/1.1
> > Accept-Language: en
> > Accept: text/html
>
> Conneg sucks. It’s a good idea for non-human-readable content
> served in a variety of formats, but for variants of anything
> that’s like a “page” you should have separate URIs, so that
> people can reliably bookmark one of them, or send someone else
> a link to talk about it and not have the other person see
> a completely different page (or file or whatever), etc.
>
> It’s OK to accept conneg on neutral URIs and then *redirect* to
> specific URIs based on the Accept-* headers. But don’t make
> conneg the *only* way to pick a specific version of a resource.
>

I think this is very good advice.



>
> > If you really must stick it in the URL, I'd go for something like:
> > /path/to/content/en
> > /path/to/content/pt_BR
> > etc
>
> Worst of all worlds, IMO. The query parameter is easiest to
> implement for the server, while the path prefix allows the user
> to hack the URI conveniently (so the latter is what I would do).
> Your suggestion is harder to implement than both and makes URIs
> annoying to hack.
>

I think Catalyst makes the path prefix the easiest.  WIth the query
parameter (which I'm doing now to be compliant with a legacy app) it's
trivial to by using "around uri_for", but I'd much rather do something once
(modify $->req->base) than override every uri_for.

I do have a slight fear of the query parameter messing with caching.  I
doubt it's much of an issue these days, though.


-- 
Bill Moseley
mose...@hank.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/