More good nuggets from ruby.mn.... Jonathan Dahl writes:
One point that I didn't notice in your email: configuration vs.
convention. Rails makes a conscious choice to support convention
over configuration, and this is a major part of the Rails "flavor".
There are no XML configuration files in Rails.
True. One of the important features of Tapestry 4 is that you can
have very little config -- but in Rails, there's *none*. As usual:
simplicity at the expense of certain potential robustness. Rails has
a very consistent design philosophy!
And also:
Ruby probably has a lower "minimum app complexity," and Tapestry
probably has a much higher "maximum app complexity," but both are
worthwhile, and for many tasks, both are good options.
There is some truth to this. Rails is built for small teams or solo
developers (previously the realm of php, perl, etc.), while
Tapestry is built for larger teams. But Rails is unique because it
erodes the "large team" ground a little; individuals and smaller
teams can do things that would have previously required a dozen or
two programmers.
On Mar 7, 2006, at 1:26 PM, Paul Cantrell wrote:
Tom Brice of ruby.mn informs me that Ruby's default "ERB"
templating approach, in which the templates are fully executable
code, is not the only approach:
Rails does not have to use the erb templates. There are options
they are just not shipped with rails try these links:
http://redhanded.hobix.com/inspect/markabyForRails.html
http://home.leetsoft.com/liquid There have been reports of using
Builder (http://rubyforge.org/projects/builder/) as the template
language. So there are a few options.
"Liquid" in particular looks like it's more similar to Tapestry
than ERB.
He also shared some good links on comparing Hibernate or a
Hibernate-like approach to a Rails:
I just wanted to add a few links I have found regarding specific
tradeoff between Rails ORM (activerecord) and the popular Java ORM
Hibernate (which is basically the data mapper pattern, as I
understand it):
http://www.martinfowler.com/eaaCatalog/activeRecord.html
http://www.martinfowler.com/eaaCatalog/dataMapper.html
http://www.loudthinking.com/arc/000209.html
http://www.theserverside.com/articles/article.tss?l=RailsHibernate
The recurring theme is "Ruby aims for simplicity and rapid
development at the expense of some robustness."
Cheers, P
On Mar 7, 2006, at 10:25 AM, Paul Cantrell wrote:
Interesting discussion, but I don't think anybody has hit on the
really important stuff yet. Those more knowledgable can correct me
if I'm wrong:
*** Rails is based on a dynamically typed language (Ruby),
Tapestry on a statically typed one (Java) with a dynamically typed
template language (OGNL).
That means that the two frameworks come with the tradeoffs of
dynamic vs. static types: Ruby code can be more concise, and can
pull more simplifying tricks by having, for example, all your
page's fields appear "by magic" with no declaration -- but that
comes at the expense of being able to catch many errors at compile
time, have your IDE do autocompletion of available methods, and
generally having the clarity of seeing during development exactly
what members are available to you and what their type is.
It's a big question, but in Rails vs. Tapestry, it we can sum it
up with the fact that in Tapestry you have to do this:
public abstract String getAddressLine1();
public abstract void setAddressLine1(String value);
...and in Rails you don't. If that feels like a burden, you'll
like Rails. If it feels like useful structure, you'll like
Tapestry. Both certainly have their place in the world.
*** Tapestry has a page template language that separates code from
pages; Rails uses the internal language as its template language.
Rails advantage: you have the full expressiveness of Ruby in your
page templates; no more wrangling with the bazillion parameters of
"@For".
Tapestry advantage: you have a clean separation between formatting
and view logic, and you can (fairly) safely hand pages over to
designers without worry.
*** Rails extends from the view down to the database; Tapestry
keeps its hands off the DB and deals only with view.
...and closely related:
*** Rails ties the database structure very closely to your object
structure, so your database tables look a lot like objects.
The Rails advantage here is that you can just model out your
objects and let the database take care of itself, with very
minimal worrying about tables. That ceases being an advantage,
however, if you're (1) integrating with legacy databases or
sharing the DB with other apps, or (2) your DB is large or complex
enough that fine-grained schema control is important. Then Rails'
lack of robust O/R mapping really starts to hurt.
Tapestry doesn't even get its hands in the DB, so you're free to
use Hibernate or Cayanne or raw JDBC or whatever you like.
Hibernate is a standard choice. Like Rails, it can autogenerate
your schema if you like, but it can also adapt to explicitly
designed schemas much better. Unlike Rails, it requires some extra
configuration.
I personally like the fine-grained control over how my tables are
named and indexed, what foreign keys are created, etc. Rails
doesn't choose good names for tables, doesn't handle foreign keys
well, etc. On the other hand, if you want something running fast,
Rails' lack of flexibility in this area also means lack of up-
front configuration cost!
*** Ruby doesn't have anything like the broad set of libraries
that exist in Java.
That will gradually change over time, to be sure. But when people
talk about Rails not being "enterprise ready," this is part of
what they mean -- you can find a library for just about anything
under the sun in Java (pun intended) ... but try finding
integration for your smart card reader in Ruby.
No reason to think it will always be this way!
*** Rails has a very strict memory-exists-only-during-a-request
view of the world.
This is because Rails uses CGI. If you want anything to live
across requests, you need to store it in on disk (how Rails
handles sessions) or communicate with a different process or
something. The performance tradeoffs are obvious: no load-once
behavior, no in-memory caching, no background threads, the whole
module has to fire itself up and parse your pages on every
request ... but your app is automatically clusterable if you keep
your hands off the disk, and you don't run into these "oops, I put
it in a static variable and didn't synchronize it right" sorts of
problems.
*** To my knowledge, Rails doesn't really have anything to compare
with Tapestry's excellent component framework, or to Hivemind.
(But I may just be ignorant.)
*** One uses Ruby, one uses Java.
This is largely a religious one, but it's important to many
people. Some people love functional languages or have blamed Java
for all their problems, and thus swear by Ruby and loathe Java.
Some people are terrified of the unfamiliar and won't touch Ruby
with a ten foot pole. I personally think they're both great
languages. (I really do! Many Java APIs, e.g. EJB 2.0, are
terrible and responsible for much suffering, but the Java language
itself is a beautiful thing. And Ruby is cool and fun and
promising.) But Rails / Tapestry debates are likely to turn into
religious Java / Ruby debates....
The bottom line is they're both exciting and interesting
frameworks. Ruby probably has a lower "minimum app complexity,"
and Tapestry probably has a much higher "maximum app complexity,"
but both are worthwhile, and for many tasks, both are good
options. What I think Rails really supercedes is PHP: I have
trouble imagining a DB-driven app where using PHP is a better idea
than using Rails.
Hope that's helpful. I also hope it's correct, because really I
don't know Rails all that well -- I've only talked about it a lot.
Maybe I'll run this by the Ruby Users of Minnesota and let them
correct me.
Cheers,
Paul
On Mar 6, 2006, at 3:19 PM, Edward Scanzano wrote:
Hi All,
I got the question today...What is the difference between
Tapestry and Ruby (on Rails). I want some good reasons as to why
Tapestry is a superior choice. Please feel free to comment.
Thanks
E
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: tapestry-user-
[EMAIL PROTECTED]
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
