[Catalyst] HTTP::Body, utf8 filenames, and escaped strings.

[Bill Moseley]

When I upload files via a browser utf8 file names are passed directly
as utf8.

I'm using a java applet also for file uploads.  When it uploads a file
with a utf8 filename the name is uri-escaped.

Is it correct behavior to uri-escape the filename?

I'm thinking it's not correct behavior - because I can upload a file
with %-escapes with Firefox and they are uploaded un-changed (the
percent+digits stay in the filename).

But, if it is valid, should HTTP::Body automatically uri_unescape the
Multipart headers?

How does one determine the charset/encoding of the "filename" passed
in the multipart upload?

I'm wondering if HTTP::Body should decode the headers as they are
parsed.



-- 
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] So, what do we want in the -next- book?

[Peter Karman]

[EMAIL PROTECTED] wrote on 4/28/08 4:15 PM:



Pick one or two app topics and let people extend and create -- then talk
about what they did in a advent sort of way.



++

One project I often hear repeated is a Cat-based alternative to Trac, using 
SVN::Web, RT, some wiki (MojoMojo?), etc.


--
Peter Karman  .  http://peknet.com/  .  [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] So, what do we want in the -next- book?

[Wade . Stuart]

Andrew Kornak <[EMAIL PROTECTED]> wrote on 04/28/2008 03:19:39 PM:

> Personally, I would like any book on Catalyst, even if it was only a
> single chapter in a larger MVC treatment. I bought Jonathan's book and
> contrary to another poster's opinion found it quite useful.
>
> -Andrew


  Hopefully I do not derail this thread (is that possible?), but how
about concentrating on something that is more likely to happen.  Such as a
concentrated effort to have a large(er) (complicated) example app that uses
Cat in "best practices" mode.  I am not talking 25 examples at different
stages (or targeted towards old updated Cat styles -- see svn),  but one or
two large apps that everyone can work towards extending.  Showing different
real world coding issues.  Then take next years Advent and target pieces of
these real world examples picking apart how sections work,  why they were
constructed in a certain way etc. That seems like a goal that will allow a
better overall base for people to work on.  Pushes conversations about best
practice (via code review and check ins merges) and designs. and is an
orchestrated effort to self document by example.

Pick one or two app topics and let people extend and create -- then talk
about what they did in a advent sort of way.

-Wade





>
> On Mon, 2008-04-28 at 10:03 -0500, Mitch Jackson wrote:
> > I'd like to see a walkthrough of good MVC separation in practice.
> > This took me a while to get through my stubborn skull, and would be
> > good material to a new Catalyst developer.  My first few Cat apps
> > suffered heavily from having too much logic in the controllers.
> >
> > The example could look something like this:
> > - Put this logic into a model method and why
> > - Build a .t file to test the model method ( possibly include
> > deploying and testing against a mock database )
> > - Build a .pl file, outside the catalyst web app that uses the method
> > - Finally, use the method from your catalyst action
> >
> > This not only suggests good practice to the reader, but shows them how
> > to do it properly and gives them hands-on with the benefits of the
> > approach.
> >
> > /Mitchell K. Jackson
> >
> > On Sat, Apr 26, 2008 at 7:01 PM, Ian Sillitoe <[EMAIL PROTECTED]> wrote:
> > > So as I said - I contacted O'Reilly to request info/submit interest
in a
> > > Catalyst Cookbook/Best Practices. I've been in contact with a chap
called
> > > Andy Oram who seems to be O'Reilly's Perl Guy (FWIW he also seems a
nice,
> > > but very busy, guy). I was waiting for him to give me the nod
> before posting
> > > the following thread to the mailing list...
> > >
> > >
> > > 
> > >
> > >
> > > I just had a moment to reply. You can post my reply to the mailing
list--I
> > > do appreciate that you asked first. Results of my asking around are
> > > discouraging. I will try to do some more research next week, butthis
is a
> > > busy time for me. (I have only 6 days at home during the whole month
of
> > > April.)
> > >
> > >  Andy
> > >
> > >  - Original Message -
> > >  From: "Ian Sillitoe" <[EMAIL PROTECTED]>
> > >  To: "Andy Oram" <[EMAIL PROTECTED]>
> > >  Sent: Thursday, April 17, 2008 4:28:34 AM (GMT-0500)
America/New_York
> > >  Subject: Re: Catalyst Cookbook/Best Practices
> > >
> > >  Andy,
> > >
> > >  Thanks for getting back to me. It would obviously be nice to see
> > >  O'Reilly give Catalyst the full "Best Practices" treatment, however
as
> > >  you say, a more simple "Catalyst Cookbook/Hacks" book of code
snippets
> > >  would presumably be much easier to produce/edit and therefore more
> > >  likely to happen. The Catalyst POD docs are already pretty good and
> > >  will undoubtably continue to improve. However most Catalyst
> > >  developers, i.e. the people that would actually fork out money (or
get
> > >  their employers to fork out money) to buy the book, would probably
be
> > >  very happy just to get the interesting snippets in lots of different
> > >  case scenarios.
> > >
> > >  Also, I was going to post the reply you gave on the Catalyst mailing
> > >  list - but it feels a bit rude without at least asking you first -
any
> > >  objections?
> > >
> > >  Lots of people would be really interested in any further
developements
> > >  so if you had a chance to update me when you hear anything, I would
be
> > >  really grateful.
> > >
> > >  Regards,
> > >
> > >  Ian
> > >
> > >
> > >  -- Forwarded message --
> > >  From: Andy Oram <[EMAIL PROTECTED]>
> > >  Date: Wed, Apr 16, 2008 at 11:46 PM
> > >  Subject: Catalyst Cookbook/Best Practices
> > >  To: [EMAIL PROTECTED]
> > >
> > >
> > >  I just had a moment to reply to your request for a Catalyst
Cookbook,
> > >  which was forwarded to me because I edit most of our Perl books now.
> > >
> > >   I appreciate your contacting us, and I'll ask the Stonehenge
trainers
> > >  as well as the many O'Reilly employees who are heavily involved in
> > >  Perl development. Unfortunately, it's very hard to

