Re: [Catalyst] source out accessors to LDAP-Model
On Mon, Dec 13, 2010 at 9:24 AM, piccard wrote: > I'm very new to Catalyst, so at the moment I am playing around with some > things. I think I've got a very basic question: > I'm not sure how to pull out more complicated queries from the controller by > providing subroutines/accessors. See the documentation related to the "connection_class" and "entry_class" configuration items. You can specify subclasses of Catalyst::Model::LDAP::Connection and Catalyst::Model::LDAP::Entry and use them exactly as you'd expect. k. -- kevin montuori ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst 5.8: the Perl MVC Framework - Packt Publishing
On Sun, Aug 1, 2010 at 1:08 PM, Roderick A. Anderson wrote: > I'm always in the market for dead tree or captured electron media but I > don't remember seeing any posts on the list by the author -- Antano Solar > John. > > Has anyone reviewed this book? Familiar with the author? The 1st edition wasn't at all bad, aside from the absolutely awful editing job and useless index. A quick read through the 2nd edition seems to be much mostly the same with a new chapter on Moose. I "upgraded" the book hoping the Moose bits would be informative. They might be, but only if you're very new to Moose. there are no deep insights to be found. The editing and layout (at least of the etext) is worse -- I honestly didn't think that was possible; the index appears unchanged. If you're looking for a good -- but becoming outdated -- book, the Apress book is a better choice. Honestly, this'll be the last time I buy anything from Packt. They have very promising titles (and the 1st ed of the Catalyst book was informative and clueful, I mean no disrespect to the author) but the publishing part of the equation is shabby, at least in a world where Apress, ORA, AW, &c. books are so well done. Something as seemingly simple as consistent capitalization appears beyond Packt's reach. All things told, I wouldn't recommend it. k. -- kevin montuori ___ 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] problem with basic test of auto-generated TTSite code
On Tue, Jul 27, 2010 at 10:07 AM, Leandro Hermida wrote: > Is it because at compile time MyApp doesn't have the path_to() method? > How should I write the test? Perhaps a 'use MyApp' statement? k. -- kevin montuori ___ 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] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 3:48 PM, Wade Stuart wrote: > Sorry, it is akin to someone driving up to you while you are in a gas > station in a unleaded ford asking very nicely "Do you know where the diesel > pumps are"? The question is literate and well formed but in context implies > lack of understanding. Not if there's a spare can in the trunk for the backhoe. Everybody's situation is different, and there's often a good reason for seemingly "incorrect" questions. k. -- kevin montuori ___ 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] Alternatives to DBIx?
On Sat, Apr 17, 2010 at 7:04 PM, John Karr wrote: > In my own analysis the Time and Effort to learn DBIx is greater than the Time > wasted writing repetitious DBI code, the time I've already invested on DBIx > has shown that there is a better way than DBI, but for me it isn't DBIx. I'm in no way arguing with your conclusion, such as it is; however, there's more to evaluate than just time spent learning a new library. In my experience (two or so years with DBIC/Catalyst and many, many more with sundry DBI hacks) DBIC code has proven trivial to maintain and augment. Furthermore, it's relatively easy to find programmers who are familiar with it and can be brought up to speed quickly. Your situation might be different; for me the maintenance is as important as the development. On a different note: I rarely have a need for raw SQL: what DBIC is generating is perfectly appropriate (and DBIC::Deploy does a bang-up job of creating DDL). When it is necessary, DBIC::ResultSource::View + native DB SQL code (stored procs, views, &c.) does a fine job of keeping SQL out of the Perl app. (I know that opinions on this differ -- ha! -- but it's worked out well for me, particularly when I hand an SP off to a DBA for optimization; as a rule I get less grief when it's just SQL and not SQL embedded in some other language.) k. -- kevin montuori ___ 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] Slow Makefile.PL
On Mon, Mar 22, 2010 at 3:20 PM, Ovid wrote: > Does this look familiar to anyone? I don't use the Makefile.PL all that often so I hadn't noticed, but my 10.6.2 box reports similar results: Total Elapsed Time = 50.86615 Seconds User+System Time = 48.08246 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 93.5 44.96 44.967441 0.1020 0.1020 File::Copy::copy 2.55 1.228 1.229 13 0.0944 0.0945 Module::Install::Admin::copy 1.76 0.846 45.744 1042 0.0008 0.0439 File::Copy::Recursive::__ANON__ [...] If I move this out of my home directory and into /tmp it's as fast as you'd expect. My guess is that FileVault is slowing things down. k. -- kevin montuori ___ 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: Forcing model to reconnect with different connect_info
>>>>> "AP" == Alex Povolotsky writes:
AP> It's a bit of crazed setup, but I do have it; I have about 100
AP> identicaly-structured based with different conent.
AP> I think it's more reasonable to have one model and set dbname for each
AP> connect. However, I haven't found any way to force model to reconnect
AP> with different connect_info. Maybe someone knows the right handle?
Well, this is (as the comment says) a hack that I whomped up for an
interal-only tool, but it works. If I know I'm going to change DBs, I
just forward off to it.
sub unset_model :Private {
# omg, this is a wicked hack.
my ($self, $c) = @_;
for my $key ( keys %{ $c->stash } ) {
if (ref $c->stash->{$key} eq 'MyApp::Model::DB') {
delete $c->stash->{$key};
return;
}
}
}
I'd love to hear of a better way.
k.
--
kevin montuori
___
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: Deployment in practice
>>>>> "MA" == Mesdaq, Ali writes: MA> Once it passes the tests the code can be merged into the MA> production branch and will auto deploy. That's a great solution until someone checks a change into the production branch accidentally. As someone already mentioned, it'll happen eventually. I'm a firm believer in not using version control as a deployment tool. It's more work to create a package, deploy that to test, test, deploy *the same package* to production, but you at least know that what you tested is what's in production. Pulling straight from VC you never really have that assurance. k. -- kevin montuori ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Catalyst::Helper Changes
>>>>> "DA" == Devin Austin writes:
DA> I will quit being a tool and get my shit released.
Heh. But that's *my* motto.
DA> Please, send me any ideas you have your way with regards to "I want
DA> to be able to do this".
There's a litany of tweaks I usually make after creating a new catalyst
project. Assuming the project MyApp, these usually include:
mkdir MyApp/{.control,bin,etc}
mkdir MyApp/etc/{conf,DDL,SQL,LDIF}
mkdir MyApp/lib/MyApp/Schema/MyApp/{Result,ResultSet}
mkdir MyApp/lib/HTML/FormFu/Validator/MyApp
mkdir MyApp/root/forms
I generally add content to the MyApp.pm file: ConfigLoader
substitutions, a new ConfigLoader base, some plugins that are almost
always used.
Usually there's a Schema/MyApp.pm file that's standard boilerplate.
There are a couple of files I add to the bin directory so they're kept
with the project.
Also I create a number of .../.template files and populate them with
project-specific templates (for the benefit of emacs).
There's probably more ... that's why I'm looking to automate it.
k.
--
kevin montuori
montu...@gmail.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] Catalyst::Helper Changes
On Tue, Sep 8, 2009 at 3:14 PM, Devin Austin wrote: > >> Can you explain a little more in depth what you're looking to do? > Sure. Among other things I'd like the myapp.conf file to live in $root/etc/config and be YAML format. This involves creating the directories, changing the conf file contents and name, and adding a line to MyApp.pm. There's more, but I think this is a fairly representative example of the kind of thing. k. -- kevin montuori ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Catalyst::Helper Changes
Hi all -- I'd like to modify what Catalyst::Helper creates when initializing a new product. I'm wondering if there's a "best practice" for this or if I'm on my own. Thanks for any pointers. k. -- kevin montuori ___ 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: Sample press release and announcement homepage
>>>>> "ZL" == Zbigniew Lukasiak writes: >> ... the revolutionary Moose Object system, the most advanced >> Object Oriented framework for any major scripting language ZL> I would change that to 'one of the most advanced' - less flame ZL> igniting (and by the way Perl 6 probably does have a more ZL> advanced Object system). Why not something like "... the most productive ..." -- Moose is great but not exactly advancing the state of the art; indeed, it's implementing a technique/protocol that's been around a long time now. Also, why does Perl have to be a "scripting language"? I don't write scripts (particularly with Moose), I write programs. If you're uncomfortable with "any major language" (or, better, "any popular language") how about substituting "interpreted" for "scripting"? Just a thought. It's nice to see someone publicizing Catalyst! k. -- kevin montuori montu...@gmail.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] Re: How to detect if the current form request is a post?
>>>>> "DD" == David Dorward writes: DD> Limiting the side effects of laziness and bad practices with other bad DD> practices ... well, that's an interesting argument, I'll give you that. that's funny. all other things being equal, since catalyst controllers can be method agnostic there's no reason to limit the application's functionality by only allowing POST or whatever. even in circumstances where the HTML should direct the browser to POST, accepting GET is often very handy. using openssl s_client to debug code behind SSL encrypted connections, for instance. (that's not to imply that it's not possible with POST, but it's less trivial. particularly at 3 am.) i think the maxim is: be strict in what you send and generous in what you receive. applications adhering to this philosophy tend to last. k. -- kevin montuori montu...@gmail.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] Re: New Catalyst Book?
>>>>> "KD" == Kieren Diment writes: KD> Oh shit, that means we've actually got to finish it :o heh. not necessarily: apress had promised an ansi common lisp reference manual for years and then one day -- poof -- any mention of it was gone from their site. i can't wait to read the catalyst book. one of the great selling points of the framework (to management types) is the idea that any programmer off the street could come in and hit the ground running in a catalyst shop ... having a second book helps further that notion significantly. k. -- kevin montuori montu...@gmail.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] Re: Only call individual fields by number?
>>>>> "AK" == Ascii King writes:
AK> You can only call individual fields by referring to the array index,
AK> like this:
AK> [% FormBuilder.field.0.tag %]
not at all (and relying on a mutable index would be a terrible idea).
this (cut and pasted) markup works fine:
[% first_name = formbuilder.field.first_name;
last_name = formbuilder.field.last_name -%]
...
[% first_name.field %]
[% last_name.field %]
[% first_name.label %]
[% last_name.label %]
k.
--
kevin montuori
montu...@gmail.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] Re: Beginner Question: Controller Layout
>>>>> "bh" == bill hauck <[EMAIL PROTECTED]> writes:
bh> For this site how would you control which user/band edits which
bh> scheduled events, uploads pictures, etc.? Do you have each
bh> function check the database? Do you write one function for each
bh> type of "item" and simply call it?
for granular authorizations like this i'd have my controller mix-in a
base class which would provide functions like:
$self->can_edit_widget($widget_id)
then the can_edit_widget can do whatever sorts of authz necessary.
usually this means that it'll return true if the $c->user is in some
sort of administrator role or has a relationship to the widget in
question that allows for the action.
this method might be something like:
sub can_edit_widget {
my ($self, $widget_id) = @_;
my $c = $self->context;
return 1 if $c->check_any_user_role($c->user, 'administrator');
return 1 if $c->model('MyApp::Widgets')->is_owner($c->user, $widget_id);
return;
}
i'm not sure that this could be considered "best practice" or even
recommended, but it does allow for a mix of role based and app
specific authz. by doing the work in a mix-in class the authz logic
is easily changed (or audited) independently of what the controller is
doing. it's also nice for controllers to ask relevant questions like
"can_edit_widget" rather than "is_owner" ... if nothing else the guy
who maintains your code next will understand why you wanted to know.
k.
--
kevin montuori
[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] Re: One App, multiple databases
>>>>> "JLM" == Jose Luis Martinez <[EMAIL PROTECTED]> writes: JLM> We have an app that will connect to one database or another JLM> depending on the logged in user. i'm wondering why you wouldn't have two models with different connection information but that use the same schema? i might be mistaken, but it seems that tying a user to a physical database circumvents some of the abstraction MVC provides. k. -- kevin montuori [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] Re: Catalyst::Plugin::XMLRPC/Catalyst::Component::ACCEPT_CONTEXT issue.
>>>>> "MST" == Matt S Trout <[EMAIL PROTECTED]> writes: MST> You wanted Catalyst::Plugin::Server::XMLRPC which obsoletes the MST> old XMLRPC plugin. apparently. maybe a deprecation notice in the old XMLRPC plugin documentation would be appropriate? anyway, thanks for the pointer. k. -- kevin montuori [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] Re: recommendation
>>>>> "OR" == Octavian Rasnita <[EMAIL PROTECTED]> writes: OR> Especially for a beginner, but not only, the most simple way of OR> creating the DBIC classes for a Catalyst app is to use the OR> DBIC::Schema helper. although it's not what you asked, i'll comment that i've had great luck doing this the other way round: i write the classes (with a lot of help from an emacs template*) and generate a DDL script from those. in addition to making table creation trivial, sqlt-diff produces scripts which (usually) do a fine job of upgrading from one version to another. see create_ddl_dir() here: http://tinyurl.com/5vgwcj and sqlt-diff here: http://tinyurl.com/6ql6wo for details. i'm much better at writing perl classes than DDL though, so it was obvious that this was the right thing for me in a 50 table, 10 view database. no doubt your mileage will vary. k. -- kevin montuori [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] Catalyst::Plugin::XMLRPC/Catalyst::Component::ACCEPT_CONTEXT issue.
hi all -- i have a trivial catalyst (version 5.7015) application using
the XMLRPC plugin (version 1.0) with two controllers
lib/MyApp/Controller/API.pm
lib/MyApp/Controller/API/SubGroup.pm
and one mixin class
lib/MyApp/ControllerBase/Quux.pm
which uses the base class Catalyst::Component::ACCEPT_CONTEXT (version
0.05) and has one method:
sub fancy {
my $self = shift;
my $c = $self->context;
print STDERR "context is: $c, ", (ref $c ? ref $c : "(not blessed)"), "\n";
}
when i call this method from MyApp::Controller::API::test i see that $c
is a blessed MyApp object; when i call the same method from
MyApp::Controller::API::SubGroup::test the value of $c is the string
"MyApp" and is not blessed. i'd have thought that the behavior would be
the same in both cases.
my question is: is my expectation incorrect and this is the correct
behavior or is there a bug somewhere?
i've included the three modules and MyApp.pm below, everything else in
the project is untouched. thanks for any help!
cheers.
k.
--
kevin montuori
[EMAIL PROTECTED]
##
#
# lib/MyApp.pm
#
package MyApp;
use strict;
use warnings;
use Catalyst::Runtime '5.70';
use Catalyst qw/-Debug ConfigLoader Static::Simple XMLRPC/;
our $VERSION = '0.01';
__PACKAGE__->config( name => 'MyApp' );
__PACKAGE__->setup;
1;
##
#
# lib/MyApp/ControllerBase/Quux.pm
#
package MyApp::ControllerBase::Quux;
use strict;
use base qw[ Catalyst::Component::ACCEPT_CONTEXT ];
sub fancy {
my $self = shift;
my $c = $self->context;
print STDERR "context is: $c, ", (ref $c ? ref $c : "(not blessed)"), "\n";
}
1;
##
#
# lib/MyApp/Controller/API.pm
#
package MyApp::Controller::API;
use strict;
use base qw[ Catalyst::Controller
MyApp::ControllerBase::Quux ];
sub default : Private {
my ($self, $c) = @_;
$c->xmlrpc;
}
sub test : XMLRPC {
my ($self, $c) = @_;
$self->fancy;
return "Test Succeeded.";
}
1;
##
#
# lib/MyApp/Controller/API/SubGroup.pm
#
package MyApp::Controller::API::SubGroup;
use strict;
use base qw[ MyApp::Controller::API ];
sub test : XMLRPC {
my ($self, $c) = @_;
$self->fancy;
return "Test Succeeded";
}
1;
___
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: Two Forms via FormBuilder on one page
>>>>> "aj" == abhishek jain <[EMAIL PROTECTED]> writes: aj> Someone pl. reply, when you searched for catalyst::controller::formbuilder on cpan to see what else might come up, did you miss c::c::formbuilder::multiform? k. -- kevin montuori [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] Re: bypassing password authentication
>>>>> "JS" == Jim Spath <[EMAIL PROTECTED]> writes:
JS> I'm currently using password authentication in a Catalyst app,
JS> but would like to implement a way to log in as a particular user,
JS> without knowing the password. (Please don't respond with "don't
JS> do this"... I'm aware of the security ramifications of this kind
JS> of functionality).
JS> I'll already have all the information on the user, except for
JS> their password, since we hash the password before storing it.
JS> The end goal would be to have an authenticated session.
i had an authentication credential plugin that looks like this to
handle authentication without actually authenticating. this is
essentially untested, but if memory serves, it worked back when i
though i was going to have to use an SSO solution.
package Catalyst::Plugin::Authentication::Credential::SSO;
use strict;
sub new {
my ($class, $config, $app) = @_;
my $self = { _config => $config };
return bless $self, $class;
}
sub authenticate {
my ($self, $c, $authstore, $authinfo) = @_;
my $user_obj = $authstore->find_user($authinfo, $c);
if (ref $user_obj) {
return $user_obj;
}
else {
$c->log->error("Unable to locate user in user store.");
return;
}
}
1;
--
kevin montuori
[EMAIL PROTECTED]
AIM: ignavusinfo
___
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: Development environments and performance
ation." -- experienced developers new to the environment waste almost no time trying to futz around getting all the working parts configured correctly. we run a setup script and volia, their databases, ldap instances, apache sandbox, SSO configuration, firewall configuration, &c. are complete and correct. when upgrades are done to any of the software, these are mostly transparent to the developers. and backups (and recovery!), security, access from off-site, redundant power, &c. are all included free of charge. -- junior developers end up in the middle of a working environment rather than frustrated trying to piece together their own bit by bit. i realize that our shop is a little abnormal in that we're higher ed and end up with our share of just-graduated and work-study types, so this point is actually very important to me. note that just because an environment is provided doesn't preclude cranking out some code elsewhere. but it does provide a proving ground *before* commits are made to VC. this almost 100% eliminates the "it works on my desktop" complaint. please don't misunderstand me, it's extremely possible to have lousy centralized services (jonathan's was a great description of that too commonplace scenario). it's also possible to provide developers with services, tools, and resources they need to get the job done while removing the headaches of doing it all yourself. if the choice were between the former and "do it yourself", i'd be in favor of the former too; my argument is that the latter can (and does, sometimes) work. obCatalyst (finally): part of the reason i like catalyst so much is the ease with which it's possible to crank up individual development servers (even, for instance, two versions of the same code) and i'd repeat that i've found them to be very lightweight and work well in a shared resource setting, your mileage probably varied. cheers. k. -- kevin montuori ___ 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: Development environments and performance
>>>>> "DR" == Dave Rolsky <[EMAIL PROTECTED]> writes: DR> * dev is one box per dev, with the best hardware affordable - nowadays DR> * that means at least a dual core machine with 4GB of ram and decent DR> * disks. "at least" 4 GB of ram? crikey. DR> Shared dev machines made sense about 10 years ago, but any place DR> still using them is hopelessly backwards (err, like my current DR> employer ;) i'd have to disagree. if you have a bunch of junior developers writing code, a shared (to some extent) development environment can aid in enforcing good development habits. it also allows them to work more on development than systems or database administration. never mind that it's asking a lot to make programmers (of any skill level) DBA their own oracle instances, LDAP servers, or, god forbid, siteminder installations. my suspicion is that in shops with poor shared development environments, the systems administration is more to blame for the suitability issues than the fact that the environment is shared. having sysadms who are sympathetic to the development process is certainly a requirement, as is having pretty fast request turnaround time. catalyst allows for a particularly nice sandbox though, using the devlopment httpd. we're having a lot of luck providing a (robust, but not 4GB per devloper!) shared dev/sandbox environment with each of 8 or so developers running a dev httpd. we then releasing code to integration for regression testing. i'm certainly not seeing the performance problems that have been reported on this list. cheers. k. -- kevin montuori ___ 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: two Catalyst flaws
>>>>> "FL" == Fayland Lam <[EMAIL PROTECTED]> writes: FL> the second one is hard to use model in cron pl. check out jonathan rockway's book [1], specifically, the section "Using Components from Outside Catalyst" [sic], page 60 or so. (the book, essentially an extended catalyst tutorial with good coverage of DBIC and TT thrown in, is a good read and covers ground that one cannot find elsewhere without piecing bits together from various sources. however, whoever packt, the publisher, found to write the "index" was way overpaid. that's too bad as it diminishes the book's usefulness.) k. [1] http://tinyurl.com/2fd5ld -- kevin montuori ___ 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: javascript in Catalyst using Template Toolkit
>>>>> "KD" == Kieren Diment <[EMAIL PROTECTED]> writes: KD> On 23 Dec 2007, at 01:06, kevin montuori wrote: >> (add-hook 'html-mode-hook KD> well tt-mode would be more sensible. my mileage varied. the font-locking of TT keywords would be ok but the the completion, indention, and validation sgml-/html-mode provides is actually useful. k. -- kevin montuori ___ 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] Re: javascript in Catalyst using Template Toolkit
>>>>> "AP" == A Pagaltzis <[EMAIL PROTECTED]> writes:
AP> * Daniel McBrearty <[EMAIL PROTECTED]> [2007-12-22 00:30]:
>> on the other hand, if you are running your app on a server that you
>> own and do admin for, and don't have such admin problems to negotiate,
>> it would be fine, eh? horses for courses and all that.
you probably have a good point but i don't believe it. to me this
reeks of "shortcuts" like running everything as root on a unix box or
using PHP. i would argue that writing code as if someone else were
going to deploy it and maintain it leads to good programming practices
(as well as frills like documentation, sensible built-in debugging,
real packaging, meaningful log messages, &c.) even if you're a one man
shop. consider: any code that you haven't looked at in six months may
as well have been written by somebody else anyway.
sorry to stray so far from the topic at hand; i've spent the last
couple years fixing former sysadmins' code/environment and your
mindset hit a nerve. if it works for you, honestly, that's super.
AP> Is it appreciably less work to omit the `[% c.uri_for('') %]`?
AP> It less than 20 extra characters up front.
obCatalyst: let me add that if you use emacs [insert emoticon of your
choice] you could define a little function like:
(defun ii-insert-catalyst-url ()
(interactive)
(let ((path (read-from-minibuffer "URI: ")))
(insert (format "" path))
(backward-char 4)))
to do the work for you. if you're accustomed to using html-mode or
sgml-mode you might even rebind C-c C-c h (html-href-anchor):
(add-hook 'html-mode-hook
'(lambda ()
(define-key html-mode-map "\C-c\C-c\h" 'ii-insert-catalyst-url)))
and there'd be no new finger memory to develop, so no extra work
whatsoever.
cheers.
k.
--
kevin montuori
___
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] Re: javascript in Catalyst using Template Toolkit
>>>>> "DM" == Daniel McBrearty <[EMAIL PROTECTED]> writes: >> My experience is that every time I think I -can- make that >> assumption, later I end up really wishing I could deploy my app to >> a sub-URL for testing or similar. DM> If I hit that one (needing to test code on the real server while DM> an existing version runs) I typically just run a second server on DM> port 8080 or something. heh. i'm picturing how that request would have gone over with the firewall group at the last fortune 500 i worked for. if you managed to write a business case and argue that opening the port was necessary it'd still have taken two weeks to accomplish (and some random and unknown port would have ended up opened up to the wrong subnet; but i digress). besides, but what about when you want to move your application to, say, a shared apache cluster where other applications are running? or you're told that you'll be using the latest and greatest new single sign on product and you need to have your application protected but the SSO login pages & images not? and what about when you want to run a second application or -- and don't think this doesn't happen -- some capricious managedroid decides to change the URL of your application? i can tell you that developers who write code that adapts well to the shifting whims of management (and deployment architects) have a happier and more fruitful life than the other kind -- as a release engineer, i make sure that's the case. sure there are times when planning for everything that might change is too difficult or not practical or too expensive, but catalyst makes this common problem just sort of go away with almost no added effort. regardless, good luck with your app. cheers. k. -- kevin montuori ___ 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] Re: retrieving multiple values from forms
>>>>> "je" == jagdish eashwar <[EMAIL PROTECTED]> writes:
>> So I changed the code to read "@role_id =
>> $c->req->params(role_id)" as Kevin suggested and put [EMAIL PROTECTED] in
>> the stash. Now there was no error, but I got "ARRAY(0x987e5e0)" in
>> the template instead of the role_id values.
i dare say that's not what i'd suggested. i wrote:
my @titles = ref $c->request->params->{title}
? @{ $c->request->params->{title} } : ($c->request->params->{title} || '');
the @{ ... } bit was not extraneous.
(on the other hand, if there's a more idiomatic way of doing this i'd
love to hear about it.)
but this is not a catalyst issue, 'perldoc perlref' for more on
references.
cheers.
k.
--
kevin montuori
___
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] Re: retrieving multiple values from forms
>>>>> "je" == jagdish eashwar <[EMAIL PROTECTED]> writes:
je> Example:- my $title = $c->request->params->{title} || '';
je> How can I retrieve multiple values from a selection list into an
je> array?
how about:
my @titles = ref $c->request->params->{title}
? @{ $c->request->params->{title} } : ($c->request->params->{title} || '');
k.
--
kevin montuori
[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] Re: How to insert from form to MySQL with autoincrement primary key?
>>>>> "PH" == Paul Henrich <[EMAIL PROTECTED]> writes: PH> You might check to make sure that you are loading PK::Auto in PH> MyAppDB::MyTable: I belive that with a recent DBIx::Class that's not necessary: perldoc DBIx::Class::PK::Auto indicates that "PK::Auto is now part of Core." k. -- kevin montuori [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/
