[Catalyst] The stash and go()
Hi!
I'm experiencing a little bit of weirdness with the stash when using
go(). I'd like to make sure I'm not making false assumptions. Is the
called action supposed to see the same context and/or stash as the the
calling action?
I'm noticing that my Root's auto-sub is getting called after calling
go() and I'm ok with that, but I need to retain the original values in
the stash. This is where the weirness kicks in... If I pass a stashed
value to warn() in Root::auto(), the called action will see the same
stash. Otherwise, the stash is empty, except for values stashed by
Root::auto().
Here's my code. Notice, that if I comment out the else-branch in auto(),
the template will have an empty stash, even though the called action
does its thing.
in Root.pm:
sub auto :Path :Args(0) {
my ( $self, $c ) = @_;
warn Root::auto();
if( ! $c-stash-{lang} ) {
warn Setting the default lingo;
$c-stash-{lang} = $c-config-{default_language};
}
else {
warn lingo is . $c-stash-{lang};
}
}
in (En|Sv|Fi).pm:
sub default :Private {
my ( $self, $c ) = @_;
my $path = $c-req-path;
my $lang = $self-_lang();
$c-stash-{lang} = $lang;
$path =~ s{\A $lang }{}msx;
$c-go( $path, [] );
}
Any info?
Alex
___
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] The stash and go()
Lars Balker Rasmussen wrote:
Yes. Your problem is that auto() needs a return value to say whether
to go forward with an action or not, so just add return 1; at the
end of auto(), and all will be fine.
...because otherwise auto() implicitly returns the result of the failed
conditional test if(! $c-stash-{lang} )! I see! Thanks! :-)
Alex
___
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
In data 15 februar 2009 alle ore 15:05:33, Octavian Râsnita orasn...@gmail.com ha scritto: From: David Wright dave-catal...@dexy.org I can't say much because of confidentiality, but from the Catalyst survey late last year, I can say that there are some pretty high profile places using Catalyst around about. It's public knowledge that two of the biggest streaming media websites in the world use Catalyst. Aye, that it is: http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html I think it could be good to have a link to a Success stories page in the main page of catalystframework.org that also show it. We're not BBC of course, but I took some time to add the My Opera community site (developed by our team in Opera Software) to appliedstacks.com. I never heard of this site before, but since it's mentioned here I assume it's somewhat trusted. http://www.appliedstacks.com/website/My%20Opera We use Catalyst not for the main backend stuff, but for the administration tools. We used it as a pilot project. If you want to mention it, you're welcome to do so. -- Cosimo ___ 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
We're not BBC of course, but I took some time to add the My Opera community site (developed by our team in Opera Software) to appliedstacks.com. Nice, thank you. I never heard of this site before, but since it's mentioned here I assume it's somewhat trusted. I have no idea who's behind AppliedStacks - I discovered it accidentally while doing the research for the Paradox of choice essay. I contacted their support e-mail with a bunch of bugs but no reply so far (it's been 4 days). AppliedStacks is a structured wiki and seems decent. Most of the sites added have been crawled by bots from pages listing Web sites powered by..., and those include our http://dev.catalyst.perl.org/wiki/sitesrunningcatalyst and http://www.catalystsites.org/ These two are the trusted places for listing Catalyst applications. Dan ___ 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 Sun, 15 Feb 2009, Kieren Diment wrote: and there you go, a pdf of all 363 pages of the catalyst docs. Well, that's a start. I think it would need some polishing to compete with the available Django docs. For easier comparison I've tossed a copy of the Django pdf manual up on my site: http://www.RawFedDogs.net/DjangoManual.pdf Kevin http://www.RawFedDogs.net http://www.WacoAgilityGroup.org Bruceville, TX Si hoc legere scis nimium eruditionis habes. Longum iter est per praecepta, breve et efficax per exempla!!! ___ 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
Hey all, Cosimo: Cool. I wanted to add that Denny de la Haye has put up perlisalive.com. He is looking for some success stories to cover. It'd be great if anyone who has some success stories / perl liveliness to share could submit them there. Jay On Feb 16, 2009, at 2:32 AM, Cosimo Streppone wrote: In data 15 februar 2009 alle ore 15:05:33, Octavian Râsnita orasn...@gmail.com ha scritto: From: David Wright dave-catal...@dexy.org I can't say much because of confidentiality, but from the Catalyst survey late last year, I can say that there are some pretty high profile places using Catalyst around about. It's public knowledge that two of the biggest streaming media websites in the world use Catalyst. Aye, that it is: http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html I think it could be good to have a link to a Success stories page in the main page of catalystframework.org that also show it. We're not BBC of course, but I took some time to add the My Opera community site (developed by our team in Opera Software) to appliedstacks.com. I never heard of this site before, but since it's mentioned here I assume it's somewhat trusted. http://www.appliedstacks.com/website/My%20Opera We use Catalyst not for the main backend stuff, but for the administration tools. We used it as a pilot project. If you want to mention it, you're welcome to do so. -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
I thought you refer to youporn.com ;-) - Alex Am Sonntag, den 15.02.2009, 13:39 +0100 schrieb Dan Dascalescu: Aye, that it is: http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html Thanks for the link. I added it as a support URL to http://www.appliedstacks.com/website/Bbc_Iplayer ___ 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/ *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ 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] RFC: New to Catalyst questions
Hello, So all this 'too many choices' talk has got me thinking. I'd like to put together some more web-available information for those transitioning to catalyst from other methods. To that end I'm soliciting your thoughts on things that you found particularly hard to get a grip on when you started using catalyst. (or that you are currently having trouble with) My intent is to pick the ones that are needed most and write them up (or sponsor). My working list is as follows (in no particular order.) 1) 'Getting' DBIx::Class (starting from a straight SQL-users point of view) 2) Basic Cat toolkit - the basic pieces you will want to produce your average web app. 3) Walkthrough of creation of a simple app end to end. Any others? Jay ___ 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: New to Catalyst questions
Well, people are going to want to know how Catalyst compares to *ahem* others as far as AJAX goes, certainly REST, and app servers like nginx, lighttpd, etc. Also, best practices. Walking beginning to end on an app is great, but a lot of the newbies end up having to throw away a lot of their newly acquired knowledge for what *should* be done. Perhaps best practices is best left for a thread on its own, but I think it should somehow be addressed. How about how Catalyst interacts with caching components/technologies? I'm just trying to think of production level necessities that we'll want to advertise to newcomers/defectors. Any of these sound legitimate? On Mon, Feb 16, 2009 at 1:32 PM, Jay Kuri j...@ion0.com wrote: Hello, So all this 'too many choices' talk has got me thinking. I'd like to put together some more web-available information for those transitioning to catalyst from other methods. To that end I'm soliciting your thoughts on things that you found particularly hard to get a grip on when you started using catalyst. (or that you are currently having trouble with) My intent is to pick the ones that are needed most and write them up (or sponsor). My working list is as follows (in no particular order.) 1) 'Getting' DBIx::Class (starting from a straight SQL-users point of view) 2) Basic Cat toolkit - the basic pieces you will want to produce your average web app. 3) Walkthrough of creation of a simple app end to end. Any others? Jay ___ 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/ -- Devin Austin http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost! ___ 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] New version of InstantCRUD
Looks like we are again discussing CRUD in Catalyst - so I decided to finally update InstantCRUD and release it to CPAN. It is still experimental. It is a 'scaffolding' - like the Rails one - it generates a CRUD application for a given dsn. Some more random thoughs: http://dev.catalystframework.org/wiki/crud/instantcrud and http://dev.catalystframework.org/wiki/crud/crud_and_rest (one caveat I completely disagree with the Preliminary URI naming guidelines). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: New to Catalyst questions
On Mon, Feb 16, 2009 at 2:01 PM, Octavian Râsnita orasn...@gmail.comwrote: Good idea. I think that many beginners find hard to learn Catalyst if they are coming from another framework, or even worse, from CGI.pm, because right after they begin, they need to learn DBIx::Class, Template-Toolkit, YAML or Config::General, and they might not understand very fast if a certain piece of text is a Catalyst code, or a DBIC one or something else. So I think a good tutorial should start without using DBIC or a configuration file, and without using a view and a model. It should be that kind of example that You shouldn't do this, but it is ment for understanding Catalyst easier. So the first MyApp.pm should use only the Root.pm controller, and print a very short of html text using $c-response-body(). The next sample should upgrade that example and show how Catalyst gets the parameters from a form, almost like CGI.pm does, and print the body in the same way, using the same warning that this code is not one that should be used. The next example should upgrade that sample app and tell why a view is needed, and how Catalyst can be used to forward to a certain view, tell how to configure a default view in MyApp.pm, and print the body using a view, but without using TT. The next example should show the advantage of using templates, introduce the TT view, the TT helper that creates the view automaticly, and print the page using a single .tt file, or a very small number of templates that create the page. There could be another sample that shows what kind of another view can be used to print the same content in a different way by just forwarding to it. Then maybe there would be good to introduce the configuration file, show how to use Config::General and why it is useful to use a config file. After the beginner started to understand how Catalyst works, how the actions work... the basic ones like Local, Index, Default, Private, Auto, introduce the model, and show a simple model that puts and gets the data in a more simple way, not by using DBI or DBIC. For example, it could open() a file and store the information to it. Then the model that should be teached should be the one that uses DBI, and show the user that he can have a $dbh object in any action, without needing to connect to the database by specifying each time the database name, username, password and other options. And only after the user will understand how Catalyst works, what means a model, teach them DBIx::Class which is pretty hard to understand if it is taught together with Catalyst without knowing any of them. Maybe here would be good a suggestion to stop and read a DBIx::Class tutorial, for understanding that module outside Catalyst, and understand even better which are the features offered by Catalyst and which are the ones offered by DBIC. Then... it could be much easier to understand how the authentication/authorization that uses DBIC works and other Catalyst features. It might sound too stupid, but for a beginner it should sound very stupid, and he should find it very easy to understand, with very little things to learn on each step, and finally he will see that he knows how to use Catalyst with its most important features. I also think that the explanation should be simple to understand even for those who don't know Perl at all. Octavian - Original Message - From: Jay Kuri j...@ion0.com To: catalyst@lists.scsys.co.uk Sent: Monday, February 16, 2009 10:32 PM Subject: [Catalyst] RFC: New to Catalyst questions Hello, So all this 'too many choices' talk has got me thinking. I'd like to put together some more web-available information for those transitioning to catalyst from other methods. To that end I'm soliciting your thoughts on things that you found particularly hard to get a grip on when you started using catalyst. (or that you are currently having trouble with) My intent is to pick the ones that are needed most and write them up (or sponsor). My working list is as follows (in no particular order.) 1) 'Getting' DBIx::Class (starting from a straight SQL-users point of view) 2) Basic Cat toolkit - the basic pieces you will want to produce your average web app. 3) Walkthrough of creation of a simple app end to end. Any others? Jay ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ I think we should also consider branching on whether someone is
Re: [Catalyst] RFC: New to Catalyst questions
Right... As I've said before, I'm not interested in the super-newbie area. I don't want to teach perl. Teaching better perl practices, sure. Teaching what a sigil is and what they mean in perl... not so much. Overall, I'm interested in helping those who are new to the Catalyst platform but are already interested and those who are thinking about it but need a bit more of a clear path through the reams of documentation that is 'out there.' Jay On Feb 16, 2009, at 2:10 PM, Devin Austin wrote: I think we should also consider branching on whether someone is experienced with perl or absolutely new. Catalyst certainly isn't for the new perl programmer, so there are some basics at the very bare minimum that need to be covered in perl first. -- Devin Austin http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost! ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: New to Catalyst questions
On 17/02/2009, at 8:01 AM, Octavian Râsnita wrote: Good idea. I think that many beginners find hard to learn Catalyst if they are coming from another framework, or even worse, from CGI.pm, because right after they begin, they need to learn DBIx::Class, Template- Toolkit, YAML or Config::General, and they might not understand very fast if a certain piece of text is a Catalyst code, or a DBIC one or something else. [snip useful description ] I would be very happy to recommend an approach such as this for the book, if someone wants to have it written by mid april (when the final first draft is done). Chapter three is a little like this, only we have a (non-database) model and view (very simple TT) straight away. Spoonfeeding like this isn't going to go into the book as space is limited and we have to get to the intermediate / advanced stuff quite quickly. But, a tutorial with this structure would be good and I'd support it going into Catalyst::Manual::Tutuorial as Catalyst::Manual::Tutorial::Beginner or something. It might sound too stupid, but for a beginner it should sound very stupid, and he should find it very easy to understand, with very little things to learn on each step, and finally he will see that he knows how to use Catalyst with its most important features. I also think that the explanation should be simple to understand even for those who don't know Perl at all. Octavian - Original Message - From: Jay Kuri j...@ion0.com To: catalyst@lists.scsys.co.uk Sent: Monday, February 16, 2009 10:32 PM Subject: [Catalyst] RFC: New to Catalyst questions Hello, So all this 'too many choices' talk has got me thinking. I'd like to put together some more web-available information for those transitioning to catalyst from other methods. To that end I'm soliciting your thoughts on things that you found particularly hard to get a grip on when you started using catalyst. (or that you are currently having trouble with) My intent is to pick the ones that are needed most and write them up (or sponsor). My working list is as follows (in no particular order.) 1) 'Getting' DBIx::Class (starting from a straight SQL-users point of view) 2) Basic Cat toolkit - the basic pieces you will want to produce your average web app. 3) Walkthrough of creation of a simple app end to end. Any others? Jay ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ 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] Using Selenium to test Catalyst app
2009/1/29 Tomas Doran bobtf...@bobtfish.net Given that _multiple_ people are hacking this to work correctly, wouldn't it make sense to send patches back to the author(s) so that it 'just works' for everyone else? So I volunteered to co-maintain Alien::SeleniumRC and the author has kindly given access. I've updated the selenium-server.jar and uploaded to CPAN. Should work for everyone now out of the box. If you've got other hacks you think people would benefit from send 'em through. Dan ___ 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/
