Re: [Catalyst] CatalystSites.org
* On Wed, Apr 02 2008, Oleg Pronin wrote: > ti che raspizdilsya po-nemetski, suka ? > > 2008/4/2, Ulf Lenski <[EMAIL PROTECTED]>: > > Hallo Ulrich, > ich habe, dein Einverständnis vorausgesetzt, unsere pspf-app mal auf der > unten genannten Seite veröffentlicht. > http://drs.dife.de/ könnte dort doch auch gelistet werden? > > Wollen wir uns bei Gelegenheit mal wieder treffen? > > bis bald - ulf. 何？ -- 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] New engine: HTTP::Prefork
* On Sun, Apr 06 2008, Andy Grundman wrote: > On Apr 6, 2008, at 3:36 AM, Kaare Rasmussen wrote: >>> little bit. I was disappointed in the POE engine and came to the >>> conclusion that POE, while tons of fun to use, is not the right >> >> Just when POE went 1.0! Not fair!! > > POE rocks, but a single process just doesn't work for Catalyst, > because the entire time your application code is running, the process > is blocked. Multiple processes is really the only way to go for a web > server. It may be possible to do some crazy things with something > like Coro but at a severe cost to performance. Or Poco::Generic. That will allow you to (automatically) run Catalyst in a separate (persistent) process. Prepare a few of those when the server starts, and you have an event-based request acceptor that won't block. Of course, the ideal situation is to have an application that never blocks, but that would involve planning on the part of the application developer. 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: about req.param
* On Fri, Apr 11 2008, Fayland Lam wrote:
> Fayland Lam wrote:
>> code as follows:
>>
>> sub test : Local {
>>my ($self, $c) = @_;
>> my $test = {
>>a => $c->req->param('a'),
>>b => $c->req->param('b'),
>>c => $c->req->param('c'),
>>};
>>$c->res->body(Dumper(\$test));
>> }
>>
>
>
> well, this is OK
>
> sub test : Local {
> my ($self, $c) = @_;
>
> my $test = {
> a => $c->req->params->{'a'},
> b => $c->req->params->{'b'},
> c => $c->req->params->{'c'},
> };
> $c->res->body(Dumper(\$test));
> }
Yes, param only exists so you can pass $c->req to a function expecting a
CGI object. (It's for compatibility, not for use in new applications.)
If you really want to use a function call instead of a hash lookup,
apply this role to the request class:
http://git.jrock.us/?p=MooseX-Param-Safe.git;a=blob;f=lib/MooseX/Param/Safe.pm;hb=HEAD
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] Sending email safely with Catalyst
* On Fri, Apr 11 2008, Zbigniew Lukasiak wrote: > I've got a related question - does anyone send bulk emails with that > plugin? Is the delay reasonable when sending let's say a hundred > emails or do I need a background mechanism for that? I have now a > forking solution - but it is a bit complex (and for mod_perl they > recommend to do it in a 'cleanup' handler instead of a forked > process). In an ideal world, you should be able to dump the messages into your mail system's queue as quickly as you can dump them into a database table (adding to the mail queue is a disk write, adding to a database is a disk write, unless you've turned off data integrity). I could see how calculating the text of 1 mail messages during a request would be slow, but why would you want to do that? Usually you'll just want to say "Your account was created, [% name %]!" and queue that. The template rendering and the mail system's queue should be more than fast enough to handle that during a request. As for bulk emails, you probably have a process that calculates those outside of your Catalyst app anyway (running from cron), so calculate them, dump them into the mail queue, and let your mailer daemon figure out what to do. Much better than putting a queue in front of a queue, IMHO. This is UNIX after all. 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] Django Dash, opportunity for Catalyst?
* On Wed, Apr 16 2008, Paul Makepeace wrote: > http://www.djangodash.com/ > > =summary > The Django Dash is a chance for Django enthusiasts to flex their > coding skills a little and put a fine point on "perfectionists with > deadlines" by giving you a REAL deadline. 48 hours from start to stop > to produce the best app you can and have a little fun in the process. > =cut > > Fun to do something in Catalyst like that. If it were run concurrently > that would be particularly interesting, and see which camp comes up > with the better app! > > http://www.djangodash.com/faq/ has the timeline, Sounds fun. Let's do a Catalyst version at YAPC::NA (and if it goes well, YAPC::EU). I say... 1 day to write your app, the next day to present it to everyone and receive highly valuable prizes if yours is the best. Discuss amongst yourselves. 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] Testing View
* On Sat, Apr 19 2008, Yao Wang wrote:
> Hi,
>
> Thanks Matt. Now i know i have used wrong way to call a method in the
> controller.
>
> However ,the reason i use $c->prepare is for unit testing. I have seen
> Catalyst::Test and Test::WWW::Mechanize::Catalyst, i think they are
> the testing tools for application, not for unit testing. When i do the
> unit testing, i need to pass $c and some other params to the methods.
> So can anybody tell me how to create this kind of $c for testing only
> ?
If you want to do what you described in your previous message, you need
to take a different approach.
I recommend something like this:
use Catalyst::Test 'MyApp';
my $template;
my $old_process = \&YourApp::View::Whatever::process;
*YourApp::View::Whatever::process = sub {
my ($self, $c, @args) = @_;
$template = $c->stash->{template};
$self->$old_process($c, @args);
}
request('foo');
is $template, 'the_template_for_foo.tt';
You really want to keep this kind of testing to a minimum. The Catalyst
part of your application should be simple enough to not require
intensive testing.
Test::WWW::Mechanize::Catalyst (and friends) is mostly good for a quick
sanity check. The important parts of your application should reside in
easily-testable classes, and Catalyst should just be a few lines of code
to make the those classes available to web users.
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] Unit Testing
* On Sun, Apr 20 2008, Octavian Rasnita wrote: > Please tell us if we can find an example of putting the logic in the > model than call those methods from the controller. http://www.jrock.us/fp2008/catalyst/start.html Using a DBIC-based model works the same way. 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] Catalyst and PayPal
* On Mon, Apr 21 2008, Zbigniew Lukasiak wrote: > There is some point on the diagram of the ratio between the complexity > of the API and the code where it starts to not make sense to release > the code as a module. When the controls of the blackbox become more > complicated as the gears inside it then I would rather use the gears > directly. > > I don't want to discuss any particular module here - but I would like > to get consensus that there is such a point. I would like to see some examples. I think that anything that will be used more than once should be easy to reuse. I never want to see the gears. Seeing the gears means it's way too easy to get your hair caught in them, and this is a problem that obviously worries me :) 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/
[Catalyst] Catalyst Conference #1
Just thought I would share this for those that hadn't heard. Some of the Tokyo-area Perl mongers put together a conference about all things Catalyst (including the routers and ATI config utility :) Here are some articles that you might enjoy putting into Google Translate: http://d.hatena.ne.jp/ZIGOROu/20080423/1208921370 http://yusukebe.com/archives/08/04/23/125842.html (more links: http://b.hatena.ne.jp/vkgtaro/catalystcon/) Too bad I couldn't make it -- maybe Catalyst Conference #2. If you lose sleep at night worrying about Catalyst's popularity, rest easy 'cause it has its own conference now :) 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] Why does $c->stats require -Debug flag?
* On Thu, Apr 24 2008, Jon Schutz wrote: > On Mon, 2008-04-21 at 19:16 +0100, Matt S Trout wrote: >> That's not a compromise, that's an AUTOLOAD, which is poor coding practice >> when you know what methods the object on the other side exists. > > Indeed it is a compromise. It's not a compromise. It's laziness that makes Catalyst less reliable. Thousands of people rely on Catalyst to not take half-assed shortcuts. Why resort to hacks that have the potential to fuck things up for everyone but save 3 seconds of your time? This isn't PHP :) >> I'm aware you object on principle; however I've stated very clearly why I >> believe your objections are incorrect and since you're contributing to >> Catalyst I'd ask that you follow the current Catalyst standards for >> backwards compatibility even if you disagree, just the same as you'd do >> for coding style and other matters of opinion. If I ever contribute to one >> of your projects I'll happily return the favour :) > > No problems, if that's what the Catalyst standard says; I must have > missed it. Where is it? I'd like to consult it on a number of > matters... please post the link. Basically it's more of a "zeitgeist" than an actual document. There are some things that the community has decided and "just do". One is not breaking things or adding features between point releases. We've fucked this up a number of times, but that doesn't really matter, the point is we try to fix our mistakes. Compare this to other frameworks that just break things and say "fuck you". > The fact that it's supposedly already in a stage of "completely broken" > kind of undermines that theory. Not really. It just means we need to fix it even sooner. > I'm quite aware that I've spent more time debating the point than it > would have taken just to do this nugatory work, but then we wouldn't be > having this interesting discussion. Can we put a timescale on it? What > is the plan for release of 5.7013 and/or 5.80? Can you either: * do this now * or say you're not going to do it? That would make it easier for someone else to just get this done. Obviously you aren't obligated to do anything, because it's an open source project. But when someone contributes changes, we release them, and then realize that there's a problem, it's nice to have the contributor around to fix the issues. When they just disappear or argue against the project's conventions, it doesn't really look good, right? The stats code is good stuff. Why taint it with flamewars when it can be loved-by-everyone in just a few minutes? :) 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] Why does $c->stats require -Debug flag?
* On Thu, Apr 24 2008, Jon Schutz wrote: > A "standard" is not a standard unless it's written down as a common > reference for everybody to see. People in the community come and go and > don't all have the same history, or longevity of memory for all the > "let's make this a standard" decisions that happen along the way. This > is perhaps getting close to the crux of the problem. Clearly Matt and > I, and you it seems, have a different concept of what the "standard" is. > > Is there someone out there, then, with the right background, to set up a > Wiki page and document this zeitgeist? I don't think anyone but you ever used the word "standard". If it would make you feel better, let's define the standard to be "whatever mst comes up with". He is the loudest, so he gets to decide. He also has that cool chainsaw thing. Anyway, this whole discussion sounds like you're being defensive. There is no need to be defensive. You didn't do anything wrong. When you sent the patch, you might not have known that we wanted to keep backcompat. I didn't know ;) And nobody told you that we wanted compat until recently. So it's not your fault for not initially adding the feature. But now we want it, and are anxiously awaiting a patch. You are most qualified to provide it. > No I can't do it now, but may well be able to if given a time frame. You need to decide your own time frame. This is not work, it's an open source project. We are not going to tell you what to do. Someone will probably have to write it before the end of next week, though. This is an issue that we would like to resolve soon. > It seems to me that there are some underlying issues here which need to > be sorted out. At least I think so. If there are code issues, let's talk about them. If there is whining about community standards and so on, I am tired of talking about them. It's boring. You know how the old saying goes -- "shut the fuck up and write some code" :) 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: Why does $c->stats require -Debug flag?
* On Thu, Apr 24 2008, Aristotle Pagaltzis wrote: > * Jonathan Rockway <[EMAIL PROTECTED]> [2008-04-24 11:25]: >> * On Thu, Apr 24 2008, Jon Schutz wrote: >> > No problems, if that's what the Catalyst standard says; I >> > must have missed it. Where is it? I'd like to consult it on >> > a number of matters... please post the link. >> >> Basically it's more of a "zeitgeist" than an actual document. >> There are some things that the community has decided and "just >> do". > > That’s the sort of feel-good bollocks I’d expect to read on a > Rails hype blog, not here. Unspoken rules and gut feel are no way > to run a community. Catalyst suffers from this in general: way > too little is written down, much less in any systematic fashion. Nobody has time to run a bureaucracy. We just want to write code. 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] So, what do we want in the -next- book?
* On Sat, Apr 26 2008, 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! To be fair, the Advent calendar is usually well received. People keep asking the same questions again and again and again, which is why a cookbook may be a good idea. Instead of asking them, they can read, understand the problem a bit better, and then cut-n-paste some code. Not ideal, but the world isn't an ideal place. Anyway, I hate to break this to you... if you want to know every detail of how the code works, you have to read the code. Reading code is the most important skill a programmer can have, so I suggest biting the bullet, opening up your favorite code browser (ECB++), and perusing. 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?
* On Sun, Apr 27 2008, Aristotle Pagaltzis 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? Yeah, and we all learned it from a super secret book we're not sharing. Here's how to learn the catalyst internals: 1) Learn how to use OO Perl (read "Intermediate Perl") 2) Learn how to use Catalyst (read my book) Now you know how the pieces of Catalyst fit together, and you know what OO is. You're halfway there. Now you figure out what you want to know. "Hmm, I wonder how the :Local attribute works." Now you grep for "Local" and find "_parse_Local_attribute". Then you follow that path until you understand it. If statically reading the code doesn't do it for you, stick in a breakpoint (or Carp::REPL) and start your app. When you're in there, poke the data structures until you understand them. Then continue reading the source. Another good thing to do is try to add a new feature. It's not going to be easy the first time, but that's the point of practicing. You're not going to get good by reading books. You're going to get good by reading the source. Finally, a book about the internals might be worthwhile if we were sure that This Is The Best Way To Do Things, but Catalyst isn't. It's *a* way that works, but certainly not the best. If you want to read about "the best" read some of Knuth's books. TeX is a literate program. >> 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. 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. Diving into Catalyst is even easier, because it has docs, tests, and thousands of working applications that use it. (Search CPAN for "catalyst". Lots of people have figured it out.) > 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. As I said above... yeah... Catalyst sucks. It is not God's Gift To The World. It's some useful code that works. > But in the meantime please quit shifting the laziness blame to > the users. People are responsible for themselves. If they want to understand something, they can't expect understanding to be handed to them on a silver platter. They will just have to dive in and try to understand. It's called programming. Anyway, if someone wants to pay me $250/hr to document Catalyst's internals, I'll do it. But I bet you'll find that it's not worth it. 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?
* 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] Catalyst website
* On Tue, Apr 29 2008, Andrew Rodland wrote:
>
> 2) Will the "new wiki" go live[1] at its current toeat.com address or at
> $answer{'Question 1'} . "/wiki/"?
Definitely not toeat. But when is this going to happen?
> 3) Can we have a link to thebookerrata on the front page with the book link,
> where newbies are likely to find it? Something to the tune of "Having
> trouble? Click here for important information on the Catalyst book." I will
> happily submit patch to the website if this is not shot down.
+1
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] So, what do we want in the -next- book?
* On Tue, Apr 29 2008, Mark Keating wrote: >> Dare I say, an Enlightened Perl Development book? > > Perl for Enterprise: A look at Enlightened Perl Development But first, the EPO needs to create a publishing company called "ORLY". -- 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] So, what do we want in the -next- book?
* On Tue, Apr 29 2008, Peter Corlett wrote: > On Sun, Apr 27, 2008 at 03:01:47AM -0500, Jonathan Rockway wrote: > [...] >> Anyway, I hate to break this to you... if you want to know every detail of >> how the code works, you have to read the code. Reading code is the most >> important skill a programmer can have, so I suggest biting the bullet, >> opening up your favorite code browser (ECB++), and perusing. > > Right, and I need to read the entire Linux and libc source code to be able > to write a Unix application. It will help, yes. 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] $row->copy causing exit from controller(!)
* On Thu, May 01 2008, Paul Makepeace wrote:
> I'm seeing something exceedingly odd: copying data causing a premature
> return from the controller, like a detach(),
>
> foreach my $table (@chart_related_tables) {
> my $rs = $ds->resultset($table);
> warn "copying $table for ", $new_chart->uid;
> for my $row ($rs->search({web_chart_spec_uid => $chart->uid})) {
> warn "..row ", $row->web_chart_spec_uid, $row;
> $row->copy({web_chart_spec_uid => $new_chart->uid}); # XXX
> }
> #$_->copy({web_chart_spec_uid => $new_chart->uid})
> #for $rs->search({web_chart_spec_uid => $chart->uid});
> die "cloned", $new_chart->uid;
> }
>
Is copy throwing an exception? Are you using an old version of
stacktrace?
If yes and yes: upgrade StackTrace (it eats exceptions)
If no and no: something is horribly wrong (perl -d may help)
If yes and no: see above.
I have a feeling it's the first one. Another possibility is that "copy"
is last-ing out of itself.
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: Fw: high school reunion [Catalyst] (no subject)
* On Fri, May 02 2008, rik knox wrote: > I''AM RIK KNOX WAS AT WEST DENTON HIGH SCHOOL NORTH HOUSE MR LAWRENCE WAS > MY FORM TEACHER, WANT TO HOOK UP WITH ANYONE YES ANYONE WHO WAS AT SCHOOL > SAME TIME .LOOKING FOR ANYONE FROM WEST DENTON HIGH SCHOOL 1976 PLEASE > EMAIL ME What. The. Fuck. -- 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] RFC: Catalyst::Controller::REST::DBIC
* On Sat, May 03 2008, luke saunders wrote:
> __PACKAGE__->config
> ( action => { setup => { PathPart => 'cd', Chained =>
> '/api/rest/rest_base' } },
> class => 'RestTestDB::CD',
> create_requires => ['artist', 'title', 'year' ],
> update_allows => ['title', 'year']
> );
>
> And this gets you the following endpoints to fire requests at:
> /api/rest/cd/create
> /api/rest/cd/id/[cdid]/update
> /api/rest/cd/id/[cdid]/delete
> /api/rest/cd/id/[cdid]/add_to_rel/[relation]
> /api/rest/cd/id/[cdid]/remove_from_rel/[relation]
This is RPC, not REST. Not that there's anything wrong with that.
It sounds like what you want to write is a Controller that proxies class
methods to a URI. For example, you write a class like this:
package Foo;
sub create { my ($class, $username, $password) = @_; ... }
sub delete { my $self = shift; $self->delete }
sub foo{ my ($self, $quux, $value_for_42) = @_; ... }
sub fetch_existing { my ($class, $id) = @_ }
...
1;
Then you write a controller like this:
package MyApp::Controller::Foo;
use base 'The::Thing::You're::Writing';
__PACKAGE__->config(
class => 'Foo',
fetch_existing => 'fetch_existing',
new_instance=> 'create',
methods => {
create => ['username', 'password'],
delete => [],
foo=> ['quux', '42'],
},
);
1;
Then you have actions like:
/foo//create//
/foo/
/foo//foo//
/foo//delete
In your configuration, an option would be available to REST-ify certain
parts of the RPC interface:
rest => {
create => 'create',
get=> 'fetch_existing',
delete => 'delete',
update => 'update',
}
Then you would have the /foo and /foo/ REST endpoints do the same
thing as the RPC calls.
Anyway, making this specific to DBIx::Class sounds like a waste of time.
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] Anybody who fancies some LWP poking ...
* On Mon, May 05 2008, Daniel McBrearty wrote: > tht's reasonable. > > what is not so reasonable is suddenly deciding that you are going to > *croak* on something which you didn't even test for with previous > releases. > > A warning would have been fine, at least for half a year or so. In that case we would be having this exact discussion 6 months from now. Breaking broken code is always good. +1 for HTTP::Message. If you don't want new versions of modules, then *don't upgrade them*. 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] uri_for() doesn't encode to utf8 first argument
* On Tue, May 06 2008, Dmitriy S. Sinyavskiy wrote:
> The -diff
>
> Index: Catalyst.pm
> ===
Please regenerate this diff without the whitespace changes. It is
completely unreadable in the current form.
Examples:
> - engine_class context_class request_class response_class stats_class
> + engine_class context_class request_class response_class stats_class
> -
> +
> -$c->stash->{data} =
> +$c->stash->{data} =
These spurious changes fuck up the history (when we apply the patch),
and they make it extremely difficult to review your changes.
GNU diff accepts an "--ignore-space-change" option that should remove
these extra changes.
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] FastCGI: incomplete headers (0 bytes) received from server
* On Tue, May 06 2008, Ryan Pack wrote: > I?m having an issue with my Catalyst app but I can only get it to break about > 1 > in 100 tries. The error log shows: > > > > [Tue May 06 11:02:46 2008] [error] [client 12.37.36.66] FastCGI: comm with > server "/u/lxlib/BookingEngine/script/bookingengine_fastcgi.pl" aborted: idle > timeout (60 sec), referer: http://be.genares.net/11 > > [Tue May 06 11:02:46 2008] [error] [client 12.37.36.66] FastCGI: incomplete > headers (0 bytes) received from server "/u/lxlib/BookingEngine/script/ > bookingengine_fastcgi.pl", referer: http://be.genares.net/11 > > > > The page does not show an error, but a new session is created instead of using > the existing session. I?m using Session::State::Cookie, Session::State::URI, > Session::Store::DBIC. All are on the latest versions. > > > > Any help would be appreciated. Do you have requests that are taking more than a minute? It looks like your frontend server is assuming the Catalyst app died, when in reality it might just be taking a long time. I'm not sure what would cause the session stuff to behave differently. Probably time to add some $c->log->debug messages to your app in key places. 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] Invalid session ids being generated
* On Fri, May 09 2008, Hartmaier Alexander wrote: > Delete the session cache file! > I had a similar problem. > > -Alex > > > -Original Message- > From: Ryan Pack [mailto:[EMAIL PROTECTED] > Sent: Friday, May 09, 2008 1:03 AM > To: The elegant MVC web framework > Subject: RE: [Catalyst] Invalid session ids being generated > > I was able to fix it by downgrading Catalyst::Plugin::Session. We were > on 0.13 until I upgraded to .19 (latest) along with a bunch of other > Catalyst modules. Just as a last resort before I downgraded everything > back to the way it was I tried just downgrading > Catalyst::Plugin::Session and it worked! Woohoo! Both of these sound like fragile workarounds. If you guys can do a bit more digging, I would appreciate it. It would be good to actually fix the problems, after all. 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] session in DB example in Catalyst book
* On Sat, May 10 2008, Andreas Marienborg wrote: > On May 10, 2008, at 3:53 AM, Andrew wrote: > > > Using the Rockway's Catalyst book to help bring me up to speed on Catalyst > and I've got a problem that I can't figure out. > > On page 59, where it uses a database to store the session key, I've made > all the code changes, but when I start the server it gives me the > following > error: > > "Couldn't find a model named DBIC::Session at /usr/local/share/perl/5.8.8/ > Catalyst/Plugin/Session/Store/DBIC.pm line 143. > Compilation failed in require at script/addressbook_server.pl line 53." > > > You don't seem to have the Model you configured the session store to use. Do > you have the MyApp/Model/DBIC/Session.pm file? You shouldn't need that. The DBIC::Schema model will create all the classes under the root namespace from the result source classes in the DBIC schema. However, I think the namespace in the book is AddressDB, not DBIC. 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] IMPORTANT: To all Catalyst::Whatever Authors, please read and ACT
* On Sun, May 11 2008, Ashley wrote: > On May 10, 2008, at 7:18 PM, Kieren Diment wrote: >> On 11 May 2008, at 10:56, Ashley wrote: >> >>> Two or more config examples is nice and kind to users and I think >>> it's a great best practice to include it (maybe someone would >>> attach a simple script to dump several formats? If I have time this >>> weekend, I'll try if no one beats me to it). >> >> That on the other hand would be useful (sorry missed it first time). >> Could you make a CatalystX::ConfigMaker that dumps >> catalyst_config.pl into $PATH somewhere? CatalystX::Starter is a >> small and simple module that shows how to do this. > > I'd love to try. I'll take a look this weekend. Thanks for pointing me > at the starter modules, I hadn't looked at it yet. > > > The biggest stumbling block and learning curve with Catalyst is almost > undeniably DBIC… Maybe we should consider a script that files tickets > against any documents that reference it going forward. I mean sure > it's useful but think of all the questions it generates! Why DBIC > users pollute the Catalyst list all the time and some of the devs even > cross post. > You seem upset that we're ditching YAML. Don't be. The defaults are designed for people that don't know how to change the defaults. You already know how to use YAML, so use it and forget what everyone else thinks. Config::General is not nearly as good as YAML, but it is harder to completely fuck up; that's why we're changing to it. The idea is to make it easier to not care for people who don't care :) Personally, I'll be sticking with YAML. I will continue to recommend it for people who are willing to learn the syntax. People complain that Perl is "too hard" all the time, but it's only hard because they don't know it. For those of us that know it, the things that make Perl hard to learn make it easier to use. YAML is the same way. If you are willing to accept that it has syntax, it will make your life easier. If you religiously believe that configuration files don't have syntax, then it's not the syntax for you :) 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] session in DB example in Catalyst book
* On Sun, May 11 2008, Andrew wrote:
> And I'm doing everything exactly as the book states except the config change
> of putting the database path in the YAML file - it's still in the
> AddressDB.pm file.
>
> I looked in the DBIC.pm file which is generating the error message and the
> method that is causing the error is below:
>
> sub session_store_model {
> my ($c, $id) = @_;
>
> my $dbic_class = $c->session_store_dbic_class;
> $c->model($dbic_class, $id) or die "Couldn't find a model named
> $dbic_class";
> }
>
> My question is where does $c->session_store_dbic_class come from? Is it a
> class that I'm suppose to define or is it a class that is suppose to be
> included in the DBIC module?
This is just an internal method that implements the details of storing
session data with DBIx::Class. (If you want the details, read the
Catalyst::Plugin::Session code, and see how it delegates to
Catalyst::Plugin::Session::Store and Catalyst::Plugin::Session::State.
Catalyst::Plugin::Session::Store::DBIC is the DBIC.pm that you are
referring to; its methods become $c->whatever when loaded into your app.
All Catalyst plugins currently work this way; all of their methods
become $c-> or YourApp-> methods as soon as you load them in the "use
Catalyst" line.)
I have a feeling that you are not following the book. In Chapter 4, I
never call the database model "DBIC", I call it "AddressDB". On page
60, I show the necessary configuration:
AddressBook->config->(session => {
dbic_class => 'AddressDB::Session',
flash_to_stash => 1,
});
You'll note that the word "DBIC" never appears in the program text, and
hence shouldn't be in error messages. Are you sure that your
configuration is setup like the book. Are you sure something in your
YAML file isn't overwriting this?
(If you look in the code bundle, you can find this in
chapter7-AddressBook/lib/AddressBook.pm. Chapter 7 is just an extension
of Chapter 4, which for some reason isn't included in the tarball. I
will probably update that in the next few days. It makes sense to me,
but not anyone else :)
FWIW, later on in the book I call the model DBIC for the other
applications; I like this style better and I wrote those parts more
recently :)
Anyway, after you've checked that "DBIC" doesn't appear in your
configuration, let me know if it still doesn't work.
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] session in DB example in Catalyst book
* On Sun, May 11 2008, Andreas Marienborg wrote:
> On May 11, 2008, at 7:14 AM, Andrew wrote:
>
>> And I'm doing everything exactly as the book states except the
>> config change of putting the database path in the YAML file - it's
>> still in the AddressDB.pm file.
>>
>> I looked in the DBIC.pm file which is generating the error message
>> and the method that is causing the error is below:
>>
>> sub session_store_model {
>>my ($c, $id) = @_;
>>
>>my $dbic_class = $c->session_store_dbic_class;
>>$c->model($dbic_class, $id) or die "Couldn't find a model named
>> $dbic_class";
>> }
>>
>> My question is where does $c->session_store_dbic_class come from?
>> Is it a class that I'm suppose to define or is it a class that is
>> suppose to be included in the DBIC module?
>>
>>
> It is a config setting:
>
> http://cpansearch.perl.org/~danieltwc/Catalyst-Plugin-Session-Store-DBIC-0.06/lib/Catalyst/Plugin/Session/Store/DBIC.pm#session_store_dbic_class
>
> - andreas
Actually, it's just a (documented) method:
=head2 session_store_dbic_class
Return the L class name to be passed to C<< $c->model >>.
Defaults to C.
=cut
sub session_store_dbic_class {
shift->config->{session}->{dbic_class} || 'DBIC::Session';
}
As I've mentioned in two other posts, I assume Andrew's problem is that
he didn't configure the plugin as per p.60 of the book. After reading
this method, I am even more sure that I'm right :)
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] Suggestions for CatalystX::Installer
Just a meta comment. I think you would get more attention from a subject like "Looking for suggestions for CatalystX::Installer". The current subject implies that you are making suggestions instead of soliciting them. As a result, suggestion-makers may be ignoring your post. 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] Suggestions for CatalystX::Installer
* On Mon, May 12 2008, Mitch Jackson wrote: > Paul, > > Is CatalystX::Installer going to be used to help initally create a > project, or help deploy a project that is already written to a server > for use? If it is for helping deploy a project to a server, there's a > few things I think would be helpful. > > - Generate a cpan preresiquites list from the source Module::ScanDeps > - Generate a file or archive of some sort that can be used to deploy > the application "make catalyst_par" > - Install the preresiquites via CPAN "make installdeps" > - Implement setting up the initial database state, perhaps through > $schema->deploy(), or a SQL script, or another method DBICx::Deploy > - run the app's test suite and report if tests succeed or fail "make test" 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] FYI: Contracting possibilities
* On Tue, May 13 2008, Ian Docherty wrote: > Ian Docherty always feels people who refer to themselves in the third > person are being pretentious, as in http://zenshadow.vox.com/profile/ > ;-) Any English style guide will tell you to write a self-introduction like this. 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] uri_for() doesn't encode to utf8 first argument
* On Sat, May 17 2008, Dmitriy S. Sinyavskiy wrote:
> It strange I haven't got received letter with this...may be deleted
> by antispam (
Yes, your mailserver rejected my reply. However, the list did receive
it.
> Nevertheless I've done it now:
>
> Index: Catalyst.pm
> ===
> --- Catalyst.pm (revision 7759)
> +++ Catalyst.pm (working copy)
> @@ -948,10 +948,12 @@
> my $params =
>( scalar @args && ref $args[$#args] eq 'HASH' ? pop @args : {} );
>
> +$path =~ s!/+!/!g; # strip extra slashes '///'
> +unshift(@args, split('/', $path));
> carp "uri_for called with undef argument" if grep { ! defined $_ } @args;
> s/([^$URI::uric])/$URI::Escape::escapes{$1}/go for @args;
>
> -unshift(@args, $path);
> +
>
> unless (defined $path && $path =~ s!^/!!) { # in-place strip
> my $namespace = $c->namespace;
OK, but it looks like you forgot the tests. :) However, I think the
patch is sound. Please check that things like:
uri_for('/controller/ほげ')
*click that link*
dispatch correctly, though.
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] Catalyst using fast CGI
* On Thu, May 22 2008, [EMAIL PROTECTED] wrote: > Dear List > > I am trying to get Catalyst working through apache by using fastcgi. I am > having difficulty in achieving this. This problem is that I seam to be > getting apache error code 13. My config for my website is: > > > ServerName www.dnsemail.co.uk > DocumentRoot /var/www/dnsemail > ErrorLog logs/www.dnsemail.co.uk.error_log > TransferLog logs/www.dnsemail.co.uk.access_log > > > # Allow CGI script to run > > Options +ExecCGI > > > # Tell Apache this is a FastCGI application >Alias / /var/www/dnsemail/script/dnsemail_fastcgi.pl/ > > > SetHandler fastcgi-script > > > > Options ExecCGI > Order allow,deny > Allow from all > AddHandler fcgid-script .pl > > > > I am running it on Fedora Core 6 with Apache 2. Can someone point me in > the right direction in getting Catalyst framework running under Apache 2. I don't use mod_fcgid (I do use mod_fastcgi), but it seems odd to not have a directive like "FastCgiServer" somewhere. I guess the AddHandler could be doing that, but since it's not working, probably not. http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiServer 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] Userpasswords
* On Thu, May 22 2008, J. Shirley wrote:
> On Thu, May 22, 2008 at 12:48 PM, Stephan Jennewein <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> what's the common way to add user with encrypted passwords with the algorithm
>> i've chosen in the config . There are nice plugins for authenticating users
>> but no for create new users. I tried to write a hook for the schema, but it
>> won't work. Can anyone give me a working solution ?
>>
>> Stephan
>>
>
> That depends how you are storing the users, which you didn't really explain.
>
> I'll just assume that you are using
> Catalyst::Authentication::Store::DBIx::Class and have a DBIx::Class
> schema class that you store your users in.
>
> If that assumption is correct, simply use DBIx::Class::EncodedColumn
>
> http://search.cpan.org/~groditi/DBIx-Class-EncodedColumn-0.1/lib/DBIx/Class/EncodedColumn.pm
As an aside, here's the script I use for creating password hashes (using
EncodedColumn and Bcrypt):
use strict;
use warnings;
use DBIx::Class::EncodedColumn::Crypt::Eksblowfish::Bcrypt;
use Term::ReadLine;
chomp(my $password = Term::ReadLine->new($0)->readline('Password> '));
print DBIx::Class::EncodedColumn::Crypt::Eksblowfish::Bcrypt->
make_encode_sub->($password), "\n";
Yes, the password is echoed.
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] UTF-8 Conversion on the fly
* On Fri, May 23 2008, Mesdaq, Ali wrote:
> Hello Everyone,
>
> Got a question about utf8 conversions on the fly. I was wondering if
> anyone had experience and some pointers of good practices for taking a
> webpage thats stored as a blob in mysql then serving that page after its
> been converted to utf8. Right now the way this is implemented is
> conversion before storage but I never liked that idea. The engineer who
> did it thought utf8 conversion is always going to be a smooth thing. I
> also don't like the fact we don't store the orginal copy of the page in
> the db its the converted copy. So I wanted to see if anyone here had
> good suggestions on how the original can be stored and just converted on
> the fly.
I'm not sure what this has to do with Catalyst, but just store the
original data and the encoding in the database, then
my $octets =
Encode::encode('utf-8', Encode::decode($stored_encoding, $stored_webpage));
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] TT output to a new browser window or tab
* On Sat, May 24 2008, Chris Devine wrote: > Yes, it is html for now, other formats later as options based on the html. > > What in need to know is how can I "fork" from within Catalyst to do this. I > have a form collect some options. The user hits submit. This window shows a > result (Ok, Error), and a go home button. The report is created and opened > into another window. This would be a JavaScript thing. Compute the report, cache it somewhere, and return the "it worked" page. That page should do window.open() to some action that returns the cached report. However, I'm not sure that you can do this in the day and age of popup blockers. YMMV. 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] Suggestions for CatalystX::Installer
* On Thu, May 29 2008, Matt S Trout wrote:
>> > my $sql_commands=CatalystX::Installer::Controller->new();
>> > $sql_commands->set_type('Entry');
>> > $sql_commands->set_action(sub{
>> >my ($self, $c,$database,$sql_file);
>> >system "sqlite3 $database < $sql_file";
>> > });
>
> Hmm. That smells a bit like Class::Workflow and/or Verby
Yes, definitely Verby. You really want actions to be classes, so you
can customize them easily.
>
>> > First, it scans for dependencies with Module::ScanDeps, and adds any
>> > dependencies not already found in Makefile.PL to Makefile.PL.
>
> No it doesn't That's a terrible, *terrible* idea. ScanDeps is heavy on the
> system and doesn't always get things right; I've seen it go rogue a
> few times.
Well, I think the idea is to pick some correct defaults that won't go
rogue (-c probably), run that, and then suggest to the developer that he
should consider adding the dependencies himself. The need for human
interaction is due to the fact that M::S will gladly say your app needs:
URI::http
URI::file
URI::dongs
URI::ftp
...
when you really only need "URI". Of course, a quick query of the CPAN
packages database can help the program help the user make a better
decision. ("Hey, these all come with URI-0.123476. Do you want *that*
to be the prereq instead?".)
Also, if someone wants to write a module to add dependencies to
Makefile.PLs, I would be happy to use it. This:
http://git.jrock.us/?p=elisp.git;a=blob;f=_local/cperl-project.el;hb=HEAD
needs to die very soon. I would rather have PPI (via Stylish) deal with
it.
> You missed 'make installdeps'.
"installdeps" is a dependency of "all", so it will probably Work Out All
Right.
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] ANNOUNCE: Catalyst::Devel 1.07 and Catalyst::Manual5.7012 released to CPAN
* On Tue, Jun 03 2008, Marcus Ramberg wrote: > On 3. juni. 2008, at 21.03, Octavian Rasnita wrote: > >> From: "Bill Moseley" <[EMAIL PROTECTED]> >>> Yes, whitespace issues in YAML can be frustrating. Can you give an >>> example of a case where POD and YAML were causing new users >>> confusion? >> >> YAML is hard to understand for a blind developer because if he >> arrows up or down the text, he hears the current line spoken, but >> he doesn't know how many spaces is that line indented. >> YAML is useful only visually, but not all the programmers can see, >> so from this point of view, other configuration modules are better. > > Does that mean it's impossible to code python if you are blind? Theoretically you can use a Braille TTY. 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] Users hierarchy
* On Wed, Jun 04 2008, jakac wrote: > I checked out DBIx::OO::Tree also but using this module would mean > that I would have to change my table schema (add columns parent,lft,rgt,mvg).. > I don't see why this is necessary since the whole thing needs only two colums > - > user_id and parent_id ...? If I know a user_id then I can always get all users > where their parent_id = this_user_id etc. > > Like I said in my previous postings - I really don't want to change my > database > schema because a lot of other applications depend on it. There is no problem > adding columns lft,rgt and mvg but if I change my primary key from > "user_id" to "id" and change my column "parent_id" to "parent" like this > module > requires it would mean changing a lot of other older applications which depend > on this database... > What about DBIx::Class::Tree? I've used this for a user hierarchy, actually. 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] Users hierarchy
* On Tue, Jun 03 2008, [EMAIL PROTECTED] wrote:
> while ($found==false && $ancestor) {
Perl does not have a "false" operator.
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] Users hierarchy
* On Fri, Jun 06 2008, [EMAIL PROTECTED] wrote:
> Gulp, that should have been 0 :)
Actually, it should have been "!" as in "if(!$found ...)". Perl has a
variety of "false" values including 0, undef, and the empty string.
Perl's built-in boolean operators return "undef" or "1" as false or
true, but other libraries use other values ("" and "hey, it worked!",
for example).
Additionally, 0 is "==" to a variety of true values, including the
string "0 but true".
So just use "!$boolean" to test if something is false :)
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] Authorization ACL: future plans?
* On Fri, Jun 06 2008, ivorw wrote: > Hi guys, > > (Yuval please note: this concerns one of your modules) > > Are there any plans afoot to build on > Catalyst::Plugin::Authorization::ACL? I have a requirement for a couple > of enhancements, and I'd like to sound out the list before jumping in > and coding. > > > 1. I'd quite like the idea of a generic "resource", that users have > access to, rather than just a controller method. The resource could be > or correspond to a file on the server's fs, a wiki page, a diary > appointment, etc. > > The resource would have a set of permissions, controlled through the model: > * See (whether this resource actually appears at all) > * Read (Are the contents of the resource visible/executable?) > * Modify > * Delete > * Grant (who can change the permissions for this resource) I don't think a Catalyst plugin is where this sort of code belongs. It belongs in a layer unrelated to Catalyst. I also don't think this can be done generically enough to make it useful. (Too generic and it won't save any time, too specific and you'll be the only user.) For something DBIx::Class-specific, look at DBIx::Class::Schema::RestrictWithObject. Basically, you have an object that does the access control (per-resultset), and your application never sees data that the user isn't allowed to see. This is the right level of generic-ness. Authorization::ACL is completely differnet,BTW. It's nice for walling off part of your application; mainly so you don't have to check $c->user_exists for every action that $c->user touches. But, it doesn't try to guess what your application's data means, it just turns part of the app off based on some rules you set up. Again, the right level of generic-ness. What I'm trying to say is that access control and C::P::A::ACL are two different things. Catalyst shouldn't even be in your mind when you are designing the access rules and code for your data. > The resource also has an owner (user) and a group (role). > Each of the permissions above can be set to one of 'owner', 'group', > 'world' or none. > > Proposed module name: Catalyst::Plugin::Authorization::ACL::Resource > > 2. Full blown access control lists > > For more sophisticated requirements, we have an actual list: > > Include: list of entities > Exclude: list of entities > > > each entity can be one of the following: > * A user > * 'owner' > * A role > * 'group' > * An ACL (i.e. nesting) > > This enhances option 1 above by allowing the permission to be an ACL > besides 'owner', 'group', 'world' or none. > > Proposed module name: Catalyst::Plugin::Authorization::ACL::Full > > What do people think? Feedback please. > > By the way in case you are wondering, I am looking to write a CMS that > sits on top of Catalyst. Write the CMS first, then factor out the access control code. If you do it the other way around, it probably won't turn out the way you want. (Nothing is worse than writing a library and then having your application that uses it work around it. Trust me, I've done that.) 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: Catalyst site design drafts feedback thread
* On Wed, Jun 11 2008, Gabriel Vieira wrote: > Hahaha. Nice! I didn't see that. > On Wed, Jun 11, 2008 at 8:33 PM, Devin Austin <[EMAIL PROTECTED]> wrote: >> On Wed, Jun 11, 2008 at 4:30 PM, Kieren Diment <[EMAIL PROTECTED]> wrote: >>> On 12 Jun 2008, at 07:23, Aristotle Pagaltzis wrote: >>>> * Matt S Trout <[EMAIL PROTECTED]> [2008-06-11 22:05]: Just so you know, it's completely impossible to follow the flow of the discussion when you top-post on top of 5 other mails. If you comment inline, and edit out the posts that you aren't replying to, it's much easier to follow. 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: Catalyst site design drafts feedback thread
* On Thu, Jun 12 2008, Cory Watson wrote: > I've been ignoring this thread because it's a bunch of bikeshedding. Basically, I agree. Let's let the designers design. There is nothing worse than a committee that distorts the artist's vision. (When everyone agrees on every detail, you get Microsoft. Bland.) We are never going to settle on a design that satisfies everyone or every concern. Live with it :) It all boils down to this. Catalyst is the only really useful Perl web framework. Perl is the only really useful language for writing web applications. So people are going to use Catalyst regardless of whether the background color on the website is #83f8e2 or #85f9ff. Let's spend our collective efforts doing something other than arguing about colors. 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: Catalyst site design drafts feedback thread
* On Fri, Jun 13 2008, Jonathan Tweed wrote: > On 13 Jun 2008, at 13:51, Jonathan Rockway wrote: > >> It all boils down to this. Catalyst is the only really useful Perl >> web >> framework. Perl is the only really useful language for writing web >> applications. So people are going to use Catalyst regardless of >> whether >> the background color on the website is #83f8e2 or #85f9ff. > > I think you're missing an 'if you only know Perl'. > > Otherwise you're just talking shit ;-) I'll bite. I've written web applications in Java, PHP, Cold Fusion, Common Lisp, Haskell, and OCaml. None of these languages have anywhere near the number of libraries that Perl does, and as a result I either waste time reimplementing something trivial-but-tedious, or I settle for half-assed solutions. Java is close, but the syntax is so tedious it's hard to pay attention to the libraries. (PHP and CF aren't real programming languages, so it's not a surprise that there are no libraries.) The Python, Ruby, and Common Lisp communities all share the attitude towards libraries -- if it works for the author, it's perfect; as a result most of the libraries are half-assed special cases that may or may not be helpful. I don't know how Perl escaped this, but it did... most module authors feel obligated to make something generally useful. (Of course there's a lot of junk, but that's fine; nobody uses the junk libraries.) It's a real shame that Lisp doesn't have Perl's libraries, 'cause I really like it a lot better than Perl. It's just that it's not useful for anything. (Emacs Lisp is the exception; not that great of a programming language, but you can do anything in about 5 lines of code thanks to the extensive libraries. But I digress.) 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: Private Chained Actions?
* On Fri, Jun 20 2008, Marc Sebastian Pelzer wrote:
>>> You need a screwdriver, not a hammer.
>>
>>sub hello_setup : Private {
>> my ($self, $c) = @_
>> $c->stash->{setup} = 'done';
>>}
>>
>>sub hello : Private {
>> my ($self, $c) = @_
>> $c->forward('hello_setup'); # <-
>> $c->res->body('hello! setup is ' . $c->stash->{setup});
>>}
>>
>>sub index : Path : Args(0) {
>> my ($self, $c) = @_
>> $c->detach('hello');
>>}
>
>
> thanks for the hint. Thats what I'm doing right now. I thought that
> there may be a more elegant way of doing this. Especially for a
> longer/ more complex chained setup :) Also, doing it this way it does
> not look not too nice in the dispatcher path in the debug logfile -
> hello() comes before hello_setup() :-|
Yeah, that's ugly. What you really want are method modifiers:
package MyApp::Controller::Foo;
use Moose;
BEGIN { extends 'Catalyst::Controller' };
sub main_page :Path Args(0) {
my ($self, $c) = @_;
$self->hello($c);
}
sub hello {
my ($self, $c) = @_;
$c->res->body('hello! setup is'. $c->stash->{setup});
}
before hello => sub {
my ($self, $c) = @_;
$c->stash->{setup} = 'done';
};
1;
You can also say:
before [qw/method1 method2 method3 .../] => sub { ... }
to do something before a bunch of methods at once. See "perldoc Moose"
for details.
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: Private Chained Actions?
* On Fri, Jun 20 2008, Aristotle Pagaltzis wrote:
> * Jonathan Rockway <[EMAIL PROTECTED]> [2008-06-20 22:20]:
>> Yeah, that's ugly. What you really want are method modifiers:
>>
>> package MyApp::Controller::Foo;
>> use Moose;
>> BEGIN { extends 'Catalyst::Controller' };
>>
>> sub main_page :Path Args(0) {
>> my ($self, $c) = @_;
>> $self->hello($c);
>> }
>>
>> sub hello {
>> my ($self, $c) = @_;
>> $c->res->body('hello! setup is'. $c->stash->{setup});
>> }
>>
>> before hello => sub {
>> my ($self, $c) = @_;
>> $c->stash->{setup} = 'done';
>> };
>>
>> 1;
>
> That’s even uglier. Imagine there isn’t just `hello` but half a
> dozen other methods all sharing the same setup. So the setup code
> is one or two screens down the source file. Now when you look at
> `hello` you have absolutely no indication whatsoever that there
> might be other code running before it.
I guess. But this is Perl, there's never any indication of anything.
There's no indication that my function is receiving arguments of a
particular type. There's no indication that my function throws
exceptions. There's no indication that "use Foo" has side effects.
Even in Catalyst, there is a ton of implicit behavior. There is no
indication that begin/end/auto applies to my action (at least until the
action runs).
So in other words, I disagree with you. I use method modifiers all the
time, and I (and others) have no problem maintaining code. If you want
ultimate verbosity, just call hello_setup from hello. If you think you
can keep a few method modifiers straight in your head, then use the
Moose approach.
TMTOWTDI.
> Note that using method modifiers instead of Cat dispatch means
> that the Catalyst::Stats breakdown of a request will be coarser.
The less my web framework does for me, the better. If I want profiling,
I'll use DashProfiler.
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] Running java inside Catalyst
* On Sun, Jun 22 2008, Lindolfo \"Lorn\" Rodrigues wrote: > system function it's a bad idea, if you really need to run Java inside Perl, i > did not try that inside Catalyst, you can check Inline::Java http:// > search.cpan.org/~patl/Inline-Java-0.52/Java.pod > I think that will not a problem to use Inline::* inside Catalyst. You do know that Inline::Java uses system() to call java, right? 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] Capture page on server?
* On Mon, Jun 23 2008, Martin Ellison wrote: > Sorry, bit of a newbie question: is there any way that I can run an action but > capture the results (server-side) to a file? Doing so client side is easy (eg > wget) but I want to keep the page text on the server and to automate the page > generation/save. If you want to log the output of every request, you probably want to wrap finalize and save the file after it runs. If you want to run an arbitrary request against your application and see the result, you want the Subrequest plugin. It would be better for your app to not depend upon your app, though. Calling a method is simpler, faster, and cleaner than running an entire request and capturing the result, so try to structure your app in such a way as to allow that. 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/
[Catalyst] Re: [Catalyst-dev] can't upgrade the scripts
* On Mon, Jun 23 2008, Chae Lee wrote: > Hi all, You sent this message to the wrong list. -dev is for development *of* the framework, not development *with* the framework. Anyway... > > I'm using Catalyst 5.7014. and I tried the script upgrade as below: > > $ catalyst.pl -force -scripts MyApp > Couldn't create MyApp/script/myapp_cgi.pl", "No such file or directory" at / > Users/cglee/perl5/bin/catalyst.pl line 52 > > by the way, there is another directiory trunk/ between MyApp/ and script/ > since > I'm using SVN for my app. so I tried the next; > > $ catalyst.pl -force -scripts MyApp/trunk > ... > ... > > > how can I upgrade the scripts? > > has anyone already answered(or solved) for this? if so, let me know. I would just symlink MyApp/MyApp to MyApp/trunk, then cd MyApp and run 'catalyst.pl -force -scripts MyApp'. 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] Capture page on server?
* On Mon, Jun 23 2008, Ryan D Johnson wrote: > On this subject though, PageCache is a really useful low-work > high-return way to do some simple page caching from Catalyst. It has > built-in support for only caching unauth'd pages, caches based on > wildcards, all kinds of useful stuff. > > But there is one caveat I ran into when playing with it. If you're doing > Content-Encoding negotiation in Catalyst (with C::P::Compress::Gzip, for > example), the PageCache doesn't know about it and will cache either the > gzip'd or plain version depending on which is first hit, then serve that > out indiscriminately to all clients. > > As an example, hit a cachable page with your web browser (which supports > gzip), > then try to fetch the same (cached) page with curl or something; you'll > get the gzip'd stream of gibberish. Use Angerwhale::Plugin::Cache instead. It solves this problem. 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] Very long request time weirdness
* On Tue, Jun 24 2008, luke saunders wrote: > In order to get some info on how long requests were taking and where > the bottlenecks were we put some code into MyApp::finalize which wrote > info gained from $c->stats to the DB so we could easily check them > later (code given below). Occasionally we get a request where total > time ($c->stats->elapsed) is very long (more than 50 seconds) but each > individual action executes very quickly (they usually sum to less than > 1 second). So presumably something is happening between the end action > and finalize which is taking ages, but what on earth could that be? Feeding data to an end-user with a slow connection? I assume your frontend server would buffer that, but who knows? Perhaps you can get the number of CPU seconds your process has used at the beginning of the request (around prepare or execute) and then again before writing data to the log, to see if you are CPU bound those 50 seconds. If you are, then your problem is the app. If you aren't, then the problem is IO. You might also want to log the size of the data you're returning. If you see no CPU usage, and the response body is huge, this further points towards IO being a problem. 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] use base or use parent?
* On Tue, Jun 24 2008, Dermot wrote:
> Hi,
>
> I have a controller with
>
> use parent 'Catalyst::Controller';
>
> I can't find any info on 'parent'
>
> I want to use FormBuilder and tried to use it like so
>
> use parent 'Catalyst::Controller';
> use base qw(Catalyst::Controller::FormBuilder);
>
> FormBuilder sends debug messages to the server but my controller can't
> locate the method:
>
> [error] Caught exception in MyApp::Controller::Submissions->edit
> "Can't locate object method "form" via package "MyApp" at line 47
>
>
> sub edit : Local Form {
> my ($self, $c, $id) = @_;
> my $sub = $c->model('MyAppDB::Submissions')->find({id => $id});
> if ($c->form->submitted && $c->form->validate) {
> $sub->name($c->form->field('name'));
> $c->stash->{message} = 'Updated'.$sub->name;
> $c->forward('list');
> }
> ...snip
>
> I think this is a problem of inheritance. Can any one advise?
Use $self->formbuilder, not $c->form. You might enjoy this page:
http://dev.catalyst.perl.org/new-wiki/thebookerrata
Anyway, I'm not sure why you would think that "use base
'Catalyst::Controller::FormBuilder'" in a controller would add methods
to $c, so I won't even ask.
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] connecting to more than one database
* On Thu, Jul 03 2008, jagdish eashwar wrote: > So when I was able to do what I had in mind at the database level, I thought > it > would be possible to do the same with Catalyst and DBIx::Class also. I still > haven't lost hope. It would be painful and inelegant to have to replicate the > employee details for each of the web applications in the respective > databases. Logically, your two databases are one database. You should consider a database to be a universe in isolation, with no access to anything else. If you have dependencies between two databases, they are not two databases, they are one database. >From an implementation standpoint, how do you expect the database engine to implement things like locks across two databases? (Berkeley can do it, but I don't know about RDBMSs though.) Basically, what you want to do with DBIC is not possible. I don't think DBMS (should) allow this either. So you really need to combine your two databases. As a last resort, I seem to remember SQL Server being able to alias tables between databases. If your DBMS allows something like that, then you can do that. You might also be able to add stored procedures to the first database that returns the tables in the second database. DBIC will probably deal with those, at least for reads. But that's not really optimal; just make everything one database. 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] connecting to more than one database
* On Thu, Jul 03 2008, jagdish eashwar wrote: > Putting all the tables in one database is a solution. I am afraid, however, > that when I create a model using script/MyApp_create.pl for a specific > Catalyst > application, I'll get all the tables in the database into my DBIC schema. > Is there a way of making MyApp_create.pl pick up only a subset of the tables? Well, if you're using the same database for two apps, it makes sense that you should use the same DBIC schema for both of those apps. Write the schema once, use the parts you need in each application. That's why the schema is a library. As for tables that aren't relevant to a given app, the answer is simple; just don't use those when you don't need them. 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] XPath, DOM problem
* On Tue, Jul 08 2008, Herr Verdieck Götz wrote:
> Hi,
>
> I try to generate a site content menu from a xml file.
>
> In my TT file I have the following syntax:
> [%
> # USE prod_tree = XML.Simple('config/xml/hele_de_tree.xml'); # OK this works
>
>
> USE xpath = XML.XPath('config/xml/hele_de_tree.xml'); # ERROR
> #USE dom = XML.DOM;
> #prod_tree = dom.parse('config/xml/sitemap.xml'); # ERROR
>
> -%]
BTW, XML::LibXML is a much nicer library for doing anything related to
XML in Perl. Using anything else is slightly crazy ;)
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] javascript in Catalyst using Template Toolkit
* On Fri, Jul 18 2008, [EMAIL PROTECTED] wrote:
> Did this work?
>I have actually tried this and yes, like Emily,my JS stuff is store
> in myapp/root/lib/site .
>
>
>
>
>
> Does not work.
> Did I miss anything out?
Unless you have an action that matches "/multifile.js", nothing is going
to happen when that URL is visited. If you use Static::Simple, put the
javascript in /static, and link via $c->uri_for('/static/multifile.js'),
then something will happen.
Someone else suggested linking to '/lib/site/multifile.js'. I don't
think that will work either.
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: javascript in Catalyst using Template Toolkit
* On Sat, Jul 19 2008, Aristotle Pagaltzis wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-07-19 04:10]:
>> i got the issue fixed up by add "root/static" to
>> lib/myApp/View/TT.pm and yes, 'Static::Simple' was used.
>>
>> Here's an extract...
>>
>> __PACKAGE__->config({
>> CATALYST_VAR => 'Catalyst',
>> INCLUDE_PATH => [
>> myApp->path_to( 'root', 'src' ),
>> myApp->path_to( 'root', 'lib' ),
>> myApp->path_to( 'root', 'static' ),<-- Added this in
>> ],
>> PRE_PROCESS => 'config/main',
>> WRAPPER => 'site/wrapper',
>> ERROR=> 'error.tt2',
>> TIMER=> 0,
>> });
>>
>>
>> Thank you for the prompt response/help, guys!
>
> This seems very wrong. Why should adding the static file
> directory to the TT include path do anything if Static::Simple is
> supposed to serve the file? Something is almost certainly going
> on here that you do not actually want.
Yes, thank you for pointing that out. The above config does not solve
the more-above problems.
If you want to [% INCLUDE your.javascript %] then that's fine. But if
you want to serve statically, then this only works because of some weird
coincidence.
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] auto re-load of application yaml config file?
* On Tue, Jul 22 2008, Marc Sebastian Pelzer wrote:
> Hello,
>
> I'm running a Catalyst application under mod_perl and wonder if there
> is a Plugin available that detects changes on the main application
> .yml config file and does a automatic re-load if needed? It not -
> what would be the most elegant (and less I/O intensive) way of doing
> this? Would it be enough to do a
>
> __PACKAGE__->config( 'Plugin::ConfigLoader' => { file =>
> my_config.yml' } );
> in my Root controller when I detect a change? Also, is there a way to
> store the state (maybe the mtime of the config file) in memory without
> being lost between requests? Or do I need to store the mtime in a
> database/memcache/tempfile (which would be "expensive")?
> Many thanks in advance for any hint :)
Reading the config file causes a lot of things to happen (instantiating
your controllers with certain arguments, for example), so this won't
work. You really need to just restart the app from scratch when you
change the config.
If you want lightweight on-the-fly configurability, you should roll your
own. You will have to engineer something with a compromise that meets
your needs. For example, checking the database every time you read a
variable will mean the config settings update quickly, but you also slow
your app way down. YMMV and all that ;)
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] Preventing simultaneous logins
* On Wed, Jul 23 2008, Daniel McBrearty wrote: > What I'd like to do is check if this user is already logged in at some > other computer, and deny access if so. I would probably store sessions in the database, and then store the session ID in the user table at login time (current_session) or something. Then when they log in again, you can join in the session row, check the expiration time in that row, and then allow/deny the login. You can also use that opportunity to delete the session from the database so that the other machine no longer has a valid session. I don't think the file-based session stores provide this much flexibility, but you could probably hack something similar if you really needed to. 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] auto re-load of application yaml config file?
* On Thu, Jul 24 2008, Pedro Melo wrote: > And yes, the tradeoff is mod_perl, which is more complex than FCGI. How does Perlbal require mod_perl? I would just run the application's own HTTP server behind Perlbal. Not very complex at all. -- 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] Squatting::On::Catalyst
* On Tue, Jul 29 2008, John Beppu wrote: > Now that composition and embedding of web apps is becoming a reality, we have > to start anticipating needs like this. For example, the documentation for an > app that's built to be embedded could state that: Expectations suck. Use Ernst, tag your attributes and classes with the necessary metadescription, and introspect. The user should tell the computer what to do, not the other way around. > * It expects a user object to be in its session's "u" key. The Session should be a class of course, and the class should have an attribute with a metadescription that "does" Squatting::Description::User, or whatever. > * The app will expect to be able to call the ->name method on this user > object. (Some apps may want more... others less... this is just a > hypothetical example.) The User class should have a class metadescription that describes what methods return what data. > * If that key is undef, the app will assume the current session is not in a > "logged in" state. Why not force the class to implement a role that provides a "user_is_logged_in" method? Then there is no need to guess. Just call the method and see. (Actually, it would be better to be able to meta-describe methods... but I haven't implemented this yet.) - Someone else mentioned in another post how this sort of thing is impossible with forms, but it's actually not. Ernst and Reaction have solved this problem. We generate the DBIC files from the "row" class's metadescription, and we generate the form handling code from the same metadescription. Unfortunately all of my examples are locked up in internal code right now (very experimental), and I think mst's code is mostly in the same state :) Anyway, here is an old Ernst demo: http://git.jrock.us/?p=Ernst.git;a=tree;f=prototype/catalyst/TestApp;hb=HEAD The important part: http://git.jrock.us/?p=Ernst.git;a=blob;f=prototype/catalyst/TestApp/lib/TestApp/Backend/Record.pm;hb=HEAD Anyway, it turns out that this is a simple problem, but just needs some tweaking for maximum enjoyment and ease of use. (We've gotten rid of TT in the "production" version, for example, because the fragments are too hard for designers to work with. Instead, we are using Template::Refine.) 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] Debug with FCGI
* On Fri, Aug 01 2008, Angel Kolev wrote: > Doesn`t work too. All debug output goes to apache log. I tryed with -e > option - same result. Use the "keep error" option, -e. 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] Debug with FCGI
* On Fri, Aug 01 2008, Jonathan Rockway wrote: > * On Fri, Aug 01 2008, Angel Kolev wrote: >> Doesn`t work too. All debug output goes to apache log. I tryed with -e >> option - same result. > > Use the "keep error" option, -e. Hmm, I should read the whole post before I reply. Anyway, it should work. -- 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] catalyst start-up
* On Sun, Aug 17 2008, Matt S Trout wrote: > That makes no sense. > > How does restarting other processes have any effect at all? Locking? Not that I've ever seen this for sessions or cache, but it could make sense if the app is doing its own locking of some shared resource. 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] Catalyst::*::REST and Javascript
* On Fri, Aug 15 2008, Patrick Donelan wrote:
> Hi Robert,
>
>
> Whereas ExtJS seems to be of form:
>
>userResource = new Resource('http://example.com/users?id=001')
>
>
> ExtJS can send any sort of HTTP request you like - it doesn't really care how
> RESTful your URLs are. Like all Ajax toolkits the connectivity portion of the
> library is just a glorified wrapper around the browser's XHR object.
FWIW, this style URL is not "not RESTful". It's perfectly RESTful -- it
refers to exactly one noun, and you can mutate it with HTTP methods
(presumably). That's REST.
If you wanted to make it non-RESTful, then you would do things like:
GET http://example.com/users?id=001&operation=delete&archive=0
or
GET http://example.com/users/001?operation=delete&archive=0
That's RPC, not REST. But as you can see, the URL scheme is irrelevant
when determining what is and is not RESTful.
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] Catalyst::Response - send a file
* On Tue, Aug 19 2008, Dermot wrote: > This method will work well for binary files. I have opted > $c->response->header() method for now. You haven't described what that method is. There are two things you need to do to send a file for download. 1) Set up the HTTP headers (Content-disposition) so that the browser knows what to do. 2) Actually send the data. In your original post, you hand-waved sending the data. A number of posters told you how to do it. Now you're saying you've "opted [for the] header method". That doesn't make any sense. So what exactly are you doing? 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] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
* On Wed, Aug 27 2008, Tobias Kremer wrote: > Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>: > >> On 2008-08-26 14:18:18 +0200, Tobias Kremer wrote: >> > Just out of pure curiosity: Why is it that there are dedicated >> > "flash:" entries in the storage for the flash? Wouldn't the >> > session be enough? >> >> The "flash:" rows were used for compatibility with Store::DBI. We can >> break compatibility if people find the it not very useful. > > We definitely should! IMHO five queries per request to the database just for > the > session and flash stuff is inacceptable. If your app is really slowed by the number of queries to load session/flash, use this: http://git.jrock.us/?p=Catalyst-Plugin-Session-HMAC.git;a=blob;f=lib/Catalyst/Plugin/Session/HMAC.pm;hb=HEAD 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] #catalyst
* On Sat, Sep 13 2008, Zbigniew Lukasiak wrote: > Hi there, > > I did not see how it looked like at the channel a few days ago - but I > hope that my irc client malfunction did not offend someone too severly > (unlike that famous wardrobe of some US pop singer). And that the > bane for my home machine is not eternal and can be released soon. You're unbanned now. In the future, just /msg an op (usually mst) and they will take care of it (especially if it's because your client malfunctioned). 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] tips for troubleshooting/QAing Unicode
* On Sat, Sep 27 2008, Darren Duncan wrote:
> Maybe you're already aware of this, but I've found from experience
> that troubleshooting encoding/Unicode problems in a web/db app can be
> difficult, especially with multiple conversions at different stages,
> but I've come up with a short generic algorithm to help test/ensure
> that things are working and where things need fixing.
A simplified version:
1) Identify sources of input to your application
2) Ensure that you called Encode::decode('the-character-encoding', ...)
on all that data. If you are dealing with pure ASCII, I guess you can
skip this step. Encode::decode('us-ascii', ...) probably works though.
Sometimes libraries will do this for you, but don't count on it, verify
it. If you don't see the code doing it, it's not being done.
Note that the existence of the "UTF-8 flag" does not tell you whether
this is being correctly done. Your program can be perfectly
Unicode-clean and never have a string with the UTF-8 flag on.
If you see stuff like utf8::encode and utf8::decode or Encode::_utf8_on
and so on, your program is horribly broken. Use Encode properly before
continuing.
Finally, keep in mind that there are odd sources of data. Hash keys
from config files, file names, file extended attributes, form params,
form field names, URIs(*), etc.
(*) handle these manually, there is no mention of Unicode in the URI
standard.
Some people do things like put Japanese text in the HTTP headers. This
is not allowed. ASCII only.
3) Identify where you output text.
4) Ensure that you called Encode::encode('output-character-encoding', ...) on
any data that leaves your program.
In the case of dealing with external applications, make sure that you've
told them what the output character encoding is. Databases have flags
for this, HTTP has the Content-type header, etc.
5) You're done.
I have found that Devel::StringInfo is very helpful; you can have it
dump the information when you are inputting data... it will make it
clear when you have bytes instead of characters.
Be sure to test with all sorts of input -- I always use characters from
ASCII ("foo"), Latin ("ÿ"), and Japanese ("ほげ"). If your app gets
those three right, it is probably OK.
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: CSRF
* On Wed, Oct 01 2008, Moritz Onken wrote: > I imagine a case where the attacker's site opens a iframe to your > site which exploits a XSS issue and can send the hole form > information back to the attacker's site. He has now the HMAC and > the random string. I was under the impression that you could open an iframe to someone else's site and manipulate it from javascript running on your own site, without relying on any vulnerabilities on that site. Maybe not? Maybe flash can do this? (Why do we even have iframes? For serving ads?) Anyway, Template::Refine is a great module for adding stuff to forms, in the event that your form builder isn't already adding some sort of unique token. I actually use it to add the "name" field to all the inputs; at some point I will just "encrypt" these like Seaside and many other frameworks do. You can then validate these with an ActionClass. 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] Success stories please
* On Sun, Oct 05 2008, Andrew Rodland wrote: > On Sunday 05 October 2008 06:16:57 pm Mark Keating wrote: >> On 6 Oct 2008, at 00:01, J. Shirley wrote: >> > Andy apparently just wanted to start a flamewar. This "article" is >> > idiotic, the reasons more so. I'm disappointed in perlbuzz in general >> > as it now holds the same amount of respect as getting my news from The >> > National Inquirer. >> > >> > I'd encourage people to rather blog about finding the article to be in >> > poor taste, then post their success stories. Commenting here or on >> > that blog entry is going to be buried. >> >> ++ to this > > Thirdeded. The best cure for Andy is to ignore him. BTW, I have to mention one of Andy's talks at OSCON: http://en.oreilly.com/oscon2008/public/schedule/detail/3001 It's called "People for Geeks", i.e. "how to be nice to people". If it's possible to die from an irony attack, you might not be seeing much more of me :) 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] ANNOUNCE: SimpleDB - Auth configuration made easy
* On Mon, Oct 27 2008, Thomas L. Shinnick wrote: > If I explicitly override the default, by explicitly requesting 'clear', > because > my requirements explicitly need this ability, then I must change the code to > get rid of the warning? Ahh, but it's for the 'simple', who must be guided, > and can't be bothered to read the warnings in the text so bonk'em repeatedly > in > the logs till they mind what you say. Which is to explicitly not use the > feature which you've explicitly provided? (sigh) Open the file in your text editor and remove the warning. Problem solved! You didn't even need to post to a mailing list! 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] How to detect cancelled requests?
* On Wed, Oct 29 2008, Stuart Watt wrote: > [snip] > Our ideal would be a non-buffered model, where results are displayed > incrementally, and where user requests can cancel a query, at worst > when the next hit is about to be displayed. Since we fetch hits and > render them incrementally, this should just work. > > It seems likely that IIS is most of the problem. Personally, I have > never been happy with it (especially with ISAPI/PerlEx), but we are > required to use IIS at least, and with much of the documentation > relating to Catalyst on IIS being slightly on the sketchy side, it is > hard to know how to improve the position. Ideally, we could use the > following This seems like a perfect time to use something like Comet. The user submits a query and immediately gets back a page that says "query is running" that updates itself with the results as they come in. It can also have a cancel button to explicitly cancel the query. (You can run the cancel code when they close the tab also.) It will complicate your architecture a bit, but it should also be a nice UI improvement. It is nice when you don't have to tell your clients to reconfigure their browser to not time out when waiting for your database. (I've been there.) Anyway, if you do this, you will have explicit messages for everything, and you won't have to guess what SIGPIPE or whatever really means. You will have a "user_clicked_the_cancel_button" event, and you can deal with that accordingly. All this assumes that you have some sort of job queue for running the long query. It may seem like a lot of overhead for the really fast queries, but it probably won't be in practice. > [more snipping] > 3. Any experience with trying to get HTML passed to IIS in a > non-buffered manner -- it all seems buffered right now You are using $c->res->write for this, right? 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] Catalyst, MVCs and other MVCs
* On Mon, Nov 03 2008, Jacinta Richardson wrote: > I know that Catalyst is about dispatch more than about CRUD, but I'd love > pointers to a tutorial about how to get a basic system with working CRUD up > and > working within minutes. I'm not sure that this will tell you anything valuable. What's good for quickly hacking something together in five minutes is rarely good for an application that needs to be maintained over many years. 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] [META] Advent calendar
* On Tue, Nov 04 2008, Dermot wrote: > Is there going to be an advent calendar for this year? Sure, why not? -- 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] Very Simple Question
* On Mon, Nov 17 2008, Amiri Barksdale wrote:
> I am a new user of Catalyst, and from reading the documents and
> reading blogs posts I have been able to set up my schema, my authz/
> authen, sessions, and my Mason view. I have a very simple question,
> though.
>
> This in a controller
>
> $c->stash->{elements} = [$c->model('DB::Elements')->all];
>
> Requires this in a view:
>
> <% $element->{_column_data}->{title} %>
To expand on the other reply to this message, I'd like to point out that
you should never access the hash values backing an object directly.
Although sometimes you might get the right data this way, it's not
guaranteed -- you need to call the documented accessor methods. (For
example, sometimes the hash data is populated lazily; meaning that the
first time you call $object->foo, foo is calculated, stashed in
$object->{foo}, and returned. Until you call the method, though, the
hash value doesn't exist.)
Anyway, I assume you arrived at $element->{_column_data}->{title} by
looking at the output of Data::Dumper. That's a fine strategy, but you
should also add Class::Inspector to your debugging arsenal. You can
find what methods you can call on an object with code like:
use Class::Inspector;
say join "\n", @{Class::Inspector->methods(ref $object, 'public')};
I also recommend that you try out Devel::REPL if you haven't already.
At the very least, it will save you from typing the 'say join "\n",
@{...}' part.
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] One App, multiple databases
* On Wed, Nov 19 2008, Jose Luis Martinez wrote:
>
> sub ACCEPT_CONTEXT {
> my ($self, $c) = @_;
>
> my $user_db = $c->lookup_the_users_db();
> $self->{'dsn'} =~ s/#DATABASE#/$user_db/;
>
> return $self;
> }
>
I am really surprised that this works at all. When do you actually ever
connect to the database with the DSN in $self->{dsn}? (I am also
surprised that the DBIC version works.)
Anyway, mutating objects is wrong. You should do things like this:
package MyApp::Model::UsersDatabase;
...
sub ACCEPT_CONTEXT {
my ($self, $c) = @_;
return $c->user->get_database($c->config->database_info);
}
Then your user class should do something like:
sub get_database {
my ($self, $database_info) = @_;
$self->database_connection($self->connect_to_database($database_info))
unless $self->has_database_connection;
return $self->database_connection;
}
(You can write cleaner code with a before method modifier, if you use
Moose.)
The idea is that each user has his own database connection, stored in
the user object, and Catalyst just returns the right thing when you say
$c->model('UsersDatabase'). This is much easier to reason about.
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] Mapping CGI scripts URLs
* On Fri, Nov 21 2008, Christian Lackas wrote: > I assume this is some kind of strange safety feature? Nope, something must be wonky in your app. I tested it, and .cgi paths work fine. (You might want to try the myapp_test.pl script in the debugger.) However, I think I would probably not implement the legacy URL translation as a controller. I would override prepare_path or similar to translate the CGI-style URL to the new-style URL before the rest of your app (including the dispatcher) ever sees it. This way your app doesn't know that the legacy URLs exist at all, and you won't have to test two sets of URLs (or the potentially odd interactions with uri_for and whatnot). 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] OT: Use the CPAN, Luke?
* On Sun, Nov 30 2008, Toby Corkindale wrote: > If the automated install fails, people are likely to say "bah, this > Perl thing sucks, let's go for that similar app written in > PHP/Java/Ruby instead - at least it's simple to install!" Why do you care about what other people do? If these people can't even install a CPAN module, it's unlikely that they were going to become active contributors. > PAR goes a little way to solving this, but then one needs to > distribute multiple versions for all the platforms you support, and > hope they have a decent PAR version too. (Again, Debian stable has > issues.) This says more about Debian than PAR. -- 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/
[Catalyst] BerkeleyDB session storage
Hi all, I have been using Session::Store::FastMmap for storing sessions for a long time. This has caused me a lot of pain, because it turns out that Cache::FastMmap is a *cache*, and is happy to randomly discard unexpired sessions. (If there are too many, one is too big, or there are too many on the same 64k page, or ...) Anyway, I have written Catalyst::Plugin::Session::Store::BerkeleyDB as a drop-in replacement. It is based on BerkeleyDB, and will never lose any sessions (unless your disk fails). It is safe to share between multiple processes, and even multiple machines with the right environment setup. It can also integrate with your existing BDB database, which is good for KiokuDB users. (And by default, it requires no configuration.) The module is on the CPAN now, so please take a look at the docs if you are interested. Email me or the list if you have questions / problems / patches / etc. :) One more thing -- you might want to make sure $c->delete_expired_sessions gets called from time to time, to make sure that you are not keeping useless data around on disk. A public action hit by cron everyday should be fine. (No harm will be done if an evil user hits the action.) Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$" http://blog.jrock.us/ ___ 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] mod_perl converts latin1 to utf8 !?
On Sun, Dec 21, 2008 at 11:52:27PM +0100, Bjørn-Helge Mevik wrote:
> I am developing a simple Catalyst application using MySQL, FormFu and
> TT. I have everything encoded in ISO-8859-1: the data in MySQL, the
> Perl files, the FormFu .yml files, and the TT templates. (I am even
> running in a ISO-8859-1 locale, for what it's worth.)
>
> Following the advice in an earlier thread ("Charset best practice" -
> <http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg00284.html>),
> I have overridden the process() method of Catalyst::View::TT with a
> version that does $c->response->content_type('text/html;
> charset=iso-8859-1');
> ...
>
> What can I do about this? Can I tell mod_perl to "leave my characters
> alone"? Have I made an error somewhere?
Sort of. Working with latin-1, or any character encoding, is just
like working with UTF-8. When you work with UTF-8, you need to say
something like this:
my $data = Encode::decode('utf8', $raw_data);
process($data);
print Encode::encode('utf8', $data);
We decode the binary data into text, then we work with the text, then
we encode the text back into binary data for the wire (or the user's
xterm, in this case).
When you are working with iso-8859-1, you need to do exactly the same
thing. Everything you read needs to be decoded, and everything you
need to write needs to be encoded. (In this case, it is sort of an
uphill battle since most people use Unicode now, and that is the "code
path" with the most testing. There are probably places that helpfully
treat your latin-1 as utf-8, which is definitely incorrect of it.)
Decoding is probably a no-op, so focus on the encoding part. Take a
look at Catalyst::Plugin::Unicode (specifically finalize_body, I
think), and change the Encode::encode('utf-8', ...) to
Encode::encode('iso-8859-1', ...)
I bet this will solve your problem, but if not, let us know what code
you tried and where, and we will try to help you some more.
Regards,
Jonathan Rockway
___
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] how to confirm before deleting
* On Wed, Jan 21 2009, Dave Howorth wrote: > Paul Falbe wrote: >> That works thank you very much. Don't know how many google searchs I did >> trying to find that out! > >> Rodrigo-51 wrote: >>> Paul, how about a javascript confirm() box? > > ... and if the user has Javascript disabled? Please enable Javascript. It's Two Thousand Fucking Nine. Seriously. 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] London Perl tutorials - 25th & 26th February 2009 - day 2 includes Cat+DBIC
* On Wed, Jan 21 2009, Robert L Cochran wrote: > This is really tempting. I don't know if I can afford this one. And I > would have to get to London several days before Day 1, because jet lag > hits me hard. Hmm. If you are in the US, I will point out that Stonehenge often does open-enrollment Perl (and Catalyst) classes like this. We don't have any planned at the moment, but that would change if I received e-mails indicating interest :) So anyway, if you are interested, e-mail me off list, and we will see if we can set something up. 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: Detach won't detach?
* On Mon, Jan 26 2009, Aristotle Pagaltzis wrote:
> sub auto :Private {
> my ( $self, $c ) = @_;
>
> return 1 if user_logged_in;
>
> $c->redirect( $c->req->base );
> return 0;
> }
If we are playing golf, I submit:
sub auto :Private {
my $c = pop;
return user_logged_in || $c->redirect( ... ) || 0;
}
Now I have that much more disk space free for pr0n!
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: Detach won't detach?
* On Tue, Jan 27 2009, pie3...@comcast.net wrote:
> Why not
>
> sub auto :Private {
> my $c = pop;
> return user_logged_in || $c->res->redirect( ... );
> }
Because now the correctness of your application depends on undocumented
behavior (the return value of $c->res->redirect).
--
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: Detach won't detach?
* On Thu, Jan 29 2009, Octavian Rasnita wrote: > I see. In that case $_->[-1] could be used instead of $c, but it is not very > nice... BTW, I thought I would reply to this thread and remind everyone that this is just supposed to be funny at this point. If you actually write your code this way, you are crazy... and not in a good way. Aristotle's code is the idiomatically correct version, so that's what you should aim for in this case and in general. 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] Objects and persistence
* On Fri, Jan 30 2009, Christopher Taranto wrote: > On Fri, January 30, 2009 7:43 am, Marco Vittorini Orgeas wrote: >> Hi, >> I am approching in those days the Catalyst framework. >> I am also quite new to persistence of Objects, and therefore before start >> building my application I need some clarifications, because I don't want > > I don't think this is a Catalyst/DBIx::Class issue as much as an object > serialization issue. Once you have serialized your objects, certainly you > can store in the DB. > > Check out this tutorial on Perlmonks: > > http://www.perlmonks.org/?node_id=8070 Things have changed in the 10 years since that article was written. The best serializers are now YAML::XS and Data::Dump::Streamer. Also, if you want a real object database, you want KiokuDB: http://www.iinteractive.com/kiokudb/ It handles "object graphs", which means that if you can express it in memory in Perl, you can persist it and query it. It also has a DBI backend (though we use the BDB backend) for storing objects in a DBI-supported relational database, and you can even use the Search::GIN indexer to extract fields from objects into database columns, for fast object lookups. (It is not, however, an ORM -- most of the data is opaque and only makes sense when viewed through KiokuDB.) We are using KiokuDB for some very high-profile applications now, and it works great for us. It is fast, easily scalable (with BDB replication), and saves us the tedium of dealing with a RDBMS (and ORM) that we don't even need. YMMV. 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] [PATCH] [RFC] Seed the RNG in Catalyst::Engine::FastCGI
* On Mon, Feb 02 2009, Andrew Rodland wrote: > Due to the way FastCGI does its business, when running as an "external" > FastCGI, the perl interpreter and the Catalyst app are initialized before the > FCGI process manager does its forking. Since modern versions of Perl seed > rand() "eagerly" on startup, this leads to all of the FastCGI children > inheriting the same RNG state, and very nonrandom behavior (such as CAPTCHAs > that appear to get "stuck"). > > I've thought over the problem and decided that the only appropriate place for > a fix is in Engine::FastCGI. A srand anyplace else (including the app code) > would run either too early (not solving the "shared state" problem) or too > late (re-seeding on every request is Bad.) Wait, is there a reason why we can't do this in FCGI::ProcManager instead? This is something that affects everyone using FCGI, not just Catalyst. -- 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] Removing
* On Tue, Feb 10 2009, Jim Spath wrote:
> Will removing the plugin and calls to localize provide an appreciable
> performance boost? We do call the method alot in our templates.
Maybe. It is impossible to know without measuring it.
Try running your app with Devel::NYTProf [1] and seeing what's slow. If
localize isn't slow, removing it isn't going to speed up your app.
[1] http://search.cpan.org/~timb/Devel-NYTProf-2.07/lib/Devel/NYTProf.pm
The basic idea is:
$ perl -d:NYTProf script/yourapp.pl
$ ab -n 1 http://localhost:3000/path/to/slow/page
$ GET http://localhost:3000/quit [2]
$ nytprofhtml
< read profile in your web browser>
[2] sub quit :Global { exit(0) }, so that NYTProf can exit cleanly
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] RFC: The paradox of choice in web development
> The community will benefit from more bloggers and success stories Actually, the community will probably benefit most from writing code. Talking about talking about something doesn't actually buy you much. New modules that make programming easier are definitely more appealing all around. It's also important to keep in mind that 99% of people that read social news sites (like Programming Reddit) are idiots that only read things they agree with. Wasting your time trying to "educate" these folks is just going to make you very, very bitter. I'm not bitter... not at all... 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] RFC: The paradox of choice in web development
* On Wed, Feb 18 2009, Dermot wrote: > Yes there is, at first glance, a lot of choice but is there. I would > say TT and Mason are the only realistic choices (for HTML). If by "realistic" you mean "unmaintainable for both designers and developers", then yes, you've described Mason and TT. The only qualities that Mason and TT have over other options is that they have been around for a while. > And ONE of the reasons why is because they have both been published > and by the patron of Perl, O'Reilly. Unless your being published by > O'Reilly (or Addison) your not hitting the right audience. LOL. Just so you know, O'Reilly recently fired pretty much everyone Perl-related. Perl.com is basically dead, and they probably won't be publishing any more Perl books. That, IMHO, is not particularly supportive of Perl. > There is lot's of choice out there but you don't have to dig very far > to find out what "best" is. The key to finding the "best" is not by doing what books tell you to. It's by trying the various options, and seeing which one works best according to your mental model of the problem you want to solve. I know everyone wants easy answers and wants to avoid thinking... but if that's you, you've chosen the wrong field. 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] Accessing a Controller from ~/script
* On Thu, Feb 19 2009, Dermot wrote:
> # MyApp/lib/Model/Adaptor.pm
> package MyApp::Model::Adaptor;
This is a poor choice in naming -- you should name it for its function
("FooImporter") instead of the Catalyst mechanics it uses.
--
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] Malformed requests may break $c->req->uri_for()
* On Fri, Feb 20 2009, Merlyn Kline wrote: > One of the checks it does is basically this: > >telnet myserver 80 >GET / > HTTP/1.1 >Host: myserver > > So the returned page includes their XSS test code in any https links because > I generated them from $c->req->uri_for()->as_string(), and so the security > test fails. The issue is that you need to escape the HTML output, right? should become, when linkified, . If you do that, there's no security problem... although the link is useless (which may be a secondary issue to deal with). (If the security scanner complains about the escaped form, it's dumb. It's not a security problem.) 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: decoding in core
Braindump follows.
* On Fri, Feb 20 2009, Tomas Doran wrote:
> On 6 Feb 2009, at 17:36, Bill Moseley wrote:
>>
>> Sure. IIRC, I think there's already been some patches and code posted
>> so maybe I can dig that up again off the archives.
>
> Please do.
>
>> But, sounds like
>> it's not that important of an issue.
>
> The fact that nobody is working on it currently is not an indication
> that it isn't an important problem to try to solve.
I meant to write a plugin to do this a long time ago, but I guess I
never cared enough.
The problem with writing a plugin or making this core is that people
really really want to misuse Unicode, and will whine when you try to
force correctness upon them.
The only place where you are really allowed to use non-ASCII characters
are in the request and response. (HTTP has a way of representing the
character encoding of its payload -- URLs and Cookies don't.)
C::P::Unicode handles this correct usage correctly. The problem is that
people want Unicode to magically work where it's not allowed. This
includes HTTP headers (WTF!?), and URLs. (BTW, when I say Unicode, I
don't necessarily mean Unicode... I mean non-ASCII characters. The
Japanese character sets contain non-Unicode characters, and some people
want to put these characters in their URLs or HTTP headers. I wish I
was making ths up, but I am not. The Unicode process really fucked over
the Asian languages.)
So anyway, the plugin basically needs to have the following config
options, so users can specify what they want. Inside Catalyst, only
Perl characters should be allowed, unless you mark the string as binary
(there is a CPAN module that does this, Something::BLOB).
* Input HTTP header encoding (ASCII default)
(this is for data in $c->req->headers, cookies, etc.)
(perhaps cookies should be separately configured)
* Input URI encoding (probably UTF-8 default)
(the dispatcher will dispatch on the decoded characters)
(source code encoding is handled by Perl, hopefully)
* Input request body encoding (read HTTP headers and decide)
* Output HTTP headers encoding (maybe die if this happens, because
it's totally illegal to have non-ascii in the headers)
* Output URI encoding ($c->uri_for and friends will use this to
translate the names of actions that are named with wide characters)
* Output response body encoding (this needs to update the HTTP
headers, namely the charset= part of Content-type)
I think that is everything.
There are subtle issues, like knowing not to touch XML (it's binary),
dealing with $c->res->body( ), and so on.
One last thing, if this becomes core, it will definitely break people's
apps. Many, many apps are blissfully unaware of characters and treat
text as binary... and their apps kind-of appear to work. As soon as
they get some real characters in their app, though, they will have
double-encoded nonsense all over the place, and will blame you for this.
("I loaded Catalyst::Plugin::Unicode, and my app broke! It's all your
fault." Yup, people mail that to me privately all the time. For some
reason, they think I am going to personally fix their app, despite
having written volumes of documentation about this. Wrong.)
Anyway, I just wanted to get this out of my head and onto paper, for
someone else to look at and perhaps implement. :)
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: decoding in core
* On Fri, Feb 20 2009, Jonathan Rockway wrote: > Braindump follows. Oh yeah, one other thing. IDNs will need to be decoded/encoded, probably. ($c->req->host should contain perl characters, but links should probably be punycoded. Fun!) -- 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] Requirements for Catalyst
* On Sat, Feb 21 2009, Octavian Râşniţă wrote: > Hello, > > It is very clear that a Catalyst app can't run on a shared host, but > it requires either a dedicated server or a VPS. > I am searching for web space providers that offer VPS and I've seen > that they use to set their tariff plans mainly on the guaranteed > memory, but I don't know which would be the necessary memory for a VPS > that runs an OS like Fedora or CentOS, Apache, Perl and Catalyst. > > Could be 256 MB of memory enough? Or 512? Or I would need 1 GB or more > if I would like to run a Catalyst app? We run lots of Catalyst apps on the smallest Linode. I think they give us something like 340M of RAM. This is enough. I use a 512M Slicehost for jrock.us, which runs my mail server and a few Catalyst applications. Anyway, nearly every VPS provider I know of lets you add more memory easily. Buy the small one, and if you need more memory, upgrade. 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] Requirements for Catalyst
* On Sat, Feb 21 2009, Ashley wrote: > On Feb 21, 2009, at 3:04 PM, Jonathan Rockway wrote: >> We run lots of Catalyst apps on the smallest Linode. I think they >> give >> us something like 340M of RAM. This is enough. >> >> I use a 512M Slicehost for jrock.us, which runs my mail server and a >> few >> Catalyst applications > > > I know this is getting pretty off topic but I'm hovering on a VPS buy > so I'd like to hear more about why these two and what you'd say to > someone like me whose Perl is drastically better than my admin chops. > Put your referral code(s) if you've got them in your response too. Sure. Linode is cheaper and lets you use more recent versions of the Linux kernel. Slicehost is stuck on an ancient version of Xen that makes it impossible to run Debian Stable (as of last week). I went with Slicehost because they had good press at the time, but if I had time to re-configure my system and all that, I would switch to Linode. We use Linode for our work svn and web servers, client apps, kerberos, LDAP, OpenAFS, etc., etc. It works great. Both Linode and Slicehost have fine web interfaces. I can usually do what I need to do quickly. Slicehost takes super-agile (*rolls eyes*) approach of "less features", but I don't really miss any of Linode's features when I am using Slicehost. Slicehost does have one killer feature that Lindoe doesn't -- nightly, weekly, and on-demand full-system backups. This saved my life when I upgraded Debian Stable last weekend and it went horribly wrong due to the crappy version of Xen they are using. One click, and I was back to my old setup, with maybe a few lost mail messages. OTOH, if they didn't suck, I wouldn't have needed the backups. Anyway, you need sysadmin experience if you are going to use a VPS. You start with a Linux system with *nothing* installed. You log in through a "console", install your text editor (mg), sshd, and sudo, and then go from there. It is not "friendly" unless you are familiar with Linux already. You are on your own for file-level backups (I use duplicity + s3 for this. It works *wonderfully*.) Etc. etc. As for referral codes, I think you can use my email address if you pick slicehost. Dunno about Linode, but it is all paid for by $work so I don't really care. Oh yeah, one other option is Amazon EC2. They are very scalable (a perl script can buy you a new machine on demand), but not quite as friendly (if your instance crashes, all your data is lost). They are also kind of expensive. If you use S3, though, you can save a lot of money with the free EC2 <-> S3 transfers. 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] Maybe there is a need for some speedups of 'config' method ?
* On Sat, Feb 21 2009, Oleg Pronin wrote: > I use Catalyst in extremely loaded projects (currently 60.000.000 pageloads / > day). > Thereforce i'm perfomance paranoid man. > > One of 'black stones' is the ->config method. It has dramatically slow > perfomance at > config_method: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @ > 3808.94/s (n= > 4047) I have to ask... is this actually slowing down your application? Let's say that your app spends 1% of its time in $c->config. If you made $c->config 1x faster, you would only make your app 1% faster. > It would be VERY GREAT if we somehow make ->config works a hundred > times faster because everybody use ->config without any suspicions on > its speed. Although I haven't noticed config calls slowing down my application, I look forward to seeing your patch for this. FWIW, I usually only call $c->config at app startup time; I read it and pass values in it as arguments to other classes that need configuration information. I'm pretty sure this is the intended use; you shouldn't be looking in it during requests. 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/
