Re: [Catalyst] source out accessors to LDAP-Model
On Mon, Dec 13, 2010 at 9:24 AM, piccard picc...@web.de 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 raand...@cyber-office.net 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 soft...@leandrohermida.com 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 w...@grepit.net 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 brain...@brainbuz.org 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 publiustemp-catal...@yahoo.com 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: Deployment in practice
MA == Mesdaq, Ali ames...@websense.com 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 devin.aus...@gmail.com 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 devin.aus...@gmail.com 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] Re: RFC: Sample press release and announcement homepage
ZL == Zbigniew Lukasiak zzb...@gmail.com 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: 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] 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: Development environments and performance
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: 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: 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/
