Forum: Ruby on Rails Ruby on Rails and CakePHP Comparison

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
75517f7a5e20e9a3b2685a4b0582a30d?d=identicon&s=25 Benjamin Arai (benjamin)
on 2006-06-11 06:51
From a development standpoint, what are the features that make Ruby on
Rails a better choice compared to CakePHP?
3275da7fdbd73cb4e7956fd0d29164de?d=identicon&s=25 Paul Bergstrom (palb)
on 2006-06-11 12:15
Benjamin Arai 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)
Fd4f7add4445007baedc5d84f9e67ca2?d=identicon&s=25 Ross Riley (Guest)
on 2006-06-11 15:51
(Received via mailing list)
Ruby
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-06-11 18:04
(Received via mailing list)
Benjamin Arai 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
91dbbd767b81caeb3652ce708728d906?d=identicon&s=25 Michael Scappa (Guest)
on 2006-06-11 18:20
(Received via mailing list)
CakePHP is essentially PHP on Rails.

Nothing beats the real thing baaaabyyyy, nothing beats the real thing...
722a18819725c0f6275b556ced89a3f4?d=identicon&s=25 Sascha Ebach (Guest)
on 2006-06-11 18:26
(Received via mailing list)
> 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.

http://www.h3rald.com/articles/view/rails-inspired...

-Sascha Ebach
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-06-11 18:45
(Received via mailing list)
Sascha Ebach 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
3b985461018c5edb36619bc30a70548d?d=identicon&s=25 John Kopanas (Guest)
on 2006-06-11 20:53
(Received via mailing list)
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 Spendlove 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
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails


John Kopanas
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
3275da7fdbd73cb4e7956fd0d29164de?d=identicon&s=25 Paul Bergstrom (palb)
on 2006-06-12 00:23
Curtis Spendlove 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.
54532f023496410e0d7b1add5561ba45?d=identicon&s=25 Manuel Holtgrewe (Guest)
on 2006-06-12 01:23
(Received via mailing list)
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.
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matthew Palmer (Guest)
on 2006-06-12 01:29
(Received via mailing list)
On Mon, Jun 12, 2006 at 12:23:35AM +0200, Pål Bergström wrote:
> Curtis Spendlove 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:

1) Simple templating (<?php include 'header.html' ?>)
2) No-effort database access
3) Near-ubiquity

Ruby && PHP.nil?

1) Blocks
2) Real OO
3) Blocks
4) A sane object model / standard library
5) 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
722a18819725c0f6275b556ced89a3f4?d=identicon&s=25 Sascha Ebach (Guest)
on 2006-06-12 03:13
(Received via mailing list)
> 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 Ebach
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-06-12 06:08
(Received via mailing list)
Sascha Ebach 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.
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-06-12 06:27
(Received via mailing list)
Pål Bergström wrote:
> Curtis Spendlove 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
2b2c2a705ed12f8fb327c7b4c56456c6?d=identicon&s=25 Sean Hussey (seanhussey)
on 2006-06-12 06:56
(Received via mailing list)
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
3275da7fdbd73cb4e7956fd0d29164de?d=identicon&s=25 Paul Bergstrom (palb)
on 2006-06-12 09:04
Sean Hussey 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.
9d1f5d2d9de70bd9a934f557dc95a406?d=identicon&s=25 Daniel ----- (liquid)
on 2006-06-12 11:46
(Received via mailing list)
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
7cdce9e94d317c4f0a3dcc20cc3b4115?d=identicon&s=25 Nicholas Wieland (Guest)
on 2006-06-12 13:15
(Received via mailing list)
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.

<html>
   <body>
     your menu stuff
     <%= @content_for_layout %>
   </body>
</html>

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 Wieland
nicholas_wieland@yahoo.it



Chiacchiera con i tuoi amici in tempo reale!
 http://it.yahoo.com/mail_it/foot/*http://it.messen...
D93cd9db8f2e3cdc03f985fc4bc8e31b?d=identicon&s=25 Larry E. Masters (Guest)
on 2006-06-12 15:55
Sean Hussey 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=packa...

