Re: [Catalyst] How best not to use the system perl
On 09/30/2011 10:52 AM, Stuart Watt wrote: Perl 5.10 isn't really supported any more, so it is highly likely that at some stage the system Perl will get upgraded behind the scenes, breaking binary compatibility with modules even if they are in local::lib. The only safe solution is to use your own Perl (I'd not put it directly under /usr/local, but somewhere application specific, but then I am fairly paranoid). That way, no surprise upgrades will break your application. For years, we've been putting our Perl under the /opt/scalable/ tree. We've run into so many problems with system supplied Perl, that in general, we simply ignore it. We also have, in the past when we were doing more Catalyst apps, shipped our baseline tree with everything pre-installed ... it was *much* easier than going through a build, *especially* due to the inherent brokenness of the WWW::Mechanize modules, and the unfortunate dependencies upon them. We haven't done much with Cat as of late, but we are definitely still shipping our own Perl build (5.12.3 as of now, shortly to move to a 5.14.x by the beginning of the new year). -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics Inc. email: land...@scalableinformatics.com web : http://scalableinformatics.com http://scalableinformatics.com/sicluster phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615 ___ 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] Quick question on forward porting versus retaining existing code
Hi folks We have a Catalyst app we've developed since about 2005 or so. We put it aside in late 2008, and haven't touched it until now. I wanted to see if it would still work (as it turns out, we can reuse this for a new project). Before we get into this in depth, are there any pointers/blog posts/articles about forward porting an application (this was pre-Moose), or whether or not the app would work without forward porting? Basically we don't want to have to redevelop everything we put into that (login/authentication, views, etc.), and simply add to the existing app with a limited set of changes to make it current would be ideal. Thanks! Joe -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics Inc. email: land...@scalableinformatics.com web : http://scalableinformatics.com http://scalableinformatics.com/sicluster phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615 ___ 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] Quick question on forward porting versus retaining existing code
On 03/17/2011 04:27 PM, Andrew Rodland wrote: On Thursday, March 17, 2011 02:51:59 PM Joe Landman wrote: Hi folks We have a Catalyst app we've developed since about 2005 or so. We put it aside in late 2008, and haven't touched it until now. I wanted to see if it would still work (as it turns out, we can reuse this for a new project). Before we get into this in depth, are there any pointers/blog posts/articles about forward porting an application (this was pre-Moose), or whether or not the app would work without forward porting? Basically we don't want to have to redevelop everything we put into that (login/authentication, views, etc.), and simply add to the existing app with a limited set of changes to make it current would be ideal. Thanks! Joe It's the intention of the Catalyst dev team that new releases don't break existing apps. The 5.7 to 5.8 transition broke that promise *slightly* more than most releases (mostly due to the C3 MRO), but a great many apps written for 5.7 will still run without any changes on 5.8, and of the remainder, 99% will only need very small changes. Rewriting your code to make explicit use of Moose is *not* required. Just deploy the app with the current version of Catalyst and current versions of any plugins it uses, and if there are any errors or warnings on startup, use them as guidance. If you run into a nut you can't crack, please feel free to come back for advice, but you should start out by just trying to run the app. For laughs, I just tried it, and modulo some module updates, it appears to work. Thanks folks, this is great! Should speed our development quite a bit! Andrew -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics Inc. email: land...@scalableinformatics.com web : http://scalableinformatics.com http://scalableinformatics.com/sicluster phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615 ___ 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] Question on Perl versions with Catalyst
Hi folks We are redoing one of our applications, and I wanted a quick sync against which Perl versions are currently blessed. I remember that 5.10.0 did not work due to a bug in the Perl base. Are there any issues we need to be aware of for 5.12.0 or should we stick with 5.10.x (x greater than or equal to 1)? Thanks in advance! Joe -- Joe Landman land...@scalableinformatics.com http://scalableinformatics.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/
[Catalyst] What is the currently blessed XMLRPC
Hi folks: Working on a new version of some of our applications. One of the things we are doing is providing an XMLRPC interface for some of our functionality. I am setting up a new load of Catalyst::Devel and some of the additional bits, and saw this nice shiny new Catalyst::Plugin::Server::XMLRPC . It didn't seem to install well though, giving me errors like this: t/003_Settings.t ... Catalyst::Plugin::Server uses NEXT, which is deprecated . Please see the Class::C3::Adopt::NEXT documentation for details. NEXT used at ../lib/Catalyst/Plugin/Server.pm line 17 Catalyst::Plugin::Server::XMLRPC uses NEXT, which is deprecated. Please see the Class::C3::Adopt::NEXT documentation for details. NEXT used at ../lib/Catalyst/ Plugin/Server/XMLRPC.pm line 279 t/003_Settings.t ... 1/? # Failed test ' 'xmlrpc_params' returned correctly' # at t/003_Settings.t line 62. # Structures begin differing at: # $got = undef # $expected = HASH(0x35bbfc) This is Strawberry Perl under Windows 7. Will try Cygwin and Linux next. But barring platform issues, is this the current version of XMLRPC server for Catalyst? Moreover, is there a list of currently blessed bits for specific functions somewhere? Thanks! Joe ps: I'll report the error to the developers directly, this is more a question of am I using the right module. -- Joe Landman land...@scalableinformatics.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/
[Catalyst] Speaking of Perls ... which is the preferred version for current Catalyst development?
Hi Folks: We've been using Catalyst for a while now, for a variety of products/projects we build/market/support. Until recently, our platform has been Perl 5.8.8 based. For a number of reasons, we needed to go to a 5.10 based platform for our other (not-Cat) tools. Catalyst had a fairly significant problem (debugging bits on standalone server not showing up) as I remember in the 5.10.0 cycle. Has this been fixed in 5.10.1? Thanks! Joe -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics, Inc. email: land...@scalableinformatics.com web : http://scalableinformatics.com http://scalableinformatics.com/jackrabbit phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615 ___ 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] Mason + DBI + Catalyst?
Daniel Carrera wrote: Andrew Rodland wrote: The info you need on how things get glued together is in perldoc Catalyst::View::Mason and perldoc Catalyst::Model::DBI. I didn't know about Catalyst::View::Mason, thanks. Btw, this is related to the point of my post, it is hard to RTFM if you don't know where the FM is. Or rather, the FM I knew of was about TT rather than Mason. We use Mason rather than TT for our Catalyst apps (most of our web-apps which aren't CGI based). We use Mason mostly for templating, using subcomponents to handle common features. This works very well. The beauty of Catalyst is that it doesn't impose a particular view (pun intended) upon you. Nor for that matter, does it impose a particular model. More in a moment. And incidentally, you're wrong about DBIC. As soon as you get into queries for related tables, DBIC will be reducing the amount of code you need to write (and the number of potential screwups) tenfold. I hesitate to make predictions like this. I don't know DBIC, and you don't know my queries. I know that I find SQL no harder than Perl, and that I appreciate being able to experiment with queries with phpMyAdmin. I am not a huge fan of DBIC myself. But I don't like SQL all that much. I do prefer something else to generate correct SQL. Happily, most of my SQL tends to be quite simple. But I still like something in there to handle this for me. This is where Catalyst really shines. I don't *need* to use the M portion of the MVC. I can use my own code (which I often do) rather than using the integrated Model capabilities, which are overkill for our apps. When I need to use the M portion, I find Catalyst::Model::Jifty::DBI matches my thought processes better than DBIC. This isn't a criticism of DBIC. Just a personal prefernce. Most of the examples assume DBIC though, so you have to (often) transliterate if you are using something else. So I can't help but wonder if it really makes sense to use a Perl module to write the SQL for me rather than write the SQL directly. How would you tell DBIC to use a sub query or to use a temporary table? Is it hard? DBIC is very powerful. I believe it has the capabilities you wish for. The only thing I do wish for is a simpler login capability. We have authentication and authorization controllers. We have many different things to admix together. What I would like at some point, is a simple controller that points to a DB or other data source, a login page template that must provide several fields, and can optionally supply others. As far as I am aware, this doesn't exist today, and I find with the rapid rate of change of the core, a login controller I wrote 2 years ago, doesn't always work with the newer code. Which is a problem. Things like that would be quite helpful, for those of us who don't want to spend our time writing login/logout controllers, but want to focus upon writing our apps. I could be wrong, but I don't think it does exist. Joe -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics LLC, email: land...@scalableinformatics.com web : http://www.scalableinformatics.com http://jackrabbit.scalableinformatics.com phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615 ___ 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] Not sure how to go about this ... or if this idea is even a good one ...
Ok, starting to want to play with Chained actions for an app, and I am
not sure they are the right fit. Possibly a round peg in this
particular square hole.
Here is what I want to do. I want to capture 0, 1, or 2 arguments on
the URL.
If 0 args, then forward over to one method.
If 1 arg, then forward over to a specific method
If 2 args, then forward over to a different specific method.
I don't want to go beyond 2 args for this, but you should get the idea.
This is sort of a drill-in type application.
Ok. Does chained make sense for this versus
sub do_stuff : Path('/') {
my ($self, $c, @my_args) = @_;
if ($#my_args == -1)
{
$c-forward('zero_args');
}
elsif ($#my_args == 0)
{
$c-forward('one_arg',@my_args);
}
elsif ($#my_args == 1)
{
$c-forward('two_arg',@my_args);
}
}
The issue in this case is that I won't know the value of the first or
second arg in advance (they are coming from a database). So I am not
sure if I can do something like
# root action - captures one argument after it
sub zero : Path('/') {
my ( $self, $c ) = @_;
...
}
sub one_arg : Chained('/') PathPart('') CaptureArgs(1) {
my ( $self, $c, $foo_arg ) = @_;
...
}
sub two_arg : Chained('/') PathPart('') CaptureArgs(2) {
my ( $self, $c, $foo_arg, $bar_arg) = @_;
...
}
that is, the particular sub to execute is a function not of the path,
but of the number of arguments.
Is this a job for chained?
--
Joe Landman
[EMAIL PROTECTED]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Not sure how to go about this ... or if this idea is even a good one ...
Hate replying to myself, but neither method seems to work.
Will need to look at this more ... it seems really simple, which means I
am missing the obvious.
Joe Landman wrote:
Ok, starting to want to play with Chained actions for an app, and I am
not sure they are the right fit. Possibly a round peg in this
particular square hole.
Here is what I want to do. I want to capture 0, 1, or 2 arguments on
the URL.
If 0 args, then forward over to one method.
If 1 arg, then forward over to a specific method
If 2 args, then forward over to a different specific method.
I don't want to go beyond 2 args for this, but you should get the idea.
This is sort of a drill-in type application.
Ok. Does chained make sense for this versus
sub do_stuff : Path('/') {
my ($self, $c, @my_args) = @_;
if ($#my_args == -1)
{
$c-forward('zero_args');
}
elsif ($#my_args == 0)
{
$c-forward('one_arg',@my_args);
}
elsif ($#my_args == 1)
{
$c-forward('two_arg',@my_args);
}
}
The issue in this case is that I won't know the value of the first or
second arg in advance (they are coming from a database). So I am not
sure if I can do something like
# root action - captures one argument after it
sub zero : Path('/') {
my ( $self, $c ) = @_;
...
}
sub one_arg : Chained('/') PathPart('') CaptureArgs(1) {
my ( $self, $c, $foo_arg ) = @_;
...
}
sub two_arg : Chained('/') PathPart('') CaptureArgs(2) {
my ( $self, $c, $foo_arg, $bar_arg) = @_;
...
}
that is, the particular sub to execute is a function not of the path,
but of the number of arguments.
Is this a job for chained?
--
Joe Landman
[EMAIL PROTECTED]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Found a simple way to restrain the verbosity of C::C::FormBuilder under debug
Ok, this has been bugging me for a while. When you turn on app
debugging, C::C::FormBuilder goes nuclear on your logs. You have a
small percentage of your log being your application, and most of your
log being the C::C::FormBuilder being its internal machinations ...
which, I really, really don't need to see.
So, how do you turn off (or control) the C::C::FormBuilder logs? Kinda
simple really.
When you create your form:
use base 'Catalyst::Controller::FormBuilder';
sub clone : Local Form {
my ($self, $c) = @_;
my $form = $self-formbuilder-new(debug=0);
and ... no more megatons of C::C::FormBuilder internal discussions in
your logs.
Now it is calm, controlled, showing the entry into C::C::FormBuilder and
the exit of C::C::FormBuilder ...
Thought everyone would like to know.
--
Joe Landman
[EMAIL PROTECTED]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] What can C::P::Cache cache?
Joe Landman wrote:
Sounds like a strange question, but I want to know if I can put a
complex data structure like a hash in there. Do I need to serialize it
first?
Alternatively, if it only handles scalars, that is also useful to know.
Thanks.
Well ... never mind. I figured it out for my self. Short version, the
following appears to work nicely:
my $serialized_menu = $c-cache-get('menu');
if ($serialized_menu)
{
@menu= @{$serialized_menu};
$c-log-debug('Root::_get_navbar menu retrieved from cache');
}
else
{
$c-log-debug('Root::_get_navbar rebuilding menu');
# rebuild menu
$c-cache-set('menu',[EMAIL PROTECTED]);
}
For some reason the manual's
unless ( ... ) {
} ...
construct did not work for this case.
--
Joe Landman
[EMAIL PROTECTED]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] I am misunderstanding something about Private actions
Hi folks:
Thought I had this nailed, but it looks like I really didn't
understand it as I should have.
Here is the problem. I want to forward to some private actions to
simplify the application (and avoid repeating myself). I want to be
able to do this from any controller in the code. So in reading the
manual, I thought I was supposed to do
$c-forward('MyApp::Root::do_something');
and not
$c-forward('/do_something');
The latter works, the former does not. Is this intended? Are both
supposed to work?
On a related note, I like naming my internal methods with an underscore
up front. Yeah, maybe not the best practice these days, but call it an
old habit. What I noticed was that private methods named _do_something
didn't seem to show up in the private list. Confused me a bit. Should
I avoid that practice with Catalyst? Just name them
INTERNAL_METHOD_do_something or something like that? Well, you get the
idea ...
Joe
--
Joe Landman
[EMAIL PROTECTED]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] upload breakage
Hi folks:
I am trying to set up a simple multiple upload form. Using jQuery
multi class for the interface portion. The form looks like this:
form action=/upload class=multi enctype=multipart/form-data
input type=file class=multi /
input type=submit name=upload value=upload file(s) /
input type=hidden name=destination_path value=%
$destination_path % /
input type=hidden name=form_submit value=yes /
/form
and the receiving action is basically a cut and paste from the cookbook
my $path = $c-req-param('destination_path');
$c-log-debug('* path = '.$path);
if ( $c-request-parameters-{form_submit} eq 'yes' ) {
$c-log-debug('* uploading! ');
for my $field ( $c-request-upload ) {
$c-log-debug('*** field '.$field);
my $upload = $c-request-upload($field);
my $filename = $upload-filename;
my $target = File::Spec-catfile($path,$filename);
$c-log-debug('*** name '.$filename);
$c-log-debug('*** target'.$target);
unless ( $upload-link_to($target) ||
$upload-copy_to($target) ) {
die( Failed to copy '$filename' to '$target': $! );
}
}
}
Now when I try to upload a file, in this case a simple perl script named
wireless.pl ... fairly small as a simple test case, the controller reports
[debug] Query Parameters are:
.-+--.
| Parameter | Value
|
+-+--+
| destination_path| /tmp
|
| file| wireless.pl
|
| file1 |
|
| form_submit | yes
|
| upload | upload file(s)
|
'-+--'
[debug] GET request for upload from 127.0.0.1
[debug] Path is upload
[debug] * path = /tmp
[debug] * uploading!
[debug] * dump = $VAR1 = 'upload file(s)';
but it never seems to hit the innards of the loop. So it doesn't
actually go through extracting the file name and so on.
Any clues? Is it obvious what I am doing wrong here?
And if there is a better way to do multi file upload using Catalyst and
jQuery, please, by all means, I am all ears ...
Thanks!
--
Joe Landman
[EMAIL PROTECTED]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Selective debug output
How do I selectively enable or disable debugging output? Specifically, FormBuilder debugging output is simply far to verbose to be meaningful to us. I suppose I could simply pass in a debug=0 when I create the form. Is there any global way? FWIW: I only want to surpress formbuilder output during debug. -- Joe Landman [EMAIL PROTECTED] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] A question on persistence with sessions or similar
Hi Folks: Here is what I want to do. I want to preserve values of stuff across the life of a session, without having to jump through hoops to do it. I want it to survive redirects in the app. It would be nice if it were just like stash. Really, it is very simple. And I thought I had it. $c-flash as part of C::P::Sessions, C::P::Sessions::Store::FastMmap and C::P::Sessions::State::Cookie says it preserves state across redirects. You have to touch the values at each instance (and since this is in the middle of a bunch of forms that might be suspect). Unfortunately, I am noticing lots of dropouts of state. Values go missing and all that. The session ids are preserved. The state is not. Rather than jamming this all into a cookie, I would like a server side version that just works. I am awful close to using a quick-n-dirty DB for this explicitly, using the session_id as a key. I am assuming it is massive pilot error on my part, but I am having trouble finding it. I get the same behavior with C::P::Sessions::Store::File as I do with FastMmap. Any thoughts? Is the state working perfectly for others? If so, are you using FastMmap? Are you using Cache? Finally as an RFE for 5.8, it would be really, really nice if there was a $c-sessionstash that worked just like stash. Stash is great, things that work like stash are great. -- Joe Landman [EMAIL PROTECTED] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] A question on persistence with sessions or similar
Jonathan Rockway wrote: Just out of curiosity, what documentation lead you in this direction? flash doesn't get much mention officially, I don't think. http://search.cpan.org/~nuffin/Catalyst-Plugin-Session-0.19/lib/Catalyst/Plugin/Session.pm For some reason, session didn't work the first time I played with it. It is behaving nicely now. So I read the rest of the documentation, and there, right under sessions is a little discussion on flash ... ... to my fevered brain, it seemed like approximately what I wanted to do. -- Joe Landman [EMAIL PROTECTED] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
