Improving MonoRail

Question

We know it's lacking documentation but what other parts would you like to see improved?

Answer 1

The problem with answering that is, how do I know if monorail actually lacks a feature, or if, due to poor documentation, I merely don't know about it.

For example, I'm not really in love with it's routing engine, but I think it will actually do what I want, if I could figure out the correct syntax.

Answer 2

Let me start off by saying we're not using the most recent version of Monorail, so this suggestion may be moot.

Imagine two controllers: BaseController and DerivedController (which is derived from BaseController).

If both controllers have rescues defined for them, I'd like rescues to work in an intuitive way.

If BaseController has rescues for:

• AException
• BException

and DerivedController has rescues for:

• AException
• CException

then:

• An AException thrown from a BaseController should use the rescue defined for AExceptions in BaseController.
• An AException thrown from a DerivedController should use the rescue defined AExceptions in DerivedController (because the DerivedController has overriden BaseController's rescue).

Answer 3

Maybe it's already there and I just haven't noticed, but I find Django's admin interface very useful during development. It would be nice to have something like that for MonoRail.

A new stable release would also be nice, I constantly waffle back and forth on whether I should be using the release or trunk.

Answer 4

I could really use some clarity on the future roadmap for the project. We are using for a bunch of sites but it is hard to tell when the project will move from Rc3 (even roughly when).

Also it is unclear about the dependencies for the trunk -- is NHibernate 2.0 really a requirement. And when does that release (or has it).

Answer 5

I think if you're looking at MonoRail compared to ASP.NET MVC then the first thing you'd say is missing is good documentation, so I think that does have to be stressed. However, since you'd said specifically about what else, I'd say that the next thing is tools to generate controllers with a list of actions, etc, much like Ruby on Rails does. I don't know if there's something similar, but I'd also suggest looking at Rail's migrations and seeing whether there's anything there that you'd want to adopt. For me, while I probably prefer using one consistent language rather than multiple domain specific languages for specific pieces like that, migration from multiple older versions to the current one can be a pain, and I've rarely worked somewhere that people have managed to adequately maintain migration scripts themselves. While ActiveRecord can configure a database schema itself, that potentially still misses the one of migrations being able to perform a series of alterations, where jumping from an unknown older version to the current one may not invariably give the same result. I'd also suggest that if you're looking for comparisons, probably and even more relevant one is that of generators. It's all very well knowing that you can create a text file with a .VM extension, etc, but if you compare with the likes of Ruby on Rails, then the generators there make it much easier and somewhat quicker to get the desired set of controllers and views set up. Even just a couple of simple generators would do - such as one to generate a project skeleton, and another to generate a controller with one or more actions, complete with views. Also having a scaffold generator would probably complete my 'top 3'.