>
> 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/t...

Models:
https://cakeforge.org/plugins/scmsvn/viewcvs.php/t...

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
722a18819725c0f6275b556ced89a3f4?d=identicon&s=25 Sascha Ebach (Guest)
on 2006-06-12 18:02
(Received via mailing list)
Thank you for writing this up, Sean.

I have investigated this myself and found exactly what you found (mainly
concerning CakePHP). Maybe with the exception of Console (or rather
Bake)
support in CakePHP. I specifically tried to contribute to this and was
really annoyed at the maintainers of the project. Without going into
details they were very (overly) defensive about their project. I tried
to
DRY up the source code a bit and that was not at all what they wanted.
Especially the project lead PhpNut_. So we got into an hour long
discussion
(in #cakephp) with the result of me deciding not to waste anymore time
with
CakePHP ;) It was just too hard for me to contribute.

Also, since they try to emancipate themselves from Rails, you cannot
really
argue like "but Rails does it that way, could we do something like that
in
CakePHP?". You will only get answers like "don't you dare bring up Rails
here" or "oh no, he mentioned the R word". This really turned me off.

It is funny. If you are like me and like to use both you seem to get
heat
from both sides of the fence...

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

This was the biggest issue for me, too. Actually you can formulate this
even broader. The part of Rails which tries to bring you to use better
work
practices is almost completely missing from CakePHP. Be it testing,
structure or the other many little things that Rails does. But this is
missing in almost all (I know of no exception) RoR wannabes.

I tried to talk to them about this, too, but there was actually no
understanding of why you would need that. I got the feeling that they
actually didn't quite know what I was talking about. This probably stems
from the fact the core CakePHP team has not actually used RoR
extensively
enough to know what all is done in RoR and what of it could be used to
make
CakePHP better. When it comes down to it, this is the main issue which
is
responsible for all other shortcomings of CakePHP or any other RoR
inspired
php framework. RoR has gotten so huge that you can't easily replicate it
in
another language with _major_ effort in both worlds.

My current php favourite is http://www.codeigniter.com/. They have some
good documentation. And their goals are in line with mine. From their
website:

Who is Code Igniter For?

Code Igniter is right for you if:

* You want a framework with a small footprint.
* You are not interested in large-scale, monolithic libraries, like
PEAR.
* You need broad compatibility with standard hosting accounts that run a
   variety of PHP versions and configurations.
* You want a framework that requires nearly zero configuration.
* You want a framework that does not require you to use the command
line.
* You do not want to be forced to learn a templating language.
* You need exceptional performance.
* You eschew complexity, favoring simple solutions.
* You need clear, thorough documentation.

They have very good video tuts, too.

-Sascha Ebach
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-06-12 19:24
(Received via mailing list)
On Jun 11, 2006, at 4:22 PM, Matthew Palmer wrote:

>
> PHP && !Ruby:
>
> 1) Simple templating (<?php include 'header.html' ?>)

Just out of curiosity how is that different than:

<%= render :partial => 'header' %>

???

--
-- Tom Mornini
3275da7fdbd73cb4e7956fd0d29164de?d=identicon&s=25 Paul Bergstrom (palb)
on 2006-06-12 19:46
Daniel ----- wrote:

> <%= 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

Great. :-) Much the same as an php include then.
2b2c2a705ed12f8fb327c7b4c56456c6?d=identicon&s=25 Sean Hussey (seanhussey)
on 2006-06-12 23:14
(Received via mailing list)
Wow, I didn't expect this response.  Excellent!

Thanks for correcting me on some points.  A lot of what we didn't like
really comes down to preference, but, from your response, I'm seeing
that a lot of what we may have had misconceptions about is simply not
documented.

On 6/12/06, Larry E. Masters <phpnut@gmail.com> wrote:
> I choose not to include any code outside of the project in the releases.

Understood.  I prefer it to be included.  Less barrier to entry.  I
like downloading one package and then running with it.