Re: [Catalyst] So, what do we want in the -next- book?

[Roderick A. Anderson]

Andrew Kornak wrote:

Personally, I would like any book on Catalyst, even if it was only a
single chapter in a larger MVC treatment. I bought Jonathan's book and
contrary to another poster's opinion found it quite useful.

-Andrew


+1

Rod
--


On Mon, 2008-04-28 at 10:03 -0500, Mitch Jackson wrote:

I'd like to see a walkthrough of good MVC separation in practice.
This took me a while to get through my stubborn skull, and would be
good material to a new Catalyst developer.  My first few Cat apps
suffered heavily from having too much logic in the controllers.

The example could look something like this:
- Put this logic into a model method and why
- Build a .t file to test the model method ( possibly include
deploying and testing against a mock database )
- Build a .pl file, outside the catalyst web app that uses the method
- Finally, use the method from your catalyst action

This not only suggests good practice to the reader, but shows them how
to do it properly and gives them hands-on with the benefits of the
approach.

/Mitchell K. Jackson

On Sat, Apr 26, 2008 at 7:01 PM, Ian Sillitoe <[EMAIL PROTECTED]> wrote:

So as I said - I contacted O'Reilly to request info/submit interest in a
Catalyst Cookbook/Best Practices. I've been in contact with a chap called
Andy Oram who seems to be O'Reilly's Perl Guy (FWIW he also seems a nice,
but very busy, guy). I was waiting for him to give me the nod before posting
the following thread to the mailing list...





I just had a moment to reply. You can post my reply to the mailing list--I
do appreciate that you asked first. Results of my asking around are
discouraging. I will try to do some more research next week, but this is a
busy time for me. (I have only 6 days at home during the whole month of
April.)

 Andy

 - Original Message -
 From: "Ian Sillitoe" <[EMAIL PROTECTED]>
 To: "Andy Oram" <[EMAIL PROTECTED]>
 Sent: Thursday, April 17, 2008 4:28:34 AM (GMT-0500) America/New_York
 Subject: Re: Catalyst Cookbook/Best Practices

 Andy,

 Thanks for getting back to me. It would obviously be nice to see
 O'Reilly give Catalyst the full "Best Practices" treatment, however as
 you say, a more simple "Catalyst Cookbook/Hacks" book of code snippets
 would presumably be much easier to produce/edit and therefore more
 likely to happen. The Catalyst POD docs are already pretty good and
 will undoubtably continue to improve. However most Catalyst
 developers, i.e. the people that would actually fork out money (or get
 their employers to fork out money) to buy the book, would probably be
 very happy just to get the interesting snippets in lots of different
 case scenarios.

 Also, I was going to post the reply you gave on the Catalyst mailing
 list - but it feels a bit rude without at least asking you first - any
 objections?

 Lots of people would be really interested in any further developements
 so if you had a chance to update me when you hear anything, I would be
 really grateful.

 Regards,

 Ian


 -- Forwarded message --
 From: Andy Oram <[EMAIL PROTECTED]>
 Date: Wed, Apr 16, 2008 at 11:46 PM
 Subject: Catalyst Cookbook/Best Practices
 To: [EMAIL PROTECTED]


 I just had a moment to reply to your request for a Catalyst Cookbook,
 which was forwarded to me because I edit most of our Perl books now.

  I appreciate your contacting us, and I'll ask the Stonehenge trainers
 as well as the many O'Reilly employees who are heavily involved in
 Perl development. Unfortunately, it's very hard to make money on books
 about Web frameworks. Even the Rails market, which used to be very
 good, is weakening.

  Basically, the success of the open source movement makes book
 publishing difficult. There are lots of competing frameworks and
 languages. There are core groups of excited users for each one, but
 rarely do they add up to a market for a book.

  But we'll see what our Perl contacts say. The idea of bypassing the
 tutorial and writing a cookbook is appealing.





