Re: [Catalyst] Re: So, what do we want in the -next- book?
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/
[Catalyst] Re: So, what do we want in the -next- book?
* 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 // 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] So, what do we want in the -next- book?
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] Multi-language and REST
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] Re: So, what do we want in the -next- book?
* 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] Re: So, what do we want in the -next- book?
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] Multi-language and REST
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 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 Searchable archive:
Re: [Catalyst] So, what do we want in the -next- book?
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 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
[Catalyst] HTTP::Body, utf8 filenames, and escaped strings.
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/