Which actually brings up another point I didn't address before.  I
REALLY like how Rails comes with a server and is just ready to go.
Having not worked with PHP very much in the past 2 years, I wasn't up
on my Apache configs for getting PHP running.  For big-time PHP
developers, it's likely not a big deal.  They do it all the time.  But
for someone new to this (or coming back to this), I found it difficult
and wondered why I was wasting so much time trying to decipher the
docs just to get things running.

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

An example of the docs not being up to snuff:

http://manual.cakephp.org/chapter/17

This link is listed as "View Caching" in the manual.  I didn't see
anything specific (at the time--this was early last week) about any
other type of caching.

> Although a separate project on cakeforge.org it is available.
> Cake Migrations:
> http://cakeforge.org/snippet/detail.php?type=packa...

Good, but, again, barrier to entry.

> > Environments: No real separation of environments (prod/dev/test) in
> > CakePHP.
>
> Not correct:
> app/config/core.php
> app/config/database.php

I saw those, but didn't see any documentation.  I don't think it's
clearly spelled out.  Nothing about the advantages of doing this.
Again, Rails comes with 3 environments already set up, so you've got a
bit of a guide-book to get going.  Also, maybe I'm being picky.  :)

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

Sorry, I should have been more clear.  The relationships and
associations are there, yes.  It's the added join model (as opposed to
a join table) that we didn't see.

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

Excellent to know.  It's obvious that there is a growing community
around CakePHP, which can only be good for development and
competition.

> 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

Again, the barrier to entry.  Maybe I'm biased or spoiled, but now
that I feel like I'm developing in a more agile way, these things are
required, not just nice to have.  If I have to constantly download
extra pieces (Ajax, migrations, test suite, etc), well, it's a real
turn off.  But if your users don't mind, then it's obviously not a big
deal.

> 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

Agreed.  The right tool for the job.

The documentation is really what killed me.  I think a lot of people
coming to RoR from straight web programming realize they have to learn
a lot about Ruby as well as MVC.  The PHP developers I've spoken with
(by NO means a representative sample) have felt like, well, they know
PHP, and this MVC thing is all the rage, so it's a no-brainer to paste
old code into the framework.

Having full documentation for the framework to show people how it's
used and why it's better to use MVC than whatever they're currently
doing is going to be huge for you.

Even having said that, from what I've seen, CakePHP is the easiest to
use of the PHP frameworks (no, I didn't look at all of them).  So
you've got something good going there.

I think if you pushed TDD onto people, or at least led by example,
you'd have more tests in the framework, which could then help generate
some rudimentary documentation you're lacking.

> Anyway hope these corrections help.

They certainly do!  Thanks very much!

Sean
A2b2f4ee23989dc68529baef9cbddcd6?d=identicon&s=25 Julian 'Julik' Tarkhanov (Guest)
on 2006-06-12 23:20
(Received via mailing list)
On 11-jun-2006, at 15:48, Ross Riley wrote:

> Ruby

+2

--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl
A2b2f4ee23989dc68529baef9cbddcd6?d=identicon&s=25 Julian 'Julik' Tarkhanov (Guest)
on 2006-06-13 00:15
(Received via mailing list)
On 11-jun-2006, at 18:23, Sascha Ebach wrote:
>
> Choose the right tool for the job.

Yes. But I know that

a) I don't want to make distributable web apps in the near future
b) I don't want to make ANY use of PHP as a language, because after
Ruby it just feels like a big blob o' functions.
--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matthew Palmer (Guest)
on 2006-06-13 01:25
(Received via mailing list)
On Mon, Jun 12, 2006 at 10:22:40AM -0700, Tom Mornini wrote:
> >>
> >>Like what? And what can Ruby do that php can't?
> >
> >PHP && !Ruby:
> >
> >1) Simple templating (<?php include 'header.html' ?>)
>
> Just out of curiosity how is that different than:
>
> <%= render :partial => 'header' %>

That's not part of standard Ruby.  Note the two items being compared.

- Matt
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-06-13 01:35
(Received via mailing list)
On Jun 12, 2006, at 2:49 PM, Matthew Palmer wrote:

>>>>> Rails.
>
> That's not part of standard Ruby.  Note the two items being compared.
>
> - Matt
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails


def include(path)
   eval(File.read(path))
end

<%= include "../foo.rb" %>


-Ezra_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matthew Palmer (Guest)
on 2006-06-13 05:36
(Received via mailing list)
On Mon, Jun 12, 2006 at 04:33:05PM -0700, Ezra Zygmuntowicz wrote:
> >>>>>There
> >>Just out of curiosity how is that different than:
> >>
> >><%= render :partial => 'header' %>
> >
> >That's not part of standard Ruby.  Note the two items being compared.
>
> def include(path)
>   eval(File.read(path))
> end
>
> <%= include "../foo.rb" %>

<slaps forehead>  I'm *so* not explaining myself properly here.

To get to the point of being able to use <%=, there's a bunch of other
stuff
that you need to do -- it's not *nearly* as simple as "apt-get install
libapache2-mod-php4" and then naming your files as foo.php.  That is,
erb-style escaping isn't inherent to the language, it's an extra thing
with
extra work needed.

Also, I don't think your include() method works quite the same way as
PHP's
include()...

- Matt
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2006-06-13 13:59
(Received via mailing list)
Matthew Palmer wrote:
>>>>> On Mon, Jun 12, 2006 at 12:23:35AM +0200, Pål Bergström wrote:
>>>>>> Like what? And what can Ruby do that php can't?
>>>
> that you need to do -- it's not *nearly* as simple as "apt-get install
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>

Either way, this has become just a Ruby vs PHP discussion, which is
getting off topic, but along that line, I will (if I have a choice)
never again touch PHP. It's the definition of a language gone wrong, and
when I'm using it anything I've ever made, no matter how hard I try,
always feels convoluted and also a hack. Ruby on the other hand has been
solidly designed from Day 1 to be a full pure OO programming language
with tons of niftly little features and completely dynamic.

CakePHP is probably a really good framework for those who love PHP. It's
modeled after Rails, but from what I've seen it's missing the one
feature that really makes Rails: code generation. CakePHP looks to get
back into the 'configuration over convention', which will probably be a
severe stumbling point for those deciding between CakePHP and Rails.
Also, the metalanguage capabilities of Ruby make classes a good bit
cleaner than Cake's way of redefining methods for stuff like 'has_many'.

Oh yeah, and `ruby script/server`.

Jason
D93cd9db8f2e3cdc03f985fc4bc8e31b?d=identicon&s=25 Larry E. Masters (Guest)
on 2006-06-13 16:52
Jason Roelofs wrote:

>
> CakePHP is probably a really good framework for those who love PHP. It's
> modeled after Rails, but from what I've seen it's missing the one
> feature that really makes Rails: code generation...
>

No sound and my first attempt at using a video capture tool:
http://www.archive.org/download/CakePHP_Buildingth...
This shows code generation using scripts/bake.php

>
> ...CakePHP looks to get back into the 'configuration over convention', which
> will probably be a severe stumbling point for those deciding between CakePHP
> and Rails.

I disagree on this, CakePHP has little, if any, configuration.
Upload it and it works.

Few articles:
http://www.h3rald.com/articles/view/rails-inspired...
http://hades.phparch.com/ceres/public/article/inde...
http://blog.usweb.com/archives/phps-answer-to-ruby...

Larry E. Masters aka PhpNut
40db9e75b3f5899258e3bdc0c9210154?d=identicon&s=25 Conrad Taylor (Guest)
on 2006-06-13 19:40
(Received via mailing list)
Hi, I would like to see this thread moved to another list being that
this
should be a list about Ruby and/or Rails.

Thank you,

-Conrad
Dce90ceb553a872aa5c621c363c5ff57?d=identicon&s=25 Bosko Milekic (Guest)
on 2006-06-13 21:41
(Received via mailing list)
On 6/11/06, Benjamin Arai <me@benjaminarai.com> wrote:
> >From a development standpoint, what are the features that make Ruby on
> Rails a better choice compared to CakePHP?

