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: [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]