On Fri, Apr 4, 2008 at 12:46 PM, Ian Sillitoe <[EMAIL PROTECTED]>
wrote:



On Thu, Apr 3, 2008 at 10:36 PM, Pierre Moret <[EMAIL PROTECTED]> wrote:


Jon wrote:


[...] Or like others have suggested, a cookbook with a large variety

of useful examples showing "best practices" for different situations.

That's exactly what I would like to see. I got the first book (thanks!)

and would buy such a cookbook immediately.


Seconded... and, like one of the previous posters, I've also added my

tuppence to (proposals@) O'Reilly (.com) suggesting they get on the case.




___
 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
Sea

Re: [Catalyst] Multi-language and REST

[Octavian Rasnita]

From: "Matt Rosin" <[EMAIL PROTECTED]>
FWIW after all that such a module should allow keys stored in cookies

to supplement/overwrite the url. So instead of prepending lang code, I
could keep the same url but have a javascript language button set the
language.


I think that the pages with different content (in different languages) 
should have a unique URL (for allowing the search engines to index all the 
pages).


I first made an application in a single language then I needed to make it 
multilanguage, and the most easy way I found was to add the language ID in 
the query string, like:  ?lang=FR.


The app uses Catalyst::Plugin::I18N. If the request doesn't contain any lang 
variable and any lang cookie, it gets the languages prefered by the browser 
and displays the page in the most apropriate language.
If the request contains the lang cookie, the app displays the pages using 
that language.


If the request contains the lang variable, it also displays the page using 
that language.


The links which should be used for changing the language send a lang 
variable, and a "cook" variable. When the app receives both of these 
variables, it displays the site in the specified language, and it also sets 
a cookie with that language, and the next time the visitor will visit the 
site, he will see the page displayed in the previously chosen language. This 
won't happen if this wasn't his choice, but only a browser preference.


For doing this I use the code I put below. I put it in the Root.pm, in the 
auto subroutine, so it is executed for all the other controllers and it sets 
the lang var in the stash for using it later in those controllers if needed 
(for sending emails in the chosen language, for example).


Of course, after doing this, I also needed to modify some templates and 
controllers in which I hard-coded URLs because I needed to insert lang=[% 
lang %].


HTH

Octavian

Here is the code I use:

my $lang = $c->req->param('lang');
my $cook = $c->req->param('cook');

if ($lang and $cook) {
#set cookie
$c->res->cookies->{lang} = {value => $lang, domain => 
$c->config->{cookie_domain}, path => '/', expires => '+1y'};


$c->languages([$lang]);
}
elsif ($lang) {
$c->languages([$lang]);
}
elsif ($c->req->cookies->{lang}) {
$lang = $c->req->cookies->{lang}->value;
$c->languages([$lang]);
}
else {
#read the browser prefered languages
my @accept_language = split /,/, $c->req->header('Accept-Language');
my @langs;
foreach(@accept_language) {
s/;.*$//;
s/-.*$//;
push (@langs, $_);
}

$c->languages([EMAIL PROTECTED]);
$lang = $c->language; #the chosen language
}

$c->stash->{lang} = $lang;



___
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] So, what do we want in the -next- book?

[Andrew Kornak]

Personally, I would like any book on Catalyst, even if it was only a
single chapter in a larger MVC treatment. I bought Jonathan's book and
contrary to another poster's opinion found it quite useful.

-Andrew