Sorry for the late reply.  The other day when I saw this post I
contemplated typing up a long reply, since I just came out of a
painful project involving CakePHP, but I was too tired (and frustrated
of even seeing the word "CakePHP") to comment.

For the aforementionned project, CakePHP was tried because the client
explicitly insisted on PHP (something about having in-house PHP
programmers, or that they were easier to come by -- a pretty terrible
argument to begin with, considering that just learning the CakePHP
framework is probably more difficult for the average "PHP programmer"
than it is for a solid programmer to pick up on Ruby and Rails).

CakePHP tries very hard to be like Rails, but ultimately, it fails.
It fails primarily because PHP is not Ruby.  There are millions of
reasons why Ruby and Rails fit better than PHP and CakePHP, but to
make a long story short: we spent God-only-knows how many hours just
hacking away at the innards of the CakePHP framework to make it behave
how we wanted it to.  CakePHP's "models" are really not the same as
Rails' ActiveRecord, and we found ourselves unfortunately adopting
static (procedural) APIs for a lot of the model functionality (you
don't pass model instances around in CakePHP, but multi-dimensional
arrays).

Working with CakePHP, we also missed gems and plugins.  A lot.

It's funny that after we completed (it's actually still in
pre-deployment) our CakePHP project, we found that we ended up
hackishly implementing a lot of the cool stuff that now ships with
latest Rails (most notably acts_as_tree and similar).

Anyway, don't take my (or anyone else's) word for it: try both, give
it a week or two, and you'll immediately see the difference.
B52ff204083819631e2083f70483c5f4?d=identicon&s=25 diyana (Guest)
on 2007-01-23 05:36
i have questions regarding to the two frameworks..for your information,
i'd assigned to develop e-portfolio system within 6 month..and i have to
decide either Ruby-on-rails or cakephp...i never use ruby b4 and i don't
know how ruby works..i try to install ruby..but i can't install
gem..seems my computer didn't reconize gem..is it relevant for me to use
ROR or just use cakephp?is it possible to learn ruby in short time?
70ca58d0e0e0eabbdb74d177417d09d7?d=identicon&s=25 augustlilleaas@gmail.com (Guest)
on 2007-01-23 05:51
(Received via mailing list)
Do yourself a favor and say goodbye to PHP and hello to Ruby. You won't
regret it.
Cdfe3f57e076d7a31882de91fd95eb19?d=identicon&s=25 james_027 (Guest)
on 2007-01-23 06:05
(Received via mailing list)
Try to read "Agile Web development with ruby on rails" You'll learn it
in just two or three days!
2d0d904abb31102b049ad60e47c7af8e?d=identicon&s=25 Bart Gajderowicz (bart)
on 2007-01-23 06:44
(Received via mailing list)
I second James' suggestion.
There's plenty of online Rails Tutorials (here are the top 12), but get
the 2nd edition of "Agile Web Dev with RoR" if you can... it's well
worth the money.
http://www.digitalmediaminute.com/article/1816/top...

The Ruby book 1st edition is online....
http://www.ruby-doc.org/docs/ProgrammingRuby/

Bart
C143acf82f94860ef6e2cba52b2de831?d=identicon&s=25 gmacgregor (Guest)
on 2007-01-23 07:20
(Received via mailing list)
If you're a Ruby newby (like me!) then before digging into Rails I
think it would be a good idea to take a look at David Black's
outstanding Ruby for Rails:

http://www.manning.com/black/

It's really great for helping you come to grips with Ruby as a language
and how you can use it with Rails, the framework. I started reading it
about a month ago and now I can actually read and understand what's
going on in (some of) the Rails source code. Highly recommended...
Cdfe3f57e076d7a31882de91fd95eb19?d=identicon&s=25 james_027 (Guest)
on 2007-01-23 07:33
(Received via mailing list)
hi gmacgregor,

I am also a newby, I'll take a look at your recommendation. Have you
try Agile Development with ROR? It is also great even for a ruby newby
like me. How do you compare the two books?

