Translating RoR framework into the Java environment


#1

For a company study I am trying to come up with what would one need
to replicate grosso modo and at the functional level what we get in
Rails. This does not need to be an “equivalent” solution, just what a
Java programmer would build upon, the canonical aggregation of
components, the usual tools.

My first fraft is:

Struts -> C layer
Hibernate -> M layer
JSP + Tiles -> V layer
Prototype, etc. -> Ajax
Tag libraries -> Helpers
HtmlUnit -> Testing

What for mailing? What for web services?

I think one would need to implement by oneself the environment
separation, the console (I guess one can write something similar with
the BeanShell, Jython, etc., do you agree?), the generators,
scaffolding, SVN integration of utilities.

That was a quick list, anything else?

– fxn


#2

Xavier N. wrote:

For a company study I am trying to come up with what would one need
to replicate grosso modo and at the functional level what we get in
Rails. This does not need to be an “equivalent” solution, just what a
Java programmer would build upon, the canonical aggregation of
components, the usual tools.

My first fraft is:

Struts -> C layer
Hibernate -> M layer
JSP + Tiles -> V layer
Prototype, etc. -> Ajax
Tag libraries -> Helpers
HtmlUnit -> Testing

What for mailing? What for web services?

I think Apache has a thing called Axis for web services. Perhaps
JavaMail for mail ? Velocity is the generic templating engine which
you’d use in place of ERb for the mail, I guess. You’d also want to
look at Cactus in the testing space. And don’t forget renegineering all
the rake tasks and capistrano stuff that you’d get for free with a rails
app.

Alan


#3

Struts -> C layer
What about Tapestry? Personally never tried, but its newer and i read
also at more places that better than Struts.
JSF - JSF has a potential in the long term to kick the other players out
because it is pushed by Sun - like java.util.regexp kicked out the other
(oroMatcher etc) regexp engines, or as Crimson (standard XML parser as
of 1.4) pushed out Xerces etc. So if you are considering a long-term
project, from a management decision POV i would not even write off JSF
totally.
Hibernate -> M layer
Certainly the best
JSP + Tiles -> V layer
Prototype, etc. -> Ajax
Tag libraries -> Helpers
HtmlUnit -> Testing
Seems to be ok…
What for mailing? What for web services?
The standard j2EE stuff is not enough?

That was a quick list, anything else?
Your proposal sounds good as-it-is. However, for a different kind of
approach you may take a look at Rife or Seam…

cheers,
Peter


#4

You could look at EJB 3, this is basically a wrapper around Hibernate
and is
the next stage in the evolution. Use EJB 3, JSF and Seam.

JMS for webservices.

JSF is growing in usage but it is completely component based and very
different compared with the approach taken by rails.

Ola


#5

There is some debate that JSF has the “designed by committee” feel and
is inferior to Tapestry.

