[Catalyst] Bing!
Sebastian Riedel
sri at oook.de
Sat Aug 13 03:36:53 CEST 2005
Am 13.08.2005 um 02:53 schrieb Kyle Maxwell:
>> Well, a lot of the helpers (which make Rails look so elegant)
>> like autocomplete_for depend on a strict boundry.
>>
>
> Boundry, or binding?
Binding.
>
>
>>
>>
>>> * You can use multiple view types. At this point, eRb and
>>> builder are the documented ones.
>>>
>>
>>
>> I never said something else.
>> But can you easily use multiple identical views with different
>> configs?
>> For example we like to have two TT views in restricted and non
>> restricted mode. (the restricted one for user editable templates)
>>
>
> Not sure what you're getting at.
Catalyst views are usually classes derived from template system
specific base classes.
package MyApp::V::TT;
use base 'Catalyst::View::TT';
1;
package MyApp::V::TTwithUnicode;
use base 'Catalyst::View::TT';
__PACKAGE__->config->{UNICODE} = 1;
1;
So you can easily use multiple TT views with different configs in the
same app, this may be not the best example but you get the idea. :)
>
>
>>
>>
>>> * Rails dispatcher "routes" is flexible, as it has just recently
>>> been rewritten. As to the example Sebastian made of index.html
>>> requiring a rewrite layer, in Rails, just put the index.html
>>> file in the public directory and it automatically is on your site.
>>>
>>
>>
>> Routes is a rewrite engine, like mod_rewrite, it doesn't change
>> the fact that the core uri mapping depends on /class/method/
>> arg1in Rails...
>>
>> I didn't meant a static file index.html, i meant a action.
>>
>> sub index : Path('/index.html') { }
>>
>
> So what you are saying is that rather than manage your paths in one
> config file, you'd like to be able to add paths in the controller?
> That sounds nifty, although there seems to be potential for two
> different controllers/actions executing on the same path
> unintentionally.
I don't want to be able to do this, i am able to do this, since this
is the default way Catalyst handles it. :)
And no, there can be only one method handling a specific uri, at
least with the default dispatcher.
We also have nice formatted table logs to give you an overview of
defined actions.
[Sat Aug 13 03:17:13 2005] [catalyst] [debug] Loaded private actions:
.=-------------------------------------
+--------------------------------------=.
| Private |
Class |
|=-------------------------------------
+--------------------------------------=|
| /default |
KittenFarm |
| /test2/add |
KittenFarm::C::Test2 |
| /test2/default |
KittenFarm::C::Test2 |
| /test2/edit |
KittenFarm::C::Test2 |
| /test2/end |
KittenFarm::C::Test2 |
| /test2/view |
KittenFarm::C::Test2 |
| /test2/do_add |
KittenFarm::C::Test2 |
| /test2/do_edit |
KittenFarm::C::Test2 |
| /test2/destroy |
KittenFarm::C::Test2 |
| /test2/list |
KittenFarm::C::Test2 |
| /test/add |
KittenFarm::C::Test |
| /test/default |
KittenFarm::C::Test |
| /test/edit |
KittenFarm::C::Test |
| /test/end |
KittenFarm::C::Test |
| /test/view |
KittenFarm::C::Test |
| /test/do_add |
KittenFarm::C::Test |
| /test/do_edit |
KittenFarm::C::Test |
| /test/destroy |
KittenFarm::C::Test |
| /test/list |
KittenFarm::C::Test |
'=-------------------------------------
+--------------------------------------='
[Sat Aug 13 03:17:13 2005] [catalyst] [debug] Loaded public actions:
.=-------------------------------------
+--------------------------------------=.
| Public |
Private |
|=-------------------------------------
+--------------------------------------=|
| /test/add | /test/
add |
| /test/destroy | /test/
destroy |
| /test/do_add | /test/
do_add |
| /test/do_edit | /test/
do_edit |
| /test/edit | /test/
edit |
| /test/list | /test/
list |
| /test/view | /test/
view |
| /test2/add | /test2/
add |
| /test2/destroy | /test2/
destroy |
| /test2/do_add | /test2/
do_add |
| /test2/do_edit | /test2/
do_edit |
| /test2/edit | /test2/
edit |
| /test2/list | /test2/
list |
| /test2/view | /test2/
view |
'=-------------------------------------
+--------------------------------------='
We have a two level private/public action mapping to support more
advanced stuff like regex actions.
sub foo : Regex('^.*\.html$') {}
>
>
>>
>>
>>> * Ruby on Rails is extendable. I have added tagging and file
>>> upload support to ActiveRecord. It was easy.
>>>
>>
>>
>> Just look into our collection of plugins http://
>> dev.catalyst.perl.org/ browser/trunk/ don't tell me you can do all
>> this with Rails so easily with so few lines. :)
>> Examples are Catalyst::Plugin::SubRequest,
>> Catalyst::Plugin::Static, Catalyst::Plugin::XMLRPC,
>> Catalyst::Plugin::Unicode...
>>
>>
> I didn't look at your files, but Rails extentions typically require
> only one additional line of code outside of the module that you are
> including (which is just the normal class structure).
Maybe i was not specific enough.
Lets say you want to utf8 encode all input parameters, in Catalyst
you just wrap another method around the original prepare_parameters
method using multiple inheritance and NEXT.
sub prepare_parameters {
my $c = shift;
$c->NEXT::prepare_parameters;
for my $value ( values %{ $c->request->{parameters} } ) {
next if ( ref $value && ref $value ne 'ARRAY' );
utf8::decode($_) for ( ref($value) ? @{$value} : $value );
}
}
>
>
>>> * Multiple inheritance is considered an anti-pattern by many.
>>> Ruby supports module mix-ins, which give the benefits of
>>> multiple inheritance without some of the drawbacks.
>>>
>>
>>
>> Guess you never heard of NEXT. (http://cpansearch.perl.org/
>> ~dconway/ NEXT-0.60/lib/NEXT.pm)
>> We use multiple inheritance as a kind of advanced AOP.
>> Think AspectJ without the static trigger points. :)
>>
>> Mixins are something completely different...
>>
>
> The link 404ed. Multiple inheritance, and inheritance in general
> where composition could be used, is frowned upon in some circles.
> Maybe not your circle, but that's ok. I wasn't disapproving, jsut
> pointing out the differences of opinion. I know that mixins and MI
> are strictly different, but they are used in similar ways for
> similar reasons. If you want MI, maybe mix-ins will be good enough.
http://cpansearch.perl.org/dist/NEXT/lib/NEXT.pm
No, this is not about adding methods to derived classes.
This is about nesting methods on different inheritance levels, NEXT
makes it possible to call all methods with the same name on all
levels of inheritance.
>> We have a much finer grained separation, take ActionPack for
>> example, it's dispatcher, session management, url rewriting, view
>> and platform binding (fcgi, mod_ruby), all in one.
>> Our Catalyst main package just includes a basic set of platform
>> bindings and the dispatcher. (just the core)
>>
>>
> I haven't yet found that level of separation to be useful. I'm
> glad that you do. I suspect that you could probably separate out
> those components of RoR and use them separately. But it seems that
> its just easier to distribute them all packaged, because no one
> wants to get them separately.
We in Perl land use Bundle packages for that task. (they just contain
lists of packages)
Fine grained separation is essential for easy extendability, Catalyst
is what we call Lego architecture, built out of many small
interchangeable bricks.
--
sebastian
More information about the Catalyst
mailing list