james
Ef0db53920b243d6758c2f6b1306df0d?d=identicon&s=25 Steve Ross (cwd)
on 2007-01-23 07:50
(Received via mailing list)
From a development standpoint, some of the differentiating features are:

+ Rails Community is excellent and can answer any questions that come
their
way.
+ Ruby. It is a language built around solid object-oriented design,
whereas
PHP has OO features bolted on. Even though PHP5 significantly changed
the
underpinnings of the interpreter, it still feels clunky compared to
Ruby.
+ Rails. The framework itself is at 1.2 and moving quickly toward 2.0.
Cake
is nowhere near a stable 1.0 release.
+ Testing. The Ruby community embraced test-driven development and Rails
has
it baked right in. PHPUnit is no match for Test::Unit (IMO), and tools
like
ZenTest or rSpec are incredible for improving the quality of your
applications.
+ Publications/Events. There are plenty of PHP events and plenty of PHP
books, but I don't think you'll find a Cake event that parallels
RailsConf.
There are now a number of great books about developing Rails apps, many
of
which have been mentioned here. I'm not aware of so rich a set of
learning
materials for Cake.

- Rails apps are harder to deploy on budget shared hosts.
- Server resources. PHP is hardly a zero-hit on the server, but because
mod_php is often loaded in shared Apache environments, people take it
for
granted.
- No IDE. If you are looking for an IDE-driven development, Rails might
not
be for you. Cake probably isn't either, but you could conceivably use
the
Zend IDE.

I built one app using Cake to bench test it against Rails, and
PHPonTrax. I
truly regret the decision to follow through with that. I've since
rewritten
in in Rails, spending 1/4 the time and adding features along the way.

If you're up for learning Ruby and want to use a sound MVC framework,
Rails
is a very productive one. My opinion is that Cake is not where it needs
to
be. Further, I do not believe PHP is a language conducive to the next
generation of Web applications.

Just my .02 (USD)



Benjamin Arai-3 wrote:
>
>

--
View this message in context:
http://www.nabble.com/Ruby-on-Rails-and-CakePHP-Co...
Sent from the RubyOnRails Users mailing list archive at Nabble.com.
B0c3ad15fd2a22839ddd4baa61bf7cc6?d=identicon&s=25 James P. Tobin (Guest)
on 2007-01-23 07:52
(Received via mailing list)
James,

I don't think order is important, but you need both books and probably
more!  I went through the Agile book first, and that got you up and
running so you felt you too could be successful, but since Ruby was new
to me, I could *read* the language but *writing* my own code was only a
subset of what I had experienced in the book.  So Ruby for Rails filled
in a lot of gaps, explained things differently which gave added insight
and so on.  So now I'm working through Apress' "Beginning Ruby on Rails
for E-Commerce" by Hellsten and Laine and it's adding even more to my
knowledge.

The next really good book would probably be a dialog between all these
authors, talking through their similar projects and exploring the
differences in their approaches and uses of the Rails framework and Ruby
constructs!

Jim
C143acf82f94860ef6e2cba52b2de831?d=identicon&s=25 gmacgregor (Guest)
on 2007-01-23 18:16
(Received via mailing list)
james_027 wrote:
> I am also a newby, I'll take a look at your recommendation. Have you
> try Agile Development with ROR? It is also great even for a ruby newby
> like me. How do you compare the two books?

The Agile book throws you right into Rails and gets you going. It's
good because you're doing something (building the depot application)
and the "magic" of Rails is thoroughly explained. However, I didn't
really get some of the basic concepts because I didn't know a thing
about Ruby -- which is of course key since it's the language behind the
framework!
76bfee9a29ba38085a8d4cb36cc05b71?d=identicon&s=25 unknown (Guest)
on 2007-01-23 19:18
(Received via mailing list)
diyana wrote:
> i have questions regarding to the two frameworks..for your information,
> i'd assigned to develop e-portfolio system within 6 month..and i have to
> decide either Ruby-on-rails or cakephp...i never use ruby b4 and i don't
> know how ruby works..i try to install ruby..but i can't install
> gem..seems my computer didn't reconize gem..is it relevant for me to use
> ROR or just use cakephp?is it possible to learn ruby in short time?