On Mon, 2008-04-28 at 10:03 -0500, Mitch Jackson wrote:
> I'd like to see a walkthrough of good MVC separation in practice.
> This took me a while to get through my stubborn skull, and would be
> good material to a new Catalyst developer.  My first few Cat apps
> suffered heavily from having too much logic in the controllers.
> 
> The example could look something like this:
> - Put this logic into a model method and why
> - Build a .t file to test the model method ( possibly include
> deploying and testing against a mock database )
> - Build a .pl file, outside the catalyst web app that uses the method
> - Finally, use the method from your catalyst action
> 
> This not only suggests good practice to the reader, but shows them how
> to do it properly and gives them hands-on with the benefits of the
> approach.
> 
> /Mitchell K. Jackson
> 
> On Sat, Apr 26, 2008 at 7:01 PM, Ian Sillitoe <[EMAIL PROTECTED]> wrote:
> > So as I said - I contacted O'Reilly to request info/submit interest in a
> > Catalyst Cookbook/Best Practices. I've been in contact with a chap called
> > Andy Oram who seems to be O'Reilly's Perl Guy (FWIW he also seems a nice,
> > but very busy, guy). I was waiting for him to give me the nod before posting
> > the following thread to the mailing list...
> >
> >
> > 
> >
> >
> > I just had a moment to reply. You can post my reply to the mailing list--I
> > do appreciate that you asked first. Results of my asking around are
> > discouraging. I will try to do some more research next week, but this is a
> > busy time for me. (I have only 6 days at home during the whole month of
> > April.)
> >
> >  Andy
> >
> >  - Original Message -
> >  From: "Ian Sillitoe" <[EMAIL PROTECTED]>
> >  To: "Andy Oram" <[EMAIL PROTECTED]>
> >  Sent: Thursday, April 17, 2008 4:28:34 AM (GMT-0500) America/New_York
> >  Subject: Re: Catalyst Cookbook/Best Practices
> >
> >  Andy,
> >
> >  Thanks for getting back to me. It would obviously be nice to see
> >  O'Reilly give Catalyst the full "Best Practices" treatment, however as
> >  you say, a more simple "Catalyst Cookbook/Hacks" book of code snippets
> >  would presumably be much easier to produce/edit and therefore more
> >  likely to happen. The Catalyst POD docs are already pretty good and
> >  will undoubtably continue to improve. However most Catalyst
> >  developers, i.e. the people that would actually fork out money (or get
> >  their employers to fork out money) to buy the book, would probably be
> >  very happy just to get the interesting snippets in lots of different
> >  case scenarios.
> >
> >  Also, I was going to post the reply you gave on the Catalyst mailing
> >  list - but it feels a bit rude without at least asking you first - any
> >  objections?
> >
> >  Lots of people would be really interested in any further developements
> >  so if you had a chance to update me when you hear anything, I would be
> >  really grateful.
> >
> >  Regards,
> >
> >  Ian
> >
> >
> >  -- Forwarded message --
> >  From: Andy Oram <[EMAIL PROTECTED]>
> >  Date: Wed, Apr 16, 2008 at 11:46 PM
> >  Subject: Catalyst Cookbook/Best Practices
> >  To: [EMAIL PROTECTED]
> >
> >
> >  I just had a moment to reply to your request for a Catalyst Cookbook,
> >  which was forwarded to me because I edit most of our Perl books now.
> >
> >   I appreciate your contacting us, and I'll ask the Stonehenge trainers
> >  as well as the many O'Reilly employees who are heavily involved in
> >  Perl development. Unfortunately, it's very hard to make money on books
> >  about Web frameworks. Even the Rails market, which used to be very
> >  good, is weakening.
> >
> >   Basically, the success of the open source movement makes book
> >  publishing difficult. There are lots of competing frameworks and
> >  languages. There are core groups of excited users for each one, but
> >  rarely do they add up to a market for a book.
> >
> >   But we'll see what our Perl contacts say. The idea of bypassing the
> >  tutorial and writing a cookbook is appealing.
> >
> >
> >
> >
> >
> > On Fri, Apr 4, 2008 at 12:46 PM, Ian Sillitoe <[EMAIL PROTECTED]>
> > wrote:
> > >
> > >
> > >
> > > On Thu, Apr 3, 2008 at 10:36 PM, Pierre Moret <[EMAIL PROTECTED]> wrote:
> > >
> > > > Jon wrote:
> > > >
> > > > > [...] Or like others have suggested, a cookbook with a large variety
> > of useful examples showing "best practices" for different situations.
> > > >
> > >
> > > >
> > > > That's exactly what I would like to see. I got the first book (thanks!)
> > and would buy such a cookbook immediately.
> > > >
> > >
> > >
> > > Seconded... and, like one of the previous posters, I've also added my
> > tuppence to (proposals@) O'Reilly (.com) suggesting they get on the case.
> > >
> > >
> >
> >
> > 

Re: [Catalyst] Re: So, what do we want in the -next- book?

[Richard Jones]

Jonathan Rockway wrote:

* On Mon, Apr 28 2008, Ali M. wrote:

Sorry to say this, but your book is not a good book!



One of the reasons we need a second book, is that because your book
was so bad. People right away started asking and hoping for a second
book.


Now I can see why people are lining up to write another book.


Except that the views expressed by Ali M are pretty extreme, and I would 
say do not reflect the view of most contributors to this list, whether 
sympathetic to your efforts or not. Many people (myself included) might 
like to see another book to *extend* yours - the question of course is 
what form it should take.


