[Catalyst] Bing!

Kyle Maxwell kyle at efactormedia.com
Sat Aug 13 02:53:43 CEST 2005


Sebastian Riedel wrote:

>
> Am 13.08.2005 um 00:16 schrieb Kyle Maxwell:
>
>>
>> * Rails is built as 5 separate components, each available from  
>> RubyGems (CPAN analogue).  They can be and are used separately,  
>> although this is not that common.
>
>
> But what other models are there next to Active::Record?
> How hard is it to write one?
>
> I heard DHH advertises NO-TIMTOWTDI as a feature. :)

There's something called Madeline as another option.  I haven't explored 
it.  The community hasn't really had a chance to fork much yet.  DHH 
says "convention over configuration," which to me means that there is 
one right way to do things, but if you need an exception for some 
reason, there's a command to override the default setting.  But there 
are standard default settings that were chosen for a good reason, and 
they make your life easier.

>
>> * Model classes are *NOT* strictly bound to controllers.
>
>
> Well, a lot of the helpers (which make Rails look so elegant) like  
> autocomplete_for depend on a strict boundry.

Boundry, or 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.

>
>> * 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.

>
>> * 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).

>> * 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.

>
>> * Ruby is slower than perl.  You're right about that.  Hopefully  
>> Rails helps spur the developement of Ruby 2, which will have a Java- 
>> like bytecode VM.
>
>
> Yea, traversing node trees is not so nice. ;)
>
>> * Rails is both "all-in-wonder" and componentized.  I love the all- 
>> in-one-ness, because the integration is flawless, and you can go to  
>> one site for the documentation and updates.
>
>
> 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.

>
> -- 
> sebastian
>
>
> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst
>
>




More information about the Catalyst mailing list