6 months is an eternity.  No need to buy books right away.

First invest some time in Ruby.  Here are some Nuby gaps filled in:

Gap 0) Interpreter environment.  Install Ruby.  Run fxri (Instant Ruby
Enlightenment docs+IRB).  Install RDE (F5 eval,  syntax highlight,
save files).   Start with texts Poignant Guide
http://poignantguide.net/ruby/ and Learning Ruby (next to the doc
bundle).

Gap 1) ...uh this post is taking too long

Classes are mixins.  You can add a method to say,  File class.  See
Kernel method for y method (yaml.rb).
Why Ruby?  That's cumulative effect.
File class is documented in the UPPER MIDDLE scrolling list of the
standard web docs.
You get access to functions by using "require" effectively.

Ah yes,  found my list,  saved the best Nuby Gap for last:

There are 5 Var_dump()s in Ruby:

p
pp
y
to_yaml
inspect

HTH,
-r
Af31e731dc3f44620a7874d9602e5bc8?d=identicon&s=25 Evan (Guest)
on 2007-01-23 21:13
(Received via mailing list)
I'm also using CakePHP and deployed some Cake-based projects, although
now I'm using Rails on most of my web projects.  CakePHP is largely
based on Ruby on Rails, so I don't think you'd have any trouble with
the structure of the framework.  There's the models, views,
controllers, helpers, and routing in both (scrap the concept of
components in CakePHP, as it's a hindrance when using Rails).  You
might have a bit of trouble though when it comes to differentiating
between  the concepts of the model class in CakePHP and Rails.  In
Cake, the model class acts more as a utility class than an actual model
class (your model data is returned as an array of values), while in
Ruby, it's the model AND utility class (your model data is the
instantiated model class).

