From a development standpoint, what are the features that make Ruby on
Rails a better choice compared to CakePHP?
Benjamin A. wrote:
From a development standpoint, what are the features that make Ruby on
Rails a better choice compared to CakePHP?
Wow. Never heard of Cake until now. I’m a php guy and I really would
like to know the same thing.
(now to cakephp for a closer look)
Ruby
CakePHP is essentially PHP on Rails.
Nothing beats the real thing baaaabyyyy, nothing beats the real thing…
Benjamin A. wrote:
From a development standpoint, what are the features that make Ruby on
Rails a better choice compared to CakePHP?
Meh. CakePHP looks good for a PHP solution. Back when I was fighting
the Flying Spaghetti Monster I prayed to Dew, the God of Development,
for stuff like CakePHP to take me away. But then I found Rails, and
Ruby… And given the choice I will never go back. I still cringe when
I have to load any .php file into an editor…
PHP will never be able to do what Ruby can do. Learn a bit about Ruby,
then read equivalent chapters in a PHP book and you’'ll burn your PHP
books as I did. :: shrug :: (Ok, I didn’t…but still, I was happy
enough to want to.)
-Curtis
Sascha E. wrote:
PHP will never be able to do what Ruby can do.
That might be right for some cases, but not for all. For example, what
if you were to build a script for distribution to clients who will
install it on their shared hosting accounts? RoR would clearly not be
the ideal solution for that (yet?).
Perhaps I should have mentioned that the reverse is also true. There
are some things that PHP can do that it’s currently difficult to do with
Rails. However, my comment was meant for PHP (the language) versus Ruby
(the language). Not necessarily Rails. (As an aside I consider it
insane–or maybe just sadistic–to utilize any language without decent
OOP facilities in this day. And, no, I don’t consider PHP to have
decent OOP facilities.)
As far as shared hosting, there are plenty that work for Rails. True,
the client’s current hosting company may not support it. :: shrug ::
That’s why we are consultants, not skriptkiddies. These Rails-like PHP
frameworks may be like working with Rails for the clients that use a
shared host that doesn’t support RoR. And the client is always right.
However, that doesn’t stop us from gently nudging them toward a path
more enlightened. My main argument is along the lines of “most likely
we can do this project and future maintenance at least twice as quickly
as we could in another language; so isn’t that worth a twenty-four
dollars a year in hosting?” (About a third of my hourly cost, most
clients are very receptive.)
I would counter your premise though by the fact that if they are already
using a hosting company utilizing PHP, they probably already have some
framework in place and you’ll probably need to integrate with that. So
integrating a new Rails-like PHP solution would probably be just as
interesting as reimplementing / integrating a Rails application. All
the shared hosts I’ve seen that support Rails, also support PHP; so you
build a Rails integration app; and toss it and the new stuff up onto a
new host.
:: shrug :: YMMV. I’m not necessarily advocating hammering nails with
a bratwurst (though sometimes I feel that’s what I’m doing when I load
the .php files up).
-Curtis
Do we still take into consideration the $10 a month that companies
pay for their shared hosting service as a major factor in the
decision of which technology they use? Wow. Shocking! That is a
slap in the face as a developer considering you should be making much
more then that an hour… not a month!
Peace, Love and Ruby. (yes, I just made that up… aern’t I witty.)
On 11-Jun-06, at 12:41 PM, Curtis S. wrote:
language) versus Ruby (the language). Not necessarily Rails. (As
nudging them toward a path more enlightened. My main argument is
would probably be just as interesting as reimplementing /
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
John K.
http://www.kopanas.com
============================================================
http://www.soen.info - Index of online software engineering knowledge
http://www.cusec.net - Canadian University Software Engineering
Conference
http://www.soenlive.com - Presentations from CUSEC
PHP will never be able to do what Ruby can do.
That might be right for some cases, but not for all. For example, what
if
you were to build a script for distribution to clients who will install
it
on their shared hosting accounts? RoR would clearly not be the ideal
solution for that (yet?). RoRs sweetspot are db backed web applications
on
your own (ideally fully controlled) server which is only a tiny amount
of
what is being installed on web servers world wide.
Choose the right tool for the job.
I prefer to be able to use both to their full effect.
Their are several promising PHP framework that try to emulate some or
many
aspects of Rails.
-Sascha E.
Curtis S. wrote:
Perhaps I should have mentioned that the reverse is also true. There
are some things that PHP can do that it’s currently difficult to do with
Rails.
Like what? And what can Ruby do that php can’t?
What I like with cakephp is that I don’t have to learn a new language
(Ruby). But on the other hand I like the simplicity with Ruby (what I’ve
seen so far). Even more important is the fact that many things I’ve seen
regarding Ruby and RoR is good looking design-wise. May sound trivial,
but to me. It says a lot. So, I’m not sure what path to follow.
Am 12.06.2006 um 00:23 schrieb
Pål Bergström:
What I like with cakephp is that I don’t have to learn a new language
(Ruby). But on the other hand I like the simplicity with Ruby (what
I’ve
seen so far). Even more important is the fact that many things I’ve
seen
regarding Ruby and RoR is good looking design-wise. May sound trivial,
but to me. It says a lot. So, I’m not sure what path to follow.
Learning a new (good) language and how to use a new (good) framework
will certainly be to your good. Even if you dislike something in Ruby
and Rails you will have learned something and then you can say “I
like PHP/thisframework better than Rails because of XYZ” instead of
having an opiniion that is not based on experience with Ruby or Rails
but on bias.
I do not want to say that you are biased or that you will dislike
Ruby or Rails simply that you gain any way: Never stop learning.
*m
–
I have found an elegant and short solution for Fermat’s Theorem
but sadly there is not enough space for it in this signature.
On Mon, Jun 12, 2006 at 12:23:35AM +0200, Pål Bergström wrote:
Curtis S. wrote:
Perhaps I should have mentioned that the reverse is also true. There
are some things that PHP can do that it’s currently difficult to do with
Rails.Like what? And what can Ruby do that php can’t?
PHP && !Ruby:
- Simple templating (<?php include 'header.html' ?>)
- No-effort database access
- Near-ubiquity
Ruby && PHP.nil?
- Blocks
- Real OO
- Blocks
- A sane object model / standard library
- Blocks
And the list goes on (with blocks featuring heavily – I heart
blocks).
Yes, all Turing-complete languages can in theory substitute for each
other,
but if I asked you what can PHP do that C can’t, I’m sure you could list
a
couple of things that make PHP better for web programming than C.
What I like with cakephp is that I don’t have to learn a new language
(Ruby).
I learnt the new language, and I like it way better than I ever liked
PHP.
It gives me a lot more nice “shivery” moments, where I just blast out
some
nice piece of code in a line or two, then look at it and think “that
looks
good”, and then start thinking about how much crap I would have had to
wade through to make that happen in PHP.
But on the other hand I like the simplicity with Ruby (what I’ve
seen so far).
Mmmm, simplicity. That’s probably the thing that most irritates me
about
PHP – it’s like a Server Side Include engine that got hit with mutating
radiation. It’s just ballooned into this giant, mutant… thing, with
tentacles everywhere. And those tentacles hide a myriad of gotchas,
security issues, crazy defaults, and other things that are just
guaranteed
to cause you pain sooner or later. There’s no denying, though, that PHP
is
the world’s greatest SSI language – you just shouldn’t need a 3MB
binary to
do SSI.
Even more important is the fact that many things I’ve seen regarding Ruby
and RoR is good looking design-wise. May sound trivial, but to me. It says
a lot. So, I’m not sure what path to follow.
Yes, the design of Rails is very good, and it speaks well of DHH and the
rest of the team that it is, for the most part, so very good. I’m quite
curious about how much of the beauty of Rails’ design is due to Ruby’s
calming influence, or whether a lot of it’s useful features would have
looked much the same had Rails been developed in, say, Python. I know,
though, that Rails could not have looked like Rails had it been in any
other
language (with the possible exception of SmallTalk, perhaps), just
because
of the uniqueness of Ruby’s language structure.
- Matt
As far as shared hosting, there are plenty that work for Rails.
Maybe you misunderstood me or I have not expressed myself clearly. I am
talking about about software packages like any blog package (Wordpress,
Expression Enginge), CMSes (Typo3, Mambo, Drupal, …), and so on.
Just imagine the Wordpress developers would suddenly not support PHP
anymore…
or
How short-sighted it would be to distribute such a package in Ruby
(right
now) if (and that is a big if) your main goal is wide
distribution.
You may have other goals and than RoR might be the best choice. I like
to
use both. I think this is no problem as long as you know the benefits
and
short-comings of both.
I suspect that the distribution of RoR apps will get easier in the
future,
but, on the scale I am talking about it will take many years. This is
maybe
comparable to the distribution of new Browsers like IE 7, which is going
to
take 5-10 years before we can stop supporting older versions
(hopefully).
-Sascha E.
Sascha E. wrote:
As far as shared hosting, there are plenty that work for Rails.
Maybe you misunderstood me or I have not expressed myself clearly. I
am talking about about software packages like any blog package
(Wordpress, Expression Enginge), CMSes (Typo3, Mambo, Drupal, …),
and so on.
Ah! Yes… Well my core projects are not CMS systems. In fact I can’t
stand common CMS systems.I haven’t met a single one I didn’t want
to beat the hell out of in a dark alley somewhere… The beauty of
Rails is that I can bypass and rewrite the core of what my clients need
in nearly as much time as it would take to figure out the damn CMS
package; but we’ve hashed and rehashed that one several times on the
list…
As you say, to each his own; and definitely use the tool that fits.
-Curtis
P.S. I would actually like to see a RoR version of Wordpress… That
would rule… If someone likes a software package, they will typically
do whatever they need to do to ensure it starts working. :: shrug ::
Even though Gramms doesn’t know much about computers, she will find
someone who does so that she can set up the weekly bridge blog… 
Options are good for geeks…and it doesn’t hurt anything to have the
Flying Spaghetti Monster around. He’s actually useful for some things.
Just less useful than he was a year ago.
Pål Bergström wrote:
Curtis S. wrote:
Perhaps I should have mentioned that the reverse is also true. There
are some things that PHP can do that it’s currently difficult to do with
Rails.Like what? And what can Ruby do that php can’t?
Matt did a pretty good job hitting most of the points I would hit; I
just would like to flesh out the OOP stuff a bit. The thing that bugs
me most about PHP was that it started out as a really good SSI
engine. Then everything was bolted on without consistency. If you’ve
ever tried to use PHP 4 objects and suffered from
Too-Many-Ampersand-Syndrome, you’ll understand. I don’t even attempt to
use OOP PHP unless I can guarantee I’ll be on a PHP 5 box. But then
that limits your possibilities somewhat… :: shrug :: (I figure if
I’m dictating server configurations, why not give them a RoR
configuration.)
What I like with cakephp is that I don’t have to learn a new language
(Ruby). But on the other hand I like the simplicity with Ruby (what I’ve
seen so far). Even more important is the fact that many things I’ve seen
regarding Ruby and RoR is good looking design-wise. May sound trivial,
but to me. It says a lot. So, I’m not sure what path to follow.
The design is beautiful. DHH is an artist. I absolutely hate XML
configuration files. Whenever I load one up in an editor I feel blood
and fire and hell rain down disguised as happy little tags…
But i digress… Like a government linguist, the more languages you
know, the more valuable you will become. And it helps to be able to
pick out good constructs and bad constructs. It helps determine which
hammer, saw, chisel, or pneumatic-nailer you’re going to use for a
project. If you only know one tool, you’ll only be able to solve
problems in the perspective of that tool.
I would imagine like many others around here, I know about five or six
core languages (not counting the derivations of) and Ruby is by far my
favorite. I work with J2EE / .NET / PHP almost exclusively at my “day
job”. But when I’m working in the batcave I like to see what I can make
RoR do. And I feel sooo much more productive. :: shrug :: It’s been
a while since programming was fun. I’m starting to remember why I got
into this business in the first place!
-Curtis
We just performed a survey on web frameworks where I work. We
compared CakePHP, Django, Rails, and Symfony (another PHP framework).
Symfony actually rated much higher than CakePHP, but Rails rated
highest. Django didn’t make the cut for our needs. Some of the
differences we found:
Ajax: Rails and Symfony both use Scriptaculous and Prototype. CakePHP
does, but you have to download and install it separately, which, to
me, calls into question how well they’re integrated.
Authentcation: CakePHP has a built-in system, but that system won’t
fit all needs, so you’ll end up writing custom code anyway.
Caching: CakePHP only has view caching.
Database versioning: None in CakePHP or Symfony, though Symfony has an
XML file for each db table, and, I suppose, you could svn them and
have versioning that way. Migrations in Rails are superior.
Environments: No real separation of environments (prod/dev/test) in
CakePHP.
Console: None in CakePHP. Symfony and Rails, yes. If you want to use
Rails and you think you won’t use the console, you’re wrong. Once you
understand the power, you’ll never want to debug without it.
Testing: Little integrated testing. It produces some stubs when you
“bake” a project, but I prefer how Rails puts those stubs there when
you’re creating models and controllers, right from the get-go. (More
on this below.)
Join models: None in CakePHP. Rails has HABTM and has_many :through.
All tables are models in Symfony, so that’s almost the same. More
like HABTM with extra info in the table. Propel, Symfony’s ORM
engine, is actually quite interesting. (Though, I prefer
ActiveRecord.)
Form validation: Good in all frameworks, but there are some extra
steps involved in dealing with invalid form data in CakePHP.
The kicker, in my eval, was documentation and training resources.
With 3 published books, 2 more on deck from O’Reilly, and, from what I
found, at least half a dozen more announced, Rails has the edge.
There are currently 11 scheduled Rails training opportunities in the
US right now.
As far as I could tell, there are NO books or training classes for
CakePHP or Symfony. Django has one book coming, announced in, I
think, February.
To defeat hit-by-the-bus syndrome, it was important to me is to be
able say to a new developer on day 1, “Hey, here’s some books, and
we’re registering you for training. Welcome aboard.” The other
frameworks, despite having great features, are missing this key piece.
Back to the Integrated Testing question, I think the lack of
documentation really killed CakePHP for me. We had the answer as “No
testing at all” until we ran into it by accident. As of last week,
there was NO mention of testing in the online docs at all.
Anyway, those were some of our findings, based on our needs and wants
and desires. I can’t claim we’re 100% right on all of them, so please
feel free to correct me.
Hope this helps,
Sean
If you have a menu that is the same in all pages for your application I
would suggest writing it as a partial and calling this from your
application.rhtml in layouts. This will put it on every page that uses
the
application layout, and if you decide to have more layouts it’s a one
liner
to include it in them too.
A partial is not used as a class as such, it’s an rhtml file that begins
with an _ that you can include in a view
<%= render :partial => “menus” %> #=> will include the _menus.rhtml
file at
that point in the view.
Alternatively you could write a helper method and put that in
application_helper.rb and then call it in your layout
<%= menu_helper_method %>
Hope this helps
Sean H. wrote:
Hope this helps,
Sean
Yes it does
What Matthew said about includes bothers me. How do you “include” a menu
that is the same on all pages? I guess a custom written class, right?
Classes is a week spot of mine, so it might be a stupid question.
Il giorno 12/giu/06, alle ore 09:04, Pål Bergström ha scritto:
that is the same on all pages? I guess a custom written class, right?
Classes is a week spot of mine, so it might be a stupid question.
Not at all, you have to use layouts.
your menu stuff <%= @content_for_layout %>If you search for layouts on RoR site you’ll find a better
explanation 
Basically, you can define a skeleton for you
application and then include custom content.
ngw
Nicholas W.
[email protected]
Chiacchiera con i tuoi amici in tempo reale!
Yahoo Search - Ricerca nel Web | Motore di Ricerca
Sean H. wrote:
Ajax: Rails and Symfony both use Scriptaculous and Prototype. CakePHP
does, but you have to download and install it separately, which, to
me, calls into question how well they’re integrated.
I choose not to include any code outside of the project in the releases.
You can use any of the packages you mention above and there are others
people use also. As to how well they are integrated, Scriptaculous and
Prototype are the most popular and are integrated very well. Any of the
other libraries people want to use are easy with the creation of a
simple helper
Authentcation: CakePHP has a built-in system, but that system won’t
fit all needs, so you’ll end up writing custom code anyway.
Agreed on this, I tell everyone my way of authentication may not fit
your way, so for someone to be able to write a do it all authentication
implementation I do not see it happening. Can the current one be
extended, of course. As with all the code in CakePHP you can extend it
very easily.
Caching: CakePHP only has view caching.
No true, CakePHP can also cache models and meta data of the tables. The
view caching if used properly, reduces all calls to the database, but
view caching is different from the model and meta data caching
Database versioning: None in CakePHP or Symfony, though Symfony has an
XML file for each db table, and, I suppose, you could svn them and
have versioning that way. Migrations in Rails are superior.
Although a separate project on cakeforge.org it is available.
Cake Migrations:
http://cakeforge.org/snippet/detail.php?type=package&id=15
Environments: No real separation of environments (prod/dev/test) in
CakePHP.
Not correct:
app/config/core.php
app/config/database.php
Join models: None in CakePHP. Rails has HABTM and has_many :through.
All tables are models in Symfony, so that’s almost the same. More
like HABTM with extra info in the table. Propel, Symfony’s ORM
engine, is actually quite interesting. (Though, I prefer
ActiveRecord.)
CakePHP handles all type of association hasOne hasMany belongsTo
hasAndBelongsToMany. CakePHP also has recursive associations that allow
you to create very complex hierarchies in a very simple way
I would say the best example of this would be the Bakery project at
cakeforge.org
Database image:
https://cakeforge.org/plugins/scmsvn/viewcvs.php/trunk/bakery/docs/bakery.png?rev=30&root=bakery&view=markup
Models:
https://cakeforge.org/plugins/scmsvn/viewcvs.php/trunk/bakery/models/?root=bakery
The controllers and view where created using the CLI bake.php in
cake/scripts/ and modified to use the admin routing. The code in these
files is not released in a package yet, since it is still being
developed
Our mail list grows daily with users and our irc channel is also a very
good place to get immediate help with a problem you may run into.
http://groups.google.com/group/cake-php/about
irc.freenode.net #cakephp
Also about testing:
I wrote the test suite for CakePHP and at one time had it included in
the core, but separated it as its own project since people who use TDD
(Test Driven Development) would be able to install the test suite and
not everyone sees the advantage of using TDD. The suite itself is very
well integrated into CakePHP and a simple upload of the package is all
that is needed to use it
I would not try to compare RoR and CakePHP like most people try to do.
CakePHP and RoR are tools of the “trade” if you will, and like any trade
you use the proper tools for the proper job. Does RoR or CakePHP work
for every project out there, No, and I do not see there ever being a
“god” framework to do it all. I use RoR, but develop CakePHP along with
a one other core developer. And IMO, which is a little biased, say we do
have the best framework for PHP applications. We also have a document
team that is starting to create some very useful documentation
.
Anyway hope these corrections help.
Larry E. Masters aka PhpNut
On Jun 11, 2006, at 4:22 PM, Matthew P. wrote:
PHP && !Ruby:
- Simple templating (<?php include 'header.html' ?>)
Just out of curiosity how is that different than:
<%= render :partial => ‘header’ %>
???
–
– Tom M.