Also, for AJAX talking to java servers, the DWR toolkit
(http://getahead.ltd.uk/dwr/) seems to be popular.

There’s a new project called “Grails” that attempts to reproduce the
best ideas from Rails (mostly convention over configuration…) using
Java technologies like Groovy, the Spring Framework, Hibernate, etc.
Might be worth investigating: http://grails.org/ I think there are
other, similar java-based projects have been started, too.

My $0.02.

Dean W.
http://www.aspectprogramming.com
http://www.newaspects.com
http://www.contract4j.org


#6

There is also Trails (https://trails.dev.java.net/).

I personally dropped Tapestry when it was floating between V3 and V4 and
discovered a new java web framework called Click (
http://click.sourceforge.net) that is considerably simpler than Tapestry
(but is still component-based). It also plays nice with Hibernate and
Cayenne (an alternative ORM you might want to look at).

Point is, it’s all disjointed, and all these different ‘layers’ have to
be
integrated together to make them work. Configuration, in other words.

Something else that is a top to bottom fully integrated Java web stack
you
should investigate is WebObjects from Apple.
(http://www.webobjects.com).
The Daddy of them all…

Good luck!
Geoff


#7

There are a ton of Rails clones, basically at least one for every
language out there. I think Python has two or three.

Anyway – this idea here looks like a bit of a misconception:

Struts -> C layer
Hibernate -> M layer
JSP + Tiles -> V layer

These things really aren’t layers. If you have three things on your
desktop, like, a file, an application which uses that file, and a
trashcan, those things aren’t distinct layers. That’s total Java
thinking, Rails doesn’t really have layers at that particular point in
the framework. These things sit at the same level, they’re only useful
because all three of them exist. In the desktop example, you would use
the application to open the file, say it’s a PDF and you just want to
read it and then throw it away, so you need both the app and the trash
can to deal with it, and neither the app nor the trashcan are
meaningful or useful without a PDF to read and then throw away. They
aren’t distinct layers because they all sit at the same level. You
don’t have a PDF layer, an Acrobat Reader layer, and a trashcan layer.
You just have a flat desktop with three things sitting there.

These things might be layers in the J2EE world, but I really think
they aren’t in Rails.

Anyway, sorry for the rant, but I do stand by it. On the whole
question of what the mailing and web services tools are in Rails,
there’s Active Mailer and Active Web Services. I think AWS is actually
somewhat underdeveloped compared to the Java alternatives which
probably exist, but Active Mailer is probably superior, and Rails
itself is certainly (in my opinion) dramatically superior to J2EE as a
whole in a very large number of situations. The thing to really look
at if you’re doing a serious analysis of the comparative usefulness of
Rails vs. J2EE is speed of development and ease of maintenance. Rails
is much, much quicker to develop in, and much, much easier to
maintain, and both these things have very real budgetary implications
for corporate types. To put it simply, Rails will save you a ton of
time and a ton of money. The only real weakness I’m aware of for Rails
is that if you have a very large user base which needs very fast
performance, Java will be faster on the server side once you finally
get it up and running.

As far as HtmlUnit for testing, that’s a bit off also, you’d need
JUnit as well. And I think it’s easy not to grasp the significance of
this comment here:

don’t forget renegineering all
the rake tasks and capistrano stuff that you’d get for free with a rails
app.

This alone could save you a great deal of work, a great deal of time,
and a great deal of money. The migrations facility in Rails is
probably worth an entire DBA’s salary at certain companies.


Giles B.
http://www.gilesgoatboy.org


#8

I’m surprised Grails, http://docs.codehaus.org/display/GROOVY/Grails,
hasn’t been mentioned yet.

Of course, if you want to use Java, you want to be sure the framework(s)
you’re using are both stable and maintained. Grails and Groovy just
might not fit into that category.

Anyway, since webwork has been merged into struts I guess struts is the
way to go. Freemarker for the view (I don’t really like velocity…
another nice templating system is webmacro, though it is old, and not
very actively maintained). For ORM hibernate definately is the easiets
implemention, so not much debate there either.
As my first contact with programming was web-based, perl(!!), ever since
that I’m used to the stateless programming (only the occasional .NET
based support app) and the combination of programminging/designing
(well… you gotto be able to produce workable html). A framework like
JSF just doesn’t offer what I want (read: am used to). More traditional
programmers might prefer it though.


#9

Sorry, didn’t mean it to sound so serious.

On 4/20/06, Xavier N. removed_email_address@domain.invalid wrote:

Anyway, sorry for the rant, but I do stand by it. On the whole
get it up and running.
heavy, much more verbose, lots of configuration files, lack of
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


Giles B.
http://www.gilesgoatboy.org


#10

On Apr 20, 2006, at 18:50, Giles B. wrote:

First of all, calm and peace!!! :slight_smile:

There are a ton of Rails clones, basically at least one for every
language out there. I think Python has two or three.

A Rails clone is a lot of work, Django and Catalyst are the only
framewroks Rails-like to some extent (not clones). Which ton of
clones are you refering to?

Anyway – this idea here looks like a bit of a misconception:

Struts -> C layer
Hibernate -> M layer
JSP + Tiles -> V layer

These things really aren’t layers.

That was clearly a simplification, the introduction paragraph tried
to set the context of this simple table and the rest of the mail.

If you have three things on your
desktop, like, a file, an application which uses that file, and a
trashcan, those things aren’t distinct layers. That’s total Java
thinking, Rails doesn’t really have layers at that particular point in
the framework.

I was using the word layer as in the MVC pattern, which is built-in
in Rails. I don’t understand what do you see strange there, it is
standard terminology.

Anyway, sorry for the rant, but I do stand by it. On the whole
question of what the mailing and web services tools are in Rails,
there’s Active Mailer and Active Web Services.

The question was which mailer and web service solution would you put
on the Java side.

for corporate types. To put it simply, Rails will save you a ton of
time and a ton of money. The only real weakness I’m aware of for Rails
is that if you have a very large user base which needs very fast
performance, Java will be faster on the server side once you finally
get it up and running.

Sorry, I think you were reading a Rails versus Java question. The
original question was “how would you build something grosso modo
functionally similar with Java”, and I stressed it hadn’t to be
equivalent, because I know beforehand it can’t as of today.

That was an exercise in trying to see what aggregation of components
would a Java developer choose to get something similar at the
functional level, grosso modo. This is of course ill-defined, but it
is just an exercise. Obviously the Java aggregation is much more
heavy, much more verbose, lots of configuration files, lack of
integration, tag libraries are not comparable with helpers because
they are a PITA compared to helpers, etc. We already know that in
this list. But we are not comparing the solutions in that sense in
this thread.

– fxn