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 NameBright - Coming Soon 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
