Aitor Imaz

Not natively. If you're familiar with JasperReports, you can sort of use it by piping the result into Rails, but it's far than ideal because you need to load a JVM everytime you generate a report. It's explained here:

http://wiki.rubyonrails.com/rails/pages/HowtoIntegrateJasperReports

The only Ruby reporting software I'm aware of is Ruport, although I haven't used it so I can't comment on it.

http://www.rubyreports.org/

Ruby IDEs are getting better and better. I particularly like Textmate for Rails development, but it's only available for the Mac. The Eclipse plugin is pretty good too.

However, one feature I greatly miss is Refactoring support, and I mean something more than simple search & replace. It'll probably take some time to get a decent refactoring support for Ruby, given the dynamic nature of the language.

Look for the stdout.log file on the log folder. You should be able to see the console output there.

I think they're quite different. Appfuse is described as "an application for kickstarting webapp development", while Ruby on Rails is a web application framework. Let me explain.

I see Appfuse as a gluecode generator. You configure it, add some metadata and it'll automatically create configuration files, code, etc. to make use of other frameworks like Spring, Hibernate, Struts, iBATIS, etc. Appfuse doesn't provide most of the functionality, it relies on other frameworks to do so.

On the other hand, Rails is a more complete application framework. You build applications that rely on the functionality Rails provides like ActiveRecord (ORM), ActiveSupport (utilities), etc. You need very little configuration in Rails, as long as you follow certain conventions everything will work "magically" at runtime.

I think many people have a mistaken idea of Rails because of one of its features: Scaffolding. Scaffolding is a simple code generator that creates barebones code ("scaffolding") that you develop from. In that respect, it's similar to Appfuse. It's definitely one of the most "visual" features of Rails, the one that is more easily "sellable". That's the feature the article you mention describes.

However, Rails is much more than Scaffolding. I see it as an integrated web development framework. You get ORM, views, utilities, testing, migrations, logging, a server, and much more out of the box, everything is part of a single framework. And a very well designed one! It is developed upon a lot of best practices and approaches. And yet, it's not complex but quite simple in most cases.

Some people even think avoiding Scaffolding (in its current state) is a good idea. For a good presentation on the subject: http://www.slash7.com/presentations/overcoming_scaffolding_addiction.pdf

You might find interesting information on how to use Rails with legacy databases on this article on the Rails Wiki:

http://wiki.rubyonrails.com/rails/pages/HowToUseLegacySchemas

Composite keys are not supported by plain Rails. However, there is a plugin that seems to support them, but I haven't tried it:

http://compositekeys.rubyforge.org/

Hope that helps.

The naming conventions are defaults for the most part. You can override them if you will, although you'll be losing a lot of what Rails gives you in terms of simplicity and productivity.

There are more things that can drive some DBAs nuts, like no composite keys (although I believe there are plugins that can let you use them). So yes, it's better suited for "new" applications.

Personally, I don't see it as a restriction, it's a feature. Rails doesn't claim to be the best tool for *any* job, but it's definitely the best tool for *many* jobs.

Eric, never mind.

Good to hear that you're working on a new book!

Hi,

Let me first thank Eric & Elisabeth for writing such an engaging and entertaining book. I have tried reading the GoF book a few times but never made it from start to finish because I always found it really boring. I've only read the parts I've needed. On the other hand, I read the whole HFDP book in a snap, from the first page to the last, and came to understand many concepts from the GoF book much better. Now I have both of them as a reference

I needed a menu system for a project I'm working on with a tree containing folders and items so I implemented the Composite Iterator pattern as described on pages 354-377 in the book. It was really simple, but I found myself with a problem.

If I execute an operation like the print() used on the example on a composite object, everything works fine. If all I want is to obtain an Iterator of "Menu Components" (in my case, all the folders and items corresponding to the tree) executing createIterator() on the root folder then I get duplicate elements. These duplicate elements show up if the tree has a depth bigger than one level (excluding the root folder). From what I can see, this is because the elements get pushed on the stack more than once.

My question is: is this behaviour by design or a bug in the implementation? If it's by design, is there a way to modify the code to avoid having duplicate elements in the Iterator? I can always look for duplicates in the calling code, but that's undesired in my opinion.

Thanks in advance!
Aitor