Superfluo

Yesterday I was talking with my fellow in business about Ruby on Rails and my doubts on its adoptability in designers driven projects (we were just going to meet a bunch of designers ;-) ). So I thought of the question again and understood that my conclusions were partially wrong and I was too hurried in writing them (ah, the desire to post!).

The described problem is real: in such kind of projects there are difficulties to organize the work in a way that:

• maintains the most suitable environment for each involved part,
• facilitates the collaboration and the integration of the work.

A perfect solution doesn't exist and it's necessary to come to compromises, I believe.

I sustained that Ruby on Rails wasn't adapt for managing this operational context, particularly in comparison with the JSP or PHP approaches. This is wrong because, except for the simplest cases, also these last ones are destined to break the normal HTML functioning. It's true that they maintain an environment more similar to what the designer expects to find but this alone is a marginal advantage.
Moreover and above all, independently from the adopted technologies, for preserving the designer-friendly pages navigation, one has to renounce to the MVC pattern and often it isn't worthwhile!

So I'm happy because I'll have less hesitations in using Ruby on Rails even in designers driven projects :-) . This doesn't stop me to look at Nitro because it seems to have a lot of flexibility and that's may be useful in a plenty of situations.