Re: [ANN] Introducing Waves - Web App Framework

>> just like rails, except done in a slightly different way, different
>> conventions, etc. So let me ask the (possible rude) question that
>> matters most:
>>
>> Why should I use this instead of rails?

It's not a rude question at all and you're not the first person to  
ask, just the first to ask on the ML. Apparently, I am not  
communicating this as well as I'd hoped on the Web site. :( I am  
going to have to work on that; I appreciate the feedback.

> Or Merb?

Some of what follows is covered at http://rubywaves.com/features but  
I will try to summarize here some of the key differences.

Waves is thread-safe (like Merb, but unlike Rails); it is DB-agnostic  
(like Merb) but comes prepackaged to support Sequel (which is also  
multi-threaded and can convert Ruby expressions into SQL queries).

Waves request mapping ("routing") is very different from either Merb  
or Rails. It is much more flexible and you can avoid MVC overhead  
when you don't need it because requests are mapped into blocks, not  
preset parameters.

Filters are also handled in the mapping, so you can lock down all  
your controllers from your mapping configuration. You don't have to  
worry about a secure method accidentally being exposed by a wayward  
controller.

Example:

# make sure users are logged in before allowing them access to URLs
# beginning with '/admin
before %r{^/admin/} do { redirect('/login') unless session[:user] }

Common patterns can also be packaged into modules for reuse, as is  
done with the built-in "PrettyUrl" rule sets. I expect to provide  
more of these (hopefully through contributors as well as my own  
efforts) in the future.

Waves implements something I am calling "just in time resources"  
which are MVC classes that are created on-demand based on exemplars.  
Thus, you often don't need to explicitly implement a model or  
controller class if it follows a well-known problem. Because  
controllers are simpler in Waves (they simply return a data object of  
some kind, essentially adapting requests to models) they tend to be  
easier to reuse.

Views are also very different. For example, layouts are set in view  
templates (where I feel they really belong, since they are part of  
the view), not in the controller, like this:

layout :default, :title => @person.full_name do
   ...
end

You can also call views directly from within other views (sort of  
like partials, but there is no real distinction between a view and a  
nested view in Waves). Waves views are primarily based around  
Markaby, allowing for pure Ruby templates, although any rendering  
engine can be easily integrated.

Waves also is hot-patchable because it supports true code-reloading  
(unloading and then loading, as opposed to just loading a second  
time, which can leave stray constants and values from prior loads).

Waves is designed to support multiple applications. Each application  
lives inside its own module, so they are completely separated. This  
makes it easy to reuse entire applications (although only one  
"master" application can provide the mappings and configuration).

Finally, Waves may look on the surface somewhat similar, but beneath  
the covers, almost every aspect of Waves is designed to be extended.  
Even the dispatcher can be extended or replaced entirely.

There's more, but hopefully, that helps a bit. I will try to spell  
this out a bit better on the Web site. Thanks for the feedback!

Regards,
Dan