But such sour contributions, which actually contribute so very little to 
the debate, should not be weighed in the same balance as the many 
substantially more reasoned arguments already put.

--
Richard Jones

___
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: So, what do we want in the -next- book?

[Jonathan Rockway]

* On Mon, Apr 28 2008, Ali M. wrote:
> On Mon, Apr 28, 2008 at 7:29 AM, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
>
>>  2) Learn how to use Catalyst (read my book)
>>
>
> Sorry to say this, but your book is not a good book!
>
> I cannot in good faith recommend it to anyone. Please consider
> believing the bad review your book got, because they are correct.
>
> One of the reasons we need a second book, is that because your book
> was so bad. People right away started asking and hoping for a second
> book.

Now I can see why people are lining up to write another book.

Regards,
Jonathan Rockway

-- 
print just => another => perl => hacker => if $,=$"

___
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

[Matt Rosin]

FWIW after all that such a module should allow keys stored in cookies
to supplement/overwrite the url. So instead of prepending lang code, I
could keep the same url but have a javascript language button set the
language.

/me shuts up now.

Matt R.

___
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

[Matt Rosin]

I think other cases show it is not only an i18n issue.

In a business listings site I made I have
x.com/dir/CityName/Business_Services/Advertising for example.

The top level category Business_Services is optional as the secondary
level category name is unique. The CityName could be any city in the
state, or "All_Cities".
No city means All_Cities.
If there is a city but no topic, it shows table of contents for that city only.
A top level topic but no secondary level topic, it shows a blog on that topic.

As Bill Moseley does, after the dir (which is Dir.pm) I check if there
is a valid city.

I also made some experimental tags to modify behavior. So you could
add "/show_all_cities" at the end and it would do that regardless of
the city. (decided not to use that). Also was going to add a
"/tags:(x,y,z,w)" style supplement to be able to submit a set of
unordered tags but this also proved overkill. However when doing
faceted metadata search the order really isn't important and so order
in the url sholdn't be either I think.

This suggests to me that it would be useful to create a general url
windowing module that lets you specify (and validate urls to) an url
format in which certain segments of it may be structured differently.
By window I mean it lets you look at and define segments of urls. It
could pick up collisions between adjacent keywords too. Could also pad
missing virtual folder names (like setting All_Cities if not present).

I guess you'd define subs for each window spec.

The definition would see x.com/dir/[CITYSPEC]/[MAJORSPEC]]/[MINORSPEC]

It need not be complicated as the purpose is human readability. I know
Accept-Language is good REST but it is less intuitive and personally I
detest being forced to read a Japanese page for a website that has
perfectly good English on it.

It might be useful if you could define a certain format, like
-MMDD for a publication date, for a certain spec. Then it would be
easy to pick up on whether it is present or not and you could easily
handle "x.com/Jones/2008-0428" as well as "x.com/Fiction/Jones" and
even "x.com/Jones/EarlyWorks" (if you allow the date spec to include
EarlyWorks, defined as within 10 years of the first PubDate on
record).

Anyway the fr/en switch is a small subset of this functionality which
is otherwise very useful for helping users (and hopefully Google)
intuitively navigate orthogonal metadata (think Author, PubDate,
Topic) or data organized into hierarchies with crosslinks, like a
Yahoo style topic hierarchy. I suppose this is too long a post but it
would benefit all catalyst sites if created. I suppose UrlFu or the
like.

___
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] So, what do we want in the -next- book?

[Robert Sedlacek]

Ali M. wrote:

i completly oppose another cookbook for catalyst

catalyst need an indepth book that describe its design!
the first book was very much a learning by example book, which is
close to a cookbook

and the main complain or the bad review where that, after reading the
book, developers still didnt not understand how catalyst work (for
exampl how subroutines attributes are used)

we need a book with diagrams that exlpain the different pieces of catalyst

a cookbook maybe be easier to write, but its not what i think is needed
a cookbook is for people who already knows catalysts, this book trend
will make catalyst a very exclusive framework only used by perl
experts!


I'd rather like to see _that_ as a community-driven project, maybe on 
the wiki. There is much more in the Catalyst ecosystem than just core, 
and different people in the community are probably better at explaining 
different things.


-rs

___
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] So, what do we want in the -next- book?

[Mitch Jackson]

I'd like to see a walkthrough of good MVC separation in practice.
This took me a while to get through my stubborn skull, and would be
good material to a new Catalyst developer.  My first few Cat apps
suffered heavily from having too much logic in the controllers.

The example could look something like this:
- Put this logic into a model method and why
- Build a .t file to test the model method ( possibly include
deploying and testing against a mock database )
- Build a .pl file, outside the catalyst web app that uses the method
- Finally, use the method from your catalyst action

