[Catalyst] Accessing a Controller from ~/script
Hi, I have an import script, MyApp/script/import.pl. I have found myself replicating about 40% of it's code into a Controller. Is there some way I can unify things and access subroutines from my controller in my import.pl or the vice versa? Thanx, Dp. ___ 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 19/02/2009, at 9:31 PM, Dermot wrote: Hi, I have an import script, MyApp/script/import.pl. I have found myself replicating about 40% of it's code into a Controller. Is there some way I can unify things and access subroutines from my controller in my import.pl or the vice versa? Yes, been there and done that. Write a standalone model (e.g. in Myapp/MyStandaloneModel.pm) that you can use the bulk of the code in the controller and the script. Use Catalyst::Model::Adaptor and ACCEPT context to get the logic of this standalone model out of the controller and into the catalyst model. ___ 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
2009/2/19 Kieren Diment dim...@gmail.com: On 19/02/2009, at 9:31 PM, Dermot wrote: Hi, I have an import script, MyApp/script/import.pl. I have found myself replicating about 40% of it's code into a Controller. Is there some way I can unify things and access subroutines from my controller in my import.pl or the vice versa? Yes, been there and done that. Write a standalone model (e.g. in Myapp/MyStandaloneModel.pm) that you can use the bulk of the code in the controller and the script. Use Catalyst::Model::Adaptor and ACCEPT context to get the logic of this standalone model out of the controller and into the catalyst model. Great thanx. I'll get straight to work on it. I might have a question or two later about the config. Dp. ___ 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 19/02/2009, at 9:52 PM, Dermot wrote: 2009/2/19 Kieren Diment dim...@gmail.com: On 19/02/2009, at 9:31 PM, Dermot wrote: Hi, I have an import script, MyApp/script/import.pl. I have found myself replicating about 40% of it's code into a Controller. Is there some way I can unify things and access subroutines from my controller in my import.pl or the vice versa? Yes, been there and done that. Write a standalone model (e.g. in Myapp/MyStandaloneModel.pm) that you can use the bulk of the code in the arg MyApp/lib/MyStandaloneModel.pm controller and the script. Use Catalyst::Model::Adaptor and ACCEPT context to get the logic of this standalone model out of the controller and into the catalyst model. Great thanx. I'll get straight to work on it. I might have a question or two later about the config. Check the 2008 advent calendar for ACCEPT_CONTEXT usage: http://dev.catalystframework.org/wiki/adventcalendararticles ___ 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] Where am I? ;-)
Jens Schwarz wrote on 02/19/2009 12:13 AM: Hi, with this somewhat philosophic question, I want to know, how a Controller knows, which of its action is currently active (p.ex. displayed to the user). http://search.cpan.org/~mramberg/Catalyst-Runtime-5.71000/lib/Catalyst.pm#$c-action And a similar question: How does the root controller know what other controllers are available in the app? http://search.cpan.org/~mramberg/Catalyst-Runtime-5.71000/lib/Catalyst.pm#$c-controllers -- Peter Karman . pe...@peknet.com . http://peknet.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: The paradox of choice in web development
-Original Message- From: Octavian Rasnita [mailto:orasn...@gmail.com] Sent: Tuesday, February 17, 2009 7:56 AM To: The elegant MVC web framework Subject: Re: [Catalyst] RFC: The paradox of choice in web development From: Ali M. tclwarr...@gmail.com When Catalyst is not chosen I personally believe it the combination of two things 1. Perl is no longer perceived as an easy language, or language that make development easier. More exactly,, Perl is considered a language hard to learn, that creates a code hard to maintain, a language that uses a strange OOP style (because I guess there are no books for Perl beginners that teach about Moose or Mouse), a language which is too flexible and because of this it is not prefered by the large teams of programmers because each of them could have a different style. 2. Catalyst perceivably doesn't offer enough added value for developers who are not that much into Perl to make the sacrifice and use Perl anyway. If the programmers are not that much into perl, this means that they don't know how to use DBIx::Class and Catalyst and possibly other few modules which are usually used by Catalyst developers, and in that case they can't understand the power of Catalyst. If Catalyst wants to compete with RoR or other frameworks, it should be as easy to install as those frameworks, and the simple apps should be also very easy to create. The comparisons between web frameworks are not based on the number of the requests they serve, or on the number of database tables they manage, or on the number of backend servers they are installed on, but on the number of web sites that use those frameworks, so those comparisons might show that there are 100 sites that use RoR and only 5 that use Catalyst, but don't tell that 3 from those 5 sites that use Catalyst have 3 times more visitors than all those 100 sites that use RoR. And of course, the conclusion is that RoR is much better. I think that the success of other languages, especially Python is also due to the fact that they support better Windows than Perl. WxPython is better developed than WxPerl, there are even screen readers that interact with the GUI of the OS in Windows and Linux, and finally... the number of programmers for Windows is bigger than the number of programmers for Linux. Most Perl programmers use to consider good to publicly despise Windows and those who use Windows, and also consider that Perl is a language for the web, while those who use Python or even Ruby consider them very good languages for creating programs with a desktop GUI. Sad to say, but I completely agree with this. It's quite ironic how the drive of open source has only furthered the need for OS agnostic software and platforms, which in turn, has actually made life harder for things like Perl that have strong origins in *nix OSes. Oh yeah, we love Linux as a platform for its [list of goodies], but we can't ask our day-to-day workforce to switch desktops, so we need OS agnostic platforms that we can build in Windows and deploy in Linux. Seems to be the credo echoing from the business world. I myself am currently trying to support multiple developers (content perl) working on a Catalyst app from Windows desktops and it's been a bit of a process. Cygwin seems to be providing the best solution right now, but Cgywin Perl fork()ing breaks frequently for me in Vista, so no HTTP::Prefork, which makes development much, much slower. I really, really want to be able to just run my Cat apps in Windows, and I probably could get it going under ActiveState or Strawberry if I stuck to it, but I _need_ it to not be that hard. I'm sure I'm not the only one. In today's world of software that is cross-platform and OS agnostic at its core, Perl 5 is showing its age. Still love it though. v/r -matt pitts ___ 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 19 februar 2009 alle ore 16:12:36, Matt Pitts mpi...@a3its.com ha scritto: I think that the success of other languages, especially Python is also due to the fact that they support better Windows than Perl. [...] Sad to say, but I completely agree with this. It's quite ironic how the drive of open source has only furthered the need for OS agnostic software and platforms, which in turn, has actually made life harder for things like Perl that have strong origins in *nix OSes. [...] I really, really want to be able to just run my Cat apps in Windows, and I probably could get it going under ActiveState or Strawberry if I stuck to it Does that mean that you haven't tried? but I _need_ it to not be that hard. I'm sure I'm not the only one. It's _not_ that hard. Perl has been good in the Windows world for long. Strawberry has improved this a great deal. Perl on Windows runs most of CPAN without problems. And yes, I sent my small amount of patches too, whenever it hurt me. Perl fully supports building on MSVC from 6 to 2008, and Win32 GCC. In today's world of software that is cross-platform and OS agnostic at its core, Perl 5 is showing its age. Cross-platform is one point where Perl excelled, and I think it's still very strong. Then if WxPerl is not developed as WxPython is not Perl's fault. -- 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
From: Matt Pitts mpi...@a3its.com -Original Message- From: Octavian Rasnita [mailto:orasn...@gmail.com] Sent: Tuesday, February 17, 2009 7:56 AM To: The elegant MVC web framework Subject: Re: [Catalyst] RFC: The paradox of choice in web development From: Ali M. tclwarr...@gmail.com When Catalyst is not chosen I personally believe it the combination of two things 1. Perl is no longer perceived as an easy language, or language that make development easier. More exactly,, Perl is considered a language hard to learn, that creates a code hard to maintain, a language that uses a strange OOP style (because I guess there are no books for Perl beginners that teach about Moose or Mouse), a language which is too flexible and because of this it is not prefered by the large teams of programmers because each of them could have a different style. 2. Catalyst perceivably doesn't offer enough added value for developers who are not that much into Perl to make the sacrifice and use Perl anyway. If the programmers are not that much into perl, this means that they don't know how to use DBIx::Class and Catalyst and possibly other few modules which are usually used by Catalyst developers, and in that case they can't understand the power of Catalyst. If Catalyst wants to compete with RoR or other frameworks, it should be as easy to install as those frameworks, and the simple apps should be also very easy to create. The comparisons between web frameworks are not based on the number of the requests they serve, or on the number of database tables they manage, or on the number of backend servers they are installed on, but on the number of web sites that use those frameworks, so those comparisons might show that there are 100 sites that use RoR and only 5 that use Catalyst, but don't tell that 3 from those 5 sites that use Catalyst have 3 times more visitors than all those 100 sites that use RoR. And of course, the conclusion is that RoR is much better. I think that the success of other languages, especially Python is also due to the fact that they support better Windows than Perl. WxPython is better developed than WxPerl, there are even screen readers that interact with the GUI of the OS in Windows and Linux, and finally... the number of programmers for Windows is bigger than the number of programmers for Linux. Most Perl programmers use to consider good to publicly despise Windows and those who use Windows, and also consider that Perl is a language for the web, while those who use Python or even Ruby consider them very good languages for creating programs with a desktop GUI. Sad to say, but I completely agree with this. It's quite ironic how the drive of open source has only furthered the need for OS agnostic software and platforms, which in turn, has actually made life harder for things like Perl that have strong origins in *nix OSes. Oh yeah, we love Linux as a platform for its [list of goodies], but we can't ask our day-to-day workforce to switch desktops, so we need OS agnostic platforms that we can build in Windows and deploy in Linux. Seems to be the credo echoing from the business world. I myself am currently trying to support multiple developers (content perl) working on a Catalyst app from Windows desktops and it's been a bit of a process. Cygwin seems to be providing the best solution right now, but Cgywin Perl fork()ing breaks frequently for me in Vista, so no HTTP::Prefork, which makes development much, much slower. I really, really want to be able to just run my Cat apps in Windows, and I probably could get it going under ActiveState or Strawberry if I stuck to it, but I _need_ it to not be that hard. I'm sure I'm not the only one. In today's world of software that is cross-platform and OS agnostic at its core, Perl 5 is showing its age. Still love it though. v/r -matt pitts As someone said it many years ago (but I don't remember who was), Perl is dead... or something like that was the idea. With that ocasion came the idea of creating Perl 6 that should be totally different, but who knows when it will be ready. A better native OOP support in Perl would be wonderful, but I think those other ideas about how Perl 6 should look like are more important, like to have a kind of virtual machine like in DotNet or Java, and to use bytecode precompiled binaries which are totally portable. Octavian ___ 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: RFC: The paradox of choice in web development
* Dermot paik...@googlemail.com [2009-02-19 16:15]: Ohh that's painful to hear. Is the venerable Mr Wall still there? That's going to hurt Perl. Eh? Larry has been off the O’Reilly payroll in a very long time. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] RFC: The paradox of choice in web development
-Original Message- From: Cosimo Streppone [mailto:cos...@streppone.it] Sent: Thursday, February 19, 2009 10:30 AM To: The elegant MVC web framework Subject: Re: [Catalyst] RFC: The paradox of choice in web development In data 19 februar 2009 alle ore 16:12:36, Matt Pitts mpi...@a3its.com ha scritto: I think that the success of other languages, especially Python is also due to the fact that they support better Windows than Perl. [...] Sad to say, but I completely agree with this. It's quite ironic how the drive of open source has only furthered the need for OS agnostic software and platforms, which in turn, has actually made life harder for things like Perl that have strong origins in *nix OSes. [...] I really, really want to be able to just run my Cat apps in Windows, and I probably could get it going under ActiveState or Strawberry if I stuck to it Does that mean that you haven't tried? I have, but I stopped working on CPAN installs in Strawberry when Data::UUID was failing with a build error that I don't remember. but I _need_ it to not be that hard. I'm sure I'm not the only one. It's _not_ that hard. Perl has been good in the Windows world for long. Strawberry has improved this a great deal. Perl on Windows runs most of CPAN without problems. And yes, I sent my small amount of patches too, whenever it hurt me. Yes, I need to be more proactive about it and figure out why it's not working, maybe when I get some tuits. Perl fully supports building on MSVC from 6 to 2008, and Win32 GCC. Thanks for the pointers. Talking about it makes me want to try and figure it out again. v/r -matt ___ 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
Cosimo Streppone wrote: It's _not_ that hard. Perl has been good in the Windows world for long. Strawberry has improved this a great deal. Actually, our experience has been pretty horrendous. The problem for us has not been Perl but deploying Catalyst apps under Windows. We've used IIS and FastCGI, which eventual hard-won success, and we now have a 60-page installation guide as a result. Strawberry for us had the same issues as ActiveState - a Perl distribution that worked fine, but neither was updated all that frequently, and both have no debugging support which makes memory leak tracing somewhere between very hard and impossible. In the end I built my own Perl, with MinGW, and found it only slightly harder than using Strawberry. This was because there had been a core bug in both distributions which broke DBI with a memory leak - since the indexing part of our app does tens of millions of SQL queries, we could never get it to run to completion under Windows. The time it took for the core patch to make it into the distribution was about four months. On Windows, for the most part, Perl is the easy bit. Getting it to talk to some parts of Windows is a bit harder. Getting it to run to a production standard with Microsoft technology is almost unbelievably complex. It would probably be much easier with Cygwin, Apache, etc., but then, the whole point of them is to hide Windows, so that isn't really a help. Some of our nasties included: * ActiveState's PerlEx induced memory errors in file access at a level below Perl -- these all went away under FastCGI * File locking under Windows is not always as sound as we'd like (we hit frequent deadlocks in KinoSearch, which depends on it) * CPAN installations depending on external libraries sometimes require help to find the right DLLs (e.g., SSL stuff, XML::LibXML, XML::LibXSLT) - this seems to be very non-standard across CPAN, with each module working entirely differently to find DLLs * Under MinGW, I have even had to manually edit export files to get DLLs working right * Windows permissions for FastCGI - let's not even go there! Have you any idea how many policy settings and permissions are involved in getting IIS and Perl FastCGI to work? OK, a lot of this is not actually Perl, but you need a very solid background in operating systems in general, networking, DLLs, makefiles, etc., if you want to get the whole of Catalyst up from a solid basis. I'd love to see a Strawberry-type distribution that included a solid Catalyst base and the bridge to FastCGI, preferably under both IIS and Apache, etc. Give it a proper installer, capable of handling enough about IIS/Apache configuration to get a base Catalyst application up and running, with decent performance under Windows. If we'd had this, we would have saved months of work, and this is not an exaggeration. All the best Stuart -- Stuart Watt ARM Product Developer Information Balance ___ 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 header and fastcgi
-Original Message-
From: Ian Docherty [mailto:catal...@iandocherty.com]
Sent: Tuesday, February 17, 2009 9:51 AM
To: The elegant MVC web framework
Subject: [Catalyst] Authorization header and fastcgi
Hi
The 'Authorization' header is not being passed to my Catalyst
application.
I have read the archives about fastcgi not passing the header and I
have
tried the following in my Apache 2 config
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]
FastCgiIpcDir /var/fcgi_ipc
FastCgiServer
/var/www/www.pharmaventures.com/script/pharmaventures_fastcgi.pl
-pass-header HTTP_AUTHORIZATION -pass-header Authorization -processes
5
-initial-env PV_DEBUG=0 -initial-env PV_HBX=1 -initial-env
PV_DSN=dbi:mysql:port=3306:host=127.0.0.1
I don't see a header and I don't see any environment variable in my
Cat
app.
I have tried variations on the -pass-header Authorization -pass-header
AUTHORIZATION but neither works.
Any other ideas?
The following is working for me in Apache 2.2 with FastCgiExternalServer
and Cat 5.8014
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]
Without any special declarations on my FastCgiExternalServer directive.
Could it be something specific to running the FastCGI internal vs.
external?
Did you forget to turn RewriteEngine On?
v/r
-matt pitts
___
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
From: Stuart Watt On Windows, for the most part, Perl is the easy bit. Getting it to talk to some parts of Windows is a bit harder. Getting it to run to a production standard with Microsoft technology is almost unbelievably complex. It would probably be much easier with Cygwin, Apache, etc., but then, the whole point of them is to hide Windows, so that isn't really a help. Getting Perl to talk to some parts of Windows and get information from different parts of Windows is very hard and it requires knowing very well the low level details of Windows, which is a big disadvantage of Perl. Unfortunately I don't think that this situation will change. If we talk about Perl as that low level functional language that have more than 200 internal functions, and don't care about CPAN modules, we can't say that it can always create portable programs, because not all those functions work well under Windows. If we consider Perl with all the CPAN modules, then we also can't say that it is very portable, because there are very many CPAN modules that can't be installed at all under Windows, and some other CPAN modules could be installed but they are just not made very well so they can't be compiled very easy. Perl isn't good for Symbian either and it is not as good as Java for other devices, but I think that even the lack of portability is a very big issue, it is not the biggest. I think the biggest issue is the fact that Perl with its CPAN modules are very hard to install, because even if perl is installed, many CPAN modules can be installed only if the user has root access and shell access, which in 99% of the times, it is not the case. Somebody asked me yesterday if I can create a web site for his small company, a little web shop which for the beginning should be very simple, no credit card payments required, and now I think that the costs involved for creating that site would be much bigger if I would use Perl and Catalyst than if I would use PHP. There are very many sites that offer PHP and MySQL access for a few dollars per month, and for some more they can offer more other features, but for using a host that offer shell access, I would need to have at least a virtual server where I could have root permissions in order to be able to install everything I need, including Catalyst and all other Perl modules, but this would cost much more, so that guy might want to choose something cheaper for the beginning. Of course that if his business will succeed, he might want to add new features to his site, and he might need to have even a dedicated server, but in that moment I doubt that he will decide to go for a Perl solution and abandon PHP. If Perl would offer a solution of deploying the Catalyst apps without needing to install anything with a root or shell access, using PAR or something else, Perl would have a much bigger success. Octavian ___ 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 header and fastcgi
-Original Message-
From: Matt Pitts [mailto:mpi...@a3its.com]
Sent: Thursday, February 19, 2009 11:50 AM
To: The elegant MVC web framework
Subject: RE: [Catalyst] Authorization header and fastcgi
-Original Message-
From: Ian Docherty [mailto:catal...@iandocherty.com]
Sent: Tuesday, February 17, 2009 9:51 AM
To: The elegant MVC web framework
Subject: [Catalyst] Authorization header and fastcgi
Hi
The 'Authorization' header is not being passed to my Catalyst
application.
I have read the archives about fastcgi not passing the header and I
have
tried the following in my Apache 2 config
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]
FastCgiIpcDir /var/fcgi_ipc
FastCgiServer
/var/www/www.pharmaventures.com/script/pharmaventures_fastcgi.pl
-pass-header HTTP_AUTHORIZATION -pass-header Authorization
-processes
5
-initial-env PV_DEBUG=0 -initial-env PV_HBX=1 -initial-env
PV_DSN=dbi:mysql:port=3306:host=127.0.0.1
I don't see a header and I don't see any environment variable in my
Cat
app.
I have tried variations on the -pass-header Authorization -pass-
header
AUTHORIZATION but neither works.
Any other ideas?
The following is working for me in Apache 2.2 with
FastCgiExternalServer
and Cat 5.8014
Correction, Cat 5.7014. Wishful thinking on my part. :-)
___
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 Thursday 19 February 2009 09:12:36 am Matt Pitts wrote: In today's world of software that is cross-platform and OS agnostic at its core, Perl 5 is showing its age. Still love it though. This isn't as much a Perl problem as it seems to be -- it's the rule all around that writing code that works on _everything but Windows_ is ten times easier than writing code that works on everything including Windows. Perl is just in a unique place to show this. In C, which is hardly more than a portable(-ish) layer on top of assembler, and which has a small standard library, code isn't portable at all without significant work (and even still, Windows is usually the hardest target to hit.) In Java, portability is considered paramount, so OS facilities are exposed through thick compatibility layers or else not at all. Perl sits in the middle ground. Sufficiently pure perl code will run on a million and one platforms, but at the same time Perl was never afraid to expose OS facilities (like stat or SysV IPC) more or less directly, to allow more powerful code. This has made it easy to write code that, even though it doesn't use XS as all, is platform-specific enough to crash and burn on windows. But if it's a shortcoming in Perl, how do we fix it? By taking all the goodies away from the Unix folks so everyone has to write to the least common denominator? ___ 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/
RFC local::lib + CPAN shell support in CatalystX::Starter (was: Re: [Catalyst] RFC: The paradox of choice in web development)
All this talk about Perl/Catalyst/CPAN pains, has got me thinking... Anybody like the idea of having a local::lib bootstrap option to CatalystX::Starter and possible integration of a script that would launch a CPAN shell for installing into the local::lib folder? Or, maybe a separate module Catalyst::Starter::LocalLib? The idea would be to help folks bootstrap Cat apps and get all the deps inside the app folder right from the start for easier deployment. Of course it won't eliminate the need for a shell, but it's still an improvement. I could probably put together a patch if I can get some best practice ideas. v/r -matt pitts ___ 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 Tue, Feb 17, 2009 at 11:02 PM, Devin Austin devin.aus...@gmail.comwrote: Rodrigo, If you have any, you're more than welcome to ask for SVN permissions to check in some. I know i have a few example apps I'd like to show off in /examples Sure! Where can I request svn permissions? Actually, I'd like to work also on a sassier getting-started page for the dev.catalystframework.org/wiki http://catalystframework.org site. IMO, the Catalyst Wiki could get a makeover: some css styling (so that the wiki is aligned with the homepage), column separated content, more short description of links or sections, or anything that improves usability really, for beginners and experienced users alike. The CatalystFramework homepage, on the other hand, would benefit from a more dynamic news or latest section, so it won't be so static. Of course, that means maintaining it to keep it dynamic... But nothing fancy here. Content is certainly more important than looks. But the raw idea is to make information pop out, making things faster/easier to find. What do you think? -rodrigo ___ 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
-Original Message- From: Andrew Rodland [mailto:arodl...@comcast.net] Sent: Thursday, February 19, 2009 1:12 PM To: The elegant MVC web framework Subject: Re: [Catalyst] RFC: The paradox of choice in web development On Thursday 19 February 2009 09:12:36 am Matt Pitts wrote: In today's world of software that is cross-platform and OS agnostic at its core, Perl 5 is showing its age. Still love it though. This isn't as much a Perl problem as it seems to be -- it's the rule all around that writing code that works on _everything but Windows_ is ten times easier than writing code that works on everything including Windows. Perl is just in a unique place to show this. In C, which is hardly more than a portable(-ish) layer on top of assembler, and which has a small standard library, code isn't portable at all without significant work (and even still, Windows is usually the hardest target to hit.) In Java, portability is considered paramount, so OS facilities are exposed through thick compatibility layers or else not at all. Perl sits in the middle ground. Sufficiently pure perl code will run on a million and one platforms, but at the same time Perl was never afraid to expose OS facilities (like stat or SysV IPC) more or less directly, to allow more powerful code. This has made it easy to write code that, even though it doesn't use XS as all, is platform-specific enough to crash and burn on windows. But if it's a shortcoming in Perl, how do we fix it? By taking all the goodies away from the Unix folks so everyone has to write to the least common denominator? I don't see it as a shortcoming and I can't imagine Perl without its low-level goodies. I'm just saying that by not having a common denominator Perl is a harder adoption as a platform in today's world of cross-OS lifecycles. Maybe perl6 will provide that common denominator without sacrificing the low-level goodies. v/r -matt pitts ___ 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
Maybe perl6 will provide that common denominator without sacrificing the low-level goodies. I've followed the perl6 development some, and the approach is a little different. Unlike now, there's not going to be a 'blessed' set of source code that is a particular perl version. Instead, perl versions are described by a test suite. If it passes the test suite, it's perl 6. Whether it's written in C, Haskell, Lisp, or whatever. It's a different way of looking at things, and far be it from me to predict if it will work. That's what's up with the various perl 6 projects right now, like Rakudo and Pugs. They're sharing the 'spec' test suite and jointly developing the definition of what is Perl 6, but implementing at a different rate. Rakudo continues to make progress (that's the one I'm betting on crossing the finish line), with more big things working than not, but like any massive software project, it takes a while to knock off the last 20% of a project. Here's the birds-eye view: http://www.perlfoundation.org/perl6/index.cgi?rakudo_feature_status You can probably write useful projects in Rakudo Perl 6 today, but of course it'd be crazy to use it for professional development at this point. -- Kirby ___ 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
A feeling of deja vu has grown. I used to be a Lisp developer, and remember a conference presentation by Richard Gabriel about the difference between languages emphasizing internal correctness and consistency, compared to those emphasizing something that works and integrates well. Since then, I found that Perl gave me all the bits I liked in Lisp (e.g., hashes, symbolic processing, higher-order functions and even closures) but also gave me access to the system (I gave up Lisp when I ended up having to build my own web server from socket functions up). There are some nice follow-ups to this at: http://www.dreamsongs.com/WorseIsBetter.html. Anyway, maybe this is a helpful tool in thinking through the issues for web frameworks. Certainly, PHP scores on getting 50% of functionality out there easily. Even if extending and maintaining it is a total pain. Although the message I'd take is that platforms are in an ecology rather than straight competition. i.e., why not just build outstanding Catalyst apps when it's the right tool for the job. --S -- Stuart Watt ARM Product Developer Information Balance ___ 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 19/02/2009, at 11:58 PM, Dermot wrote: 2009/2/19 Kieren Diment kie...@diment.org: On 19/02/2009, at 9:52 PM, Dermot wrote: 2009/2/19 Kieren Diment dim...@gmail.com: yapp/MyStandaloneModel.pm) that you can use the bulk of the code in the arg MyApp/lib/MyStandaloneModel.pm controller and the script. Use Catalyst::Model::Adaptor and ACCEPT context to get the logic of this standalone model out of the controller and into the catalyst model. Great thanx. I'll get straight to work on it. I might have a question or two later about the config. Check the 2008 advent calendar for ACCEPT_CONTEXT usage: http://dev.catalystframework.org/wiki/adventcalendararticles Wow! that works but I am not sure where ACCEPT_CONTEXT comes into it. That'd be if you needed to pass stuff from $c into the model to get it working properly. ___ 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 header and fastcgi
Matt Pitts wrote:
-Original Message-
From: Ian Docherty [mailto:catal...@iandocherty.com]
Sent: Tuesday, February 17, 2009 9:51 AM
To: The elegant MVC web framework
Subject: [Catalyst] Authorization header and fastcgi
Hi
The 'Authorization' header is not being passed to my Catalyst
application.
I have read the archives about fastcgi not passing the header and I
have
tried the following in my Apache 2 config
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]
FastCgiIpcDir /var/fcgi_ipc
FastCgiServer
/var/www/www.pharmaventures.com/script/pharmaventures_fastcgi.pl
-pass-header HTTP_AUTHORIZATION -pass-header Authorization -processes
5
-initial-env PV_DEBUG=0 -initial-env PV_HBX=1 -initial-env
PV_DSN=dbi:mysql:port=3306:host=127.0.0.1
I don't see a header and I don't see any environment variable in my
Cat
app.
I have tried variations on the -pass-header Authorization -pass-header
AUTHORIZATION but neither works.
Any other ideas?
The following is working for me in Apache 2.2 with FastCgiExternalServer
and Cat 5.8014
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]
Without any special declarations on my FastCgiExternalServer directive.
Could it be something specific to running the FastCGI internal vs.
external?
Did you forget to turn RewriteEngine On?
v/r
-matt pitts
__
'RewriteEngine On' was there, it makes no difference.
I too am on Cat 5.7014
I will experiment with changing between FastCGI static and dynamic mode
to see if that makes any difference.
Regards
Ian
___
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 header and fastcgi
are you looking in $c-engine-env?
Mark
Ian Docherty wrote:
Matt Pitts wrote:
-Original Message-
From: Ian Docherty [mailto:catal...@iandocherty.com]
Sent: Tuesday, February 17, 2009 9:51 AM
To: The elegant MVC web framework
Subject: [Catalyst] Authorization header and fastcgi
Hi
The 'Authorization' header is not being passed to my Catalyst
application.
I have read the archives about fastcgi not passing the header and I
have
tried the following in my Apache 2 config
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]
FastCgiIpcDir /var/fcgi_ipc
FastCgiServer
/var/www/www.pharmaventures.com/script/pharmaventures_fastcgi.pl
-pass-header HTTP_AUTHORIZATION -pass-header Authorization -processes
5
-initial-env PV_DEBUG=0 -initial-env PV_HBX=1 -initial-env
PV_DSN=dbi:mysql:port=3306:host=127.0.0.1
I don't see a header and I don't see any environment variable in my
Cat
app.
I have tried variations on the -pass-header Authorization -pass-header
AUTHORIZATION but neither works.
Any other ideas?
The following is working for me in Apache 2.2 with FastCgiExternalServer
and Cat 5.8014
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]
Without any special declarations on my FastCgiExternalServer directive.
Could it be something specific to running the FastCGI internal vs.
external?
Did you forget to turn RewriteEngine On?
v/r
-matt pitts
__
'RewriteEngine On' was there, it makes no difference.
I too am on Cat 5.7014
I will experiment with changing between FastCGI static and dynamic mode
to see if that makes any difference.
Regards
Ian
___
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 Fri, Feb 20, 2009 at 4:41 AM, Rodrigo rodrigol...@gmail.com wrote: Actually, I'd like to work also on a sassier getting-started page for the dev.catalystframework.org/wiki site. IMO, the Catalyst Wiki could get a makeover: some css styling (so that the wiki is aligned with the homepage), column separated content, more short description of links or sections, or anything that improves usability really, for beginners and experienced users alike. I agree that the Wiki could do with some work, although I don't mind the style so much. ^_^ I do think it could be a little better organised, and promoted though. Also, I think having a prominent last modified date on a Wiki page is a useful indication, and maybe even a Catalyst Version reference for howtos code snippets. (Again, a specialist knowledge base could handle that sort of data filtering better than a Wiki I think). What is the best practices for Wiki updates? Should new articles be posted to this list first, for discussion, or should they be just whacked into the Wiki, then posted here for review/deletion? Is there an alert/review process for Wiki edits? Is there a core team that will be notified of changes/additions, so they can review/delete? As someone fairly new to Catalyst, I'm happy to contribute, but I'm hesitant to jump in start making changes additions... Perhaps there should be a prominent page on the Wiki on how to best contribute to the Wiki? Here's some quick observations on things I think could be clearer on the main Catalyst site too: *The main site Community link goes straight to the Wiki. How about a Community page that summarises the Wiki, the mail list, the IRC channel, etc... *The main site Documentation goes straight to the manual - yet there's also documentation in the Wiki. Again, Docs page which deep links into key pages in the official docs and parts of the Wiki would be better IMHO. *The main site Developer jumps straight into the Catalyst repository (hmmm, there's a theme here). How about clarifying resources for Developers who work on Catalyst versus Developers who use Catalyst to develop apps? -- Trevor Phillips - http://dortamur.livejournal.com/ On nights such as this, evil deeds are done. And good deeds, of course. But mostly evil, on the whole. -- (Terry Pratchett, Wyrd Sisters) ___ 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 Thu, Feb 19, 2009 at 12:07 PM, Matt Pitts mpi...@a3its.com wrote: Anyway, this is a long story, I'll stop ranting. My point was just that there is no easy way to just run the Cat app in Windows. I understand the idea of developing a Catalyst app on Windows and running it on a *nix web server. This is what I currently do, and it's easy to just run an app on Windows with the last Strawberry Perl (5.10.0.4, released last month) and the internal myapp_server.pl. After installing Strawberry, `cpan Catalyst::Runtime` and `cpan Catalyst::Devel` completed successfully, without any intervention. This is markedly different from alpha version of Strawberry, when random things would crash in various ways. Strawberry won me and I've just ditched ActiveState perl, because indeed, you have various problems with SSL modules, ActiveState's PPM repository is way out of date, and it doesn't come with the gcc binaries to compile modules off CPAN. The latest Strawberry, I'm surprised but happy to say, does that flawlessly. 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 Fri, Feb 20, 2009 at 2:38 PM, Dan Dascalescu ddascalescu+catal...@gmail.com wrote: On Thu, Feb 19, 2009 at 12:07 PM, Matt Pitts mpi...@a3its.com wrote: Anyway, this is a long story, I'll stop ranting. My point was just that there is no easy way to just run the Cat app in Windows. I understand the idea of developing a Catalyst app on Windows and running it on a *nix web server. Umm, I've been doing it the other way round recently. Development on unix and deployment on windows (desktops in my case). Aside from some sticky cpan issues (which notest install fixes after appropriate investigation), it's been working well for me. ___ 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
Regarding wiki questions: The Catalyst wiki runs on MojoMojo (http://mojomojo.org), a project led by Marcus Ramberg. I tend to do a bit of coding too, and more advocacy and managing ideas. We've set up a feedback board for MojoMojo at http://mojomojo.ideascale.com/. To join the MojoMojo team, hang out in #mojomojo on irc.perl.org, or fork mojomojo off github, do your patch, then submit a pull request. Rodrigo, MojoMojo now supports custom styles. A different theme can be seen at http://nordaaker.no/wiki/. We think the typography needs improvement, and a Mediawiki-like theme would be very good to have. Trevor, The practice so far has been to post articles on the wiki, which then get corrected by the community, just as it happens with other wikis. Pretty much everyone agrees that newbies write the best documentation. If something wrong slips into your article, it will be corrected down the line. So feel free to dive ahead after having a look at the main structure and searching the wiki. It's usually faster to go ahead and fix things, e.g. There's also, it seems, a quite extensive Cookbook in the CPAN documentation - yet the Wiki doesn't link to it or mention it? It took less than 30 seconds to add a link to Catalyst::Manual::Cookbook on the main page. There is currently no e-mail notification about changes to the wiki, but this is on the list: http://mojomojo.ideascale.com/akira/dtd/11563-2416. In the meantime, there is a list of recent changes at http://dev.catalyst.perl.org/wiki/.recent Also, I think having a prominent last modified date on a Wiki page is a useful indication Good idea. I just pushed a fix for that. mst will hopefully update Catwiki to the latest MojoMojo. HTH, 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/
