Home

See README.md for more details.

Why was this created?

webmachine-ruby is the best native HTTP speaker in the Ruby server-side pantheon.

However, webmachine-ruby leaves a lot of things to the developer. Chief among these things is the necessity of integrating your own templating engine. For simple cases, this is not hard, but Rails already has ActionView and a few conventions that are useful on this side of the fence.

What are the main differences between ActionView in webmachine-ruby and ActionView in Rails?

Controller actions vs. real resources

In Rails, you have controller actions. This means that your view directory often looks like the (abridged) following:

+--views
  |
  +--customer
    |
    +-- index.html.erb
    +-- show.html.erb 

The "customer" part refers to a Customer model. The "index" and "show" options aren't exactly resources themselves, but map conceptually to a "list of customers" resource and a "customer" resource.

Assuming that you have a CustomerResource and a CustomerListResource in webmachine-ruby with webmachine-actionview, your views directory might instead look like this:

+--views
  |
  +-- customer_list.html.erb
  +-- customer.html.erb 

A lot of Rails-compatible gems rely on much more than ActionView!

Many conveniences we take for granted in the Rails world will be time-consuming to port to this way of doing things. Most gems rely on both ActionView and ActionController, meaning they may do things like:

• Rely on the existence of a params collection (Webmachine separates queries and posted fields)
• Rely on the existence of helpers that are tightly coupled to some part of Rails we are purposely ignoring (like routing or anything associated with an ActionController)

Right now, I have a problem porting Kaminari, which relies on the Rails url_for helper for linking, while I'm using webmachine-linking. If I want Kaminari to integrate, I'll have to write an adapter helper to make Webmachine seem more like Rails. Or think a little harder. One of those.