This not only suggests good practice to the reader, but shows them how
to do it properly and gives them hands-on with the benefits of the
approach.

/Mitchell K. Jackson

On Sat, Apr 26, 2008 at 7:01 PM, Ian Sillitoe <[EMAIL PROTECTED]> wrote:
> So as I said - I contacted O'Reilly to request info/submit interest in a
> Catalyst Cookbook/Best Practices. I've been in contact with a chap called
> Andy Oram who seems to be O'Reilly's Perl Guy (FWIW he also seems a nice,
> but very busy, guy). I was waiting for him to give me the nod before posting
> the following thread to the mailing list...
>
>
> 
>
>
> I just had a moment to reply. You can post my reply to the mailing list--I
> do appreciate that you asked first. Results of my asking around are
> discouraging. I will try to do some more research next week, but this is a
> busy time for me. (I have only 6 days at home during the whole month of
> April.)
>
>  Andy
>
>  - Original Message -
>  From: "Ian Sillitoe" <[EMAIL PROTECTED]>
>  To: "Andy Oram" <[EMAIL PROTECTED]>
>  Sent: Thursday, April 17, 2008 4:28:34 AM (GMT-0500) America/New_York
>  Subject: Re: Catalyst Cookbook/Best Practices
>
>  Andy,
>
>  Thanks for getting back to me. It would obviously be nice to see
>  O'Reilly give Catalyst the full "Best Practices" treatment, however as
>  you say, a more simple "Catalyst Cookbook/Hacks" book of code snippets
>  would presumably be much easier to produce/edit and therefore more
>  likely to happen. The Catalyst POD docs are already pretty good and
>  will undoubtably continue to improve. However most Catalyst
>  developers, i.e. the people that would actually fork out money (or get
>  their employers to fork out money) to buy the book, would probably be
>  very happy just to get the interesting snippets in lots of different
>  case scenarios.
>
>  Also, I was going to post the reply you gave on the Catalyst mailing
>  list - but it feels a bit rude without at least asking you first - any
>  objections?
>
>  Lots of people would be really interested in any further developements
>  so if you had a chance to update me when you hear anything, I would be
>  really grateful.
>
>  Regards,
>
>  Ian
>
>
>  -- Forwarded message --
>  From: Andy Oram <[EMAIL PROTECTED]>
>  Date: Wed, Apr 16, 2008 at 11:46 PM
>  Subject: Catalyst Cookbook/Best Practices
>  To: [EMAIL PROTECTED]
>
>
>  I just had a moment to reply to your request for a Catalyst Cookbook,
>  which was forwarded to me because I edit most of our Perl books now.
>
>   I appreciate your contacting us, and I'll ask the Stonehenge trainers
>  as well as the many O'Reilly employees who are heavily involved in
>  Perl development. Unfortunately, it's very hard to make money on books
>  about Web frameworks. Even the Rails market, which used to be very
>  good, is weakening.
>
>   Basically, the success of the open source movement makes book
>  publishing difficult. There are lots of competing frameworks and
>  languages. There are core groups of excited users for each one, but
>  rarely do they add up to a market for a book.
>
>   But we'll see what our Perl contacts say. The idea of bypassing the
>  tutorial and writing a cookbook is appealing.
>
>
>
>
>
> On Fri, Apr 4, 2008 at 12:46 PM, Ian Sillitoe <[EMAIL PROTECTED]>
> wrote:
> >
> >
> >
> > On Thu, Apr 3, 2008 at 10:36 PM, Pierre Moret <[EMAIL PROTECTED]> wrote:
> >
> > > Jon wrote:
> > >
> > > > [...] Or like others have suggested, a cookbook with a large variety
> of useful examples showing "best practices" for different situations.
> > >
> >
> > >
> > > That's exactly what I would like to see. I got the first book (thanks!)
> and would buy such a cookbook immediately.
> > >
> >
> >
> > Seconded... and, like one of the previous posters, I've also added my
> tuppence to (proposals@) O'Reilly (.com) suggesting they get on the case.
> >
> >
>
>
> ___
>  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

Re: [Catalyst] Re: So, what do we want in the -next- book?

[Martin Ellison]

I'd like something that explains the 'Catalyst way'. Most languages have an
associated style, and introductory texts go to some trouble to explain how
to write in that style. For example, Java textbooks explain that you
shouldn't have lots of little 'struct' classes then one big main class so
the program looks just like you used to do in COBOL... Perl manuals tend to
teach The Is More Than One Way... but then we have Damian Conway's *Perl
Best Practices* to tell us the 'Perl way'. So I suppose there is a Catalyst
Way to do it.

I should say I haven't read the Rockway book.

-- 
Regards,
Martin
([EMAIL PROTECTED])
IT: http://methodsupport.com Personal: http://thereisnoend.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

