Re: [Catalyst] Re: Catalyst site design drafts feedback thread
* On Thu, Jun 12 2008, Cory Watson wrote: I've been ignoring this thread because it's a bunch of bikeshedding. Basically, I agree. Let's let the designers design. There is nothing worse than a committee that distorts the artist's vision. (When everyone agrees on every detail, you get Microsoft. Bland.) We are never going to settle on a design that satisfies everyone or every concern. Live with it :) It all boils down to this. Catalyst is the only really useful Perl web framework. Perl is the only really useful language for writing web applications. So people are going to use Catalyst regardless of whether the background color on the website is #83f8e2 or #85f9ff. Let's spend our collective efforts doing something other than arguing about colors. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ 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] Re: Catalyst site design drafts feedback thread
Jonathan Rockway wrote: Let's spend our collective efforts doing something other than arguing about colors. Exactly. Leave the design of the site as it is and concentrate on making the the content easier to understand and use. Sprawling inconsistent self-contradictory content is still that no matter what colour you paint it. Make the content easy to find and use and it almost doesn't matter what the design looks like. Information architects hate this design-down approach as much as you core Catalyst developers hate poor APIs. Both desires, easy to use web sites and well thought out adaptable APIs require similar approaches and deep thinking in understanding how the site/code may be used and abused. But I guess I am bikeshedding, I don't have the time to be actively involved in the process so what I say is less important. FWIW, I vote that Matt picks what he likes and goes with it as someone is always going to be unhappy with the end result. S. ___ 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] Re: Catalyst site design drafts feedback thread
* On Fri, Jun 13 2008, Jonathan Tweed wrote: On 13 Jun 2008, at 13:51, Jonathan Rockway wrote: It all boils down to this. Catalyst is the only really useful Perl web framework. Perl is the only really useful language for writing web applications. So people are going to use Catalyst regardless of whether the background color on the website is #83f8e2 or #85f9ff. I think you're missing an 'if you only know Perl'. Otherwise you're just talking shit ;-) I'll bite. I've written web applications in Java, PHP, Cold Fusion, Common Lisp, Haskell, and OCaml. None of these languages have anywhere near the number of libraries that Perl does, and as a result I either waste time reimplementing something trivial-but-tedious, or I settle for half-assed solutions. Java is close, but the syntax is so tedious it's hard to pay attention to the libraries. (PHP and CF aren't real programming languages, so it's not a surprise that there are no libraries.) The Python, Ruby, and Common Lisp communities all share the attitude towards libraries -- if it works for the author, it's perfect; as a result most of the libraries are half-assed special cases that may or may not be helpful. I don't know how Perl escaped this, but it did... most module authors feel obligated to make something generally useful. (Of course there's a lot of junk, but that's fine; nobody uses the junk libraries.) It's a real shame that Lisp doesn't have Perl's libraries, 'cause I really like it a lot better than Perl. It's just that it's not useful for anything. (Emacs Lisp is the exception; not that great of a programming language, but you can do anything in about 5 lines of code thanks to the extensive libraries. But I digress.) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ 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] ANNOUNCE: 0.09_01 dev release of Rose::DBx::Garden::Catalyst
I've just uploaded a new 0.09_01 dev release of Rose::DBx::Garden::Catalyst to CPAN. The package has been completely refactored with one principle in mind: move what used to be generated code into test-able, subclass-able, Perl modules. The RDGC project was described in last year's Catalyst Advent calendar here: http://www.catalystframework.org/calendar/2007/7 Also new in this version: * support for YUI 2.5.x * Excel export of db records * lots of UI improvements Feedback, comments welcome. -- Peter Karman . [EMAIL PROTECTED] . 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] Multiple inheritance of controllers
I ran into the same problem. But I found that adding this to my controllers
that inherit from multiple controller base classes works as a work around:
use Class::C3;
sub create_action {
my $self = shift;
return $self-maybe::next::method(@_);
}
It's an annoying workaround, but I didn't have time to pursue the issue any
further :P Does anybody know why this might be happening?
Anyway, I hope that helps somewhat..
Byron
Zbigniew Lukasiak wrote on 2008-06-13:
I've tried to build a module that would merge two base controllers and
then use it as another base controller. Unfortunately it looks like
only actions from the first base class in the 'use base ...' phrase are
being inherited:
I've created a test case for that - it is attached and I paste it
below for your convenience.
If someone sent me some instructions how to modify it to fit into the
Moose model I'll test it on the Moose branch as well (I am not sure if
they would be base controllers there at all - perhaps Roles instead?).
Cheers,
Zbigniew
package TestApp::Controller::Action::SubclassedChained;
use strict;
use warnings;
use base qw/Intermediate/;
1;
==
package Intermediate; use strict; use warnings;
use base qw/Catalyst::Controller::REST Base/; # this one does not
inherit actions from Base
#use base qw/Base Catalyst::Controller::REST/; # this one does
1; ==
package Base; use strict; use warnings;
use base qw/Catalyst::Controller/;
sub basefoo :CaptureArgs(1) :Chained('/') { }
sub baseendpoint :Args(1) :Chained('basefoo') { }
1;
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