As for the language, once you've grasped the structure, you'd have
little trouble in coding in Ruby, and if ever you run into trouble,
just google your problem coz' there's tons of information, tutorials,
q&a's and the whole shebang around the Rails worldwide community.  Or
get yourself a copy of Programming Ruby and Agile Web Development with
Rails (you can get the book, but there's tons of CHM and PDF copies
floating around), and of course the Rails API
(http://delynnberry.com/projects/rails-chm-documentation/).  These are
the three most important resources for Ruby on Rails, although at some
point you would find that the Rails API is worth more than Agile Web
Development with Rails book.

Six months is too long.  If you're persistent, you could learn the Ruby
language structure in less than a week (I'd say 2-3 days, maybe 1 will
do).  And in another week, you'd know how to create your Rails app.
Give it more time, and you could delve into the wonderful world of
Rails unit testing (yes, it's built-in, unlike in Cake, and the same
goes for the mailer), plugins, rake, Capistrano deployment, Ruby
metaprogramming and more.  In less than a month, you have an app ready
for deployment.

Ruby is a great language, and Rails a great framework.  So good luck
with the learning process.  It ain't that hard.
B52ff204083819631e2083f70483c5f4?d=identicon&s=25 diyana (Guest)
on 2007-01-30 03:50
THANKS GUYS FOR UR SUGGESTION..AND ROR IS ABSOLUTELY GOOD..
FEEL FREE TO ANSWER MY SURVEY.. THANK YOU VERY MUCH FOR YOUR
COOPERATION..
http://FreeOnlineSurveys.com/rendersurvey.asp?sid=...
D0b0d51eb3f7b6ed84ae8428895bd3d2?d=identicon&s=25 mike (Guest)
on 2007-01-31 23:07
Excellent discussion, and I'm glad to see it continue.

I highly recommend the "Agile" book, which I've been devouring over the
past few days. The example they use for discussion is developing an
ecommerce site -- and as someone who has PHP-coded from scratch and
manages just such a beast (much more elaborate than the example), I can
see with every page how Rails would make my job a lot easier, a lot
quicker, and a whole lot better to maintain and enhance.

I briefly considered CakePHP, mainly because I was concerned about Rails
deployment issues: How well does it actually run on a production server?
(We rent a Linux box at a hosting farm.) Do I have to scrap Apache to
make it work? (Talk about barriers...)

Happily, the Agile book has an excellent discussion about running Rails
using Apache and mod_proxy, which satisfied my concerns. I may still
look into Cake for PHP-only jobs, but where I have the option I'm going
with Rails.
Aad37b5f7116c8d1f547d23b37566032?d=identicon&s=25 Greg Donald (destiney)
on 2007-01-31 23:49
(Received via mailing list)
On 1/31/07, mike <rails-mailing-list@andreas-s.net> wrote:
> I highly recommend the "Agile" book, which I've been devouring over the
> past few days.

I'm only a few days away from finishing 2nd edition myself.

> The example they use for discussion is developing an
> ecommerce site -- and as someone who has PHP-coded from scratch and
> manages just such a beast (much more elaborate than the example), I can
> see with every page how Rails would make my job a lot easier, a lot
> quicker, and a whole lot better to maintain and enhance.

That's what I tell my PHP/Perl-loving peers.  "Just read the book.. at
the end you'll get a good head start on a nice shopping cart."

> I briefly considered CakePHP, mainly because I was concerned about Rails
> deployment issues: How well does it actually run on a production server?

Same as most PHP apps I suspect.

> (We rent a Linux box at a hosting farm.) Do I have to scrap Apache to
> make it work? (Talk about barriers...)

No.  You can proxy through Apache to your mongrel or lighttpd instance.

http://destiney.com/blog/lighttpd-proxied-under-ap...

> Happily, the Agile book has an excellent discussion about running Rails
> using Apache and mod_proxy, which satisfied my concerns. I may still
> look into Cake for PHP-only jobs, but where I have the option I'm going
> with Rails.

Cake seems nicely written but last time I gave it a little of my time
it felt incomplete.. it didn't have nearly the js integration compared
to that of Rails.  Anyone can toss 3 folders at you and tell you to
split up your logic and code MVC style.

For me I hate writing js.  I hate debugging js.  I hate helping
clients understand why my js doesn't work in their ancient browser on
their ancient OS that is full of malware and virii.  Half of what I
love about Rails is getting all this cool js stuff for free.  Writing
Ruby that writes js just feels good.

Another PHP thingy I'm sorta watching a bit is the Zend Framework.
It's very heavy on the OO-ness, and I'd expect nothing less from Zend,
but it has no js integration I could find.  Rumor has it IBM is
supposed to be committing a bunch of js stuff to the code base soon,
but Rails is already here and works great.

PHP is great, and I can easily see myself using it for years to come,
but I don't do much with it outside of the office anymore.  All my
hobbie coding time is spent with Rails.


--
Greg Donald
http://destiney.com/
18d3c84ca5a017fe3e96490afaea28aa?d=identicon&s=25 Richard Conroy (Guest)
on 2007-02-01 10:40
(Received via mailing list)
On 1/31/07, Greg Donald <gdonald@gmail.com> wrote:
>
> On 1/31/07, mike <rails-mailing-list@andreas-s.net> wrote:
> > I highly recommend the "Agile" book, which I've been devouring over the
> > past few days.
>
> I'm only a few days away from finishing 2nd edition myself.

I have only just started, don't spoil the ending!
41a468b84ccc874470685a8f920919d4?d=identicon&s=25 Nate Klaiber (Guest)
on 2007-02-07 18:15
> For me I hate writing js.  I hate debugging js.  I hate helping
> clients understand why my js doesn't work in their ancient browser on
> their ancient OS that is full of malware and virii.  Half of what I
> love about Rails is getting all this cool js stuff for free.  Writing
> Ruby that writes js just feels good.

I would only question that in, though I really like RoR - I absolutely
despise the inline JS that is used (though I know there is a plugin to
make it unobtrusive). It's not free - you still need to know what you
are doing, though.
This topic is locked and can not be replied to.