[Geir Aalberg]

On 25 Apr 2008, at 14:44 , 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?


- Use two different subdomains (en.domain.com and fr.domain.com)

- Send a cookie header (which arguably is easier for the user than  
messing with Accept-Language)


- Send both languages in the HTML (encoded with lang="xxx"), but show  
only one using CSS


The main question is to decide whether the language should be  
specified in the URL or not. There are valid reasons for saying that  
the French text is not the same document as the English text, hence  
they should have separate URLs (one such example is having both  
versions indexed in Google).


-geir



___
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: So, what do we want in the -next- book?

[Ian Sillitoe]

I get the impression that persuading a decent publisher to properly back a
500+ page Catalyst book covering all aspects, discussions, internals, best
practices, cookbook, etc. is just not going to happen (unfortunately),
certainly not at the moment. The point has been made before, but I think it
is worth reiterating: writing a decent book requires an enormous
commitment/investment of money, time, skill and effort from both the authors
and publishers. Even with all those things you can end up with a bad
product, but you're almost certainly guaranteed a bad product without them.

If people are serious about trying to get another book commissioned, written
and published, then perhaps there are two separate issues:

 - what do we *want* in the next book?
 - what do we think *we might realistically be able to get* in the next
book?

Yes, it would be great to see O'Reilly give Catalyst the full 'Camel Book'
treatment, but the initial comments from O'Reilly make this seem at best
unlikely (at least in the near future). However, it's worth noting that I
remember my first copy of the Camel Book (2nd ed?) being a great deal
smaller than the latest edition - so maybe it's worth being a bit more
pragmatic - choosing a format that would be most useful and sell well, while
being easiest to produce - with the view that increased coverage/backing
would help the project perhaps as much as book itself.

So again, my vote is for Catalyst Best Practices - I get the impression that
this format would require less editing/structuring - i.e. providing code
snippets and accompanying discussion for a whole number of FAQs, gotchas,
recommended plugins, common development scenarios. However, I very much take
the point that if this is going to be useful it should provide opinions on a
number of non-Catalyst topics - e.g. providing opinions on DBIx::Class,
Moose, setting up MVC applications outside of Catalyst would be relevant and
a Good Thing.

Like PBP, it would take someone (or preferably a group of people) to agree
on a bunch of points that they think are important - then be brave and say
this is what I/we think is the best way of doing them and why (perhaps even
breaking things down to a simple set of 'rules' as in PBP). This could also
help to address the other discussion currently going on about providing a
set of standards for internal coding practices. Inevitably there will be
disagreements (e.g. Class::Std/Moose in PBP), especially in hindsight.
However just like PBP, I for one would be very happy to take the advice of
someone who has spent time getting these things working in commercially
successful applications.

Ian

On Mon, Apr 28, 2008 at 11:11 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote:

> Quoting "Ali M." <[EMAIL PROTECTED]>:
> > Sorry to say this, but your book is not a good book!
> > I cannot in good faith recommend it to anyone. Please consider
> > believing the bad review your book got, because they are correct.
>
> And here we are again, waiting for the usual "If you don't like what's out
> there, roll/write/code your own" response which is not gonna make things
> better
> for Catalyst or Perl in general ... I bought the book, put it in my shelf
> and
> never looked into it. I seriously doubt that's a good sign for any book
> ...
>
> Writing a book IS hard and I appreciate the work Jonathan put in the first
> Catalyst book. But the book in its current form really is not very
> appealing
> especially to people who're not involved in the Cat community at all.
>
> I don't know why the Perl community in general is having such a hard time
> making
> its favourite language and tools like Catalyst appealing to the outside
> world. I
> suppose all those Ruby and PHP dudes are better at this because many of
> them
> once started out as "web designers" before becoming "web developers" ...
> It
> seems there are too few top-notch developers in the Perl community who
> have a
> sense for the "soft" factors that make or break a product.
>
> --Tobias
>
> ___
> 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/

[Catalyst] Re: So, what do we want in the -next- book?

[Aristotle Pagaltzis]

* Jonathan Rockway <[EMAIL PROTECTED]> [2008-04-28 06:40]:
> Am I the only person here that has ever started a job and had
> to just dive into the code, code without docs or tests?
>
> I assume not, but nobody is asking your boss to write a book
> about how your internal code works. You just dive in and
> understand it.

Just because largely undocumented internal codebases are the norm
doesn’t mean they are an inevitable fate.

Anything that takes more than a week of effort requires a
design document, with specific sections that have to be
filled out, and with feedback from primary and secondary
reviewers of your choice. The net result is that for any
significant piece of code at Google, you can find almost a
whole book about it internally, and a well-written one at
that.
—Steve Yegge

But in any case, most companies are not in the business of
creating free software libraries that hope to attract programmers
as users and contributors, so the comparison is a category error
to begin with.

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: So, what do we want in the -next- book?

[Tobias Kremer]

Quoting "Ali M." <[EMAIL PROTECTED]>:
> Sorry to say this, but your book is not a good book!
> I cannot in good faith recommend it to anyone. Please consider
> believing the bad review your book got, because they are correct.

And here we are again, waiting for the usual "If you don't like what's out
there, roll/write/code your own" response which is not gonna make things better
for Catalyst or Perl in general ... I bought the book, put it in my shelf and
never looked into it. I seriously doubt that's a good sign for any book ...

Writing a book IS hard and I appreciate the work Jonathan put in the first
Catalyst book. But the book in its current form really is not very appealing
especially to people who're not involved in the Cat community at all.

I don't know why the Perl community in general is having such a hard time making
its favourite language and tools like Catalyst appealing to the outside world. I
suppose all those Ruby and PHP dudes are better at this because many of them
once started out as "web designers" before becoming "web developers" ... It
seems there are too few top-notch developers in the Perl community who have a
sense for the "soft" factors that make or break a product.

--Tobias

___
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: So, what do we want in the -next- book?

[Zbigniew Lukasiak]

On Sun, Apr 27, 2008 at 8:05 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> * J. Shirley <[EMAIL PROTECTED]> [2008-04-27 19:30]:
>
> > If you want to know the internals of catalyst, do as Jonathan
>  > said and fire up a code browser and get started.
>
>  Putting together a map of a mountain by examining it one pebble
>  at a time is not particular efficient nor easy.
>
>  Did you ever notice that the only people who say this are the
>  ones who already know the code intimately?
>
>
>  > Alternatively, just read the pod for all the Catalyst
>  > components; they are very well documented and easy to
>  > understand.
>
>  Easy to say when you've been on personal terms with the codebase
>  throughout its evolution. For someone completely new to the code,
>  things are far less obvious.
>
>  As I try to make sense of the codebase I keep stumbling over
>  places where the setup is quite incestuous: components often do
>  not really set themselves up, they are just glorified structs
>  that expect whoever instatiates them to do all the work. Which
>  expectation is nowhere to be found in the docs – so much for
>  "well documented."  In OO design terms, this is really crummy.
>
>  There is also a lot of indirection – for good reason, of course,
>  but readability suffers from it just the same.
>
>  As a result, a lot of the code is not nearly as self-contained
>  as it could be, which means that you need to already understand
>  a lot of the codebase before you can understand most of the
>  codebase.
>
>  It's by no means an insurmountable task (which is a happy side
>  effect of the modest size of the codebase and not in any way a
>  property of the design itself), but it would be miles easier if
>  there was a high-level overview of the architecture.
>
>  If no one else does write such a thing, I will, once I've come
>  out the other side. Depending on the extent of the task, it might
>  also lead to a patch or two to untangle and isolate parts of the
>  code from each other, although I'm not sure how far this can be
>  taken while respecting the stability/backcompat imperative.
>

Code inspection is recommended by many sources as one of the most
effective tools for improving software quality.  The problem with it
in Open Source projects is that it can quickly turn into a flamewar.
I would like to see how this works out here.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
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: So, what do we want in the -next- book?

[Alessio Bragadini]

On 28 Apr 2008, at 11:14, Ali M. wrote:


Please read this review:
http://dave.org.uk/reviews/catalyst.html

Dave is being too nice to you, blaming the publisher.


Do you understand that Dave Cross' point of view regarding what needs  
to be put in a book is exactly opposite to yours?


--
Alessio Bragadini   [EMAIL PROTECTED]

"One of these mornings / You're going to rise up singing
Then you'll spread your wings / And you'll take to the sky"
-- George & Ira Gershwin, "Summertime"




___
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: So, what do we want in the -next- book?

[Ali M.]

On Mon, Apr 28, 2008 at 7:29 AM, Jonathan Rockway <[EMAIL PROTECTED]> wrote:

>  2) Learn how to use Catalyst (read my book)
>

Sorry to say this, but your book is not a good book!

I cannot in good faith recommend it to anyone. Please consider
believing the bad review your book got, because they are correct.

One of the reasons we need a second book, is that because your book
was so bad. People right away started asking and hoping for a second
book.

Please read this review:
http://dave.org.uk/reviews/catalyst.html

Dave is being too nice to you, blaming the publisher.

The good reviews your book got where from nice people who were excited
catalyst got a book, any book, doesn't matter how poorly written it
is.

Dont believe me:

http://www.amazon.com/review/product/1847190952/ref=cm_cr_pr_helpful

Your book reviews ordered by most helpful first! The bad reviews come first!

___
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/