Kiss A simpler, smarter web application framework for Ruby

Introduction

SECTIONS
What is Kiss? Compared with Rails and Merb Minimal Configuration Fast Enough to Run via CGI Built on Rack and Erubis Sequel ORM Library Smart Forms Easy Organization of Actions Dynamic Action and Model Classes Ready to Dive In?

What is Kiss?

Kiss is a web application framework for the Ruby programming language. Kiss uses elements of the Model-View-Controller (MVC) and Model-View-Presentation (MVP) design patterns, to enable clear separation of business logic (what the app does) and presentation (how the app looks and behaves). Using Kiss, developers can create web applications with greater speed and flexibility, less tedium, and easier maintenance than with other frameworks.

This guide assumes that you are familiar with the Ruby language and have used an MVC web application framework such as Ruby on Rails. However, we provide a brief primer on MVC in the Applications chapter, for those who are new to the concept.

Compared with Rails and Merb

The Kiss name is an acronym for Keep It Smart and Simple.

Generally speaking, we have aimed to make Kiss applications easier to configure, easier to develop, and easier to maintain than applications written for Rails or Merb. Wherever possible, we have chosen to go with simplicity and flexibility over tedious processes and rigid structure. You'll find that many of the required setup steps of Rails and Merb have been simplified or omitted entirely in the Kiss way of doing things. With Kiss, you can focus on building your app, instead of fussing with the framework.

That said, we've also given Kiss some very nifty features to help you be more productive and build complex applications more easily, and with better maintainability. We think you'll be pleased with the balance of simplicity and power that Kiss provides.

Throughout this introduction, we'll highlight some of the ways Kiss is different from Rails and Merb, so you can determine if Kiss might be a better choice for your project.

Minimal Configuration

With Kiss, there's very little configuration needed to get up and running. Kiss provides a scaffold creation tool to start a new project, including sample actions to handle user authentication and login sessions. Kiss applications generally have fewer files and directories than Rails and Merb applications, so the scaffold is pretty simple and easy to work with. You won't have to install and attach your own ORM library and other basic components, as you would with Merb. In fact, you won't have to add much, if anything, besides your application code.

We want to make it easy for you to create new applications and start building them right away, whenever the creative spark hits you.

Fast Enough to Run via CGI

Merb was created with the intention of being faster than Rails, but both have become large frameworks that take a few seconds to initialize and start running. This makes it highly impractical to run Rails or Merb applications via CGI scripts, since CGI applications must initialize from scratch for each request, and this simply takes too long with Rails and Merb.

Kiss was designed to initialize very quickly and to load only the files necessary to handle the request at hand, so it is actually fast enough to load via a CGI script. This allows you to deploy your Kiss applications in shared hosting environments that do not allow persistent app server processes. If your web host allows Ruby CGI scripts but doesn't let you run a Rails app server, Kiss may be just the answer you're looking for.

Built on Rack and Erubis

Kiss is built on the Rack library, so you can also run Kiss applications as persistent app servers using WEBrick, Mongrel, Thin, or other app servers. Kiss loads and caches files as needed to answer different types of requests received, until the entire application is cached, for fast ongoing performance.

We also use the Erubis template engine, which is up to five times faster than the standard ERB library.

Sequel ORM Library

Rails  built on the ActiveRecord ORM, which has been criticized for poor performance, lack of thread safety, and limited functionality. Merb added DataMapper and Sequel as ORM options, but no matter which ORM you choose, Merb requires you to perform the ORM integration manually, which can be tedious and troublesome.

Of these three ORM options, we believe that the Sequel ORM library is the most elegant the and most powerful. Much of the Sequel syntax will be familiar or easily understandable by those familiar with ActiveRecord or DataMapper, and Sequel provides a unmatched level of functionality along with a clean syntax for great code maintainability. It is also thread-safe and delivers high performance for power users.

For these reasons, we have decided to build Kiss on the Sequel ORM, freeing you from having to do the integration work yourself. The tight integration between Kiss and Sequel also provides convenient shortcut methods to access Sequel model data from your actions.

Smart Forms

Kiss is designed to handle complex forms that deal with multiple resources in a single request. For such forms, it makes sense for the validation to be handled at the form (view) level, rather than by the individual models that receive data from the form.

Therefore, Kiss provides a form class that lets you define form field elements, specify validation options for each element, and generate form HTML automatically. You can also association forms with database model objects to populate form fields' default values with object data and to save validated form input back to the models.

Using Kiss's smart forms, you can define all aspects of a form in a single place, rather than have interdependent pieces spread across action code, models, and templates. You'll build forms faster, know that they work the way you'd expect, and be able to expand and maintain them more easily.

The form definition syntax is fairly straightforward, despite all this various functionality. We're hard at work making forms even simpler in the upcoming release of Kiss 1.2.

Easy Organization of Actions

Actions Stored in Separate Files to Organize as You Wish

In Rails and Merb, actions are grouped into "controller" class files, generally based on the type of resource that they act on. As controller classes expand and the number of action methods grow, it becomes harder to find a particular action method to modify it.  This can make improvements, debugging, and other maintenance of the codebase cumbersome over time.

In Kiss, each action gets its own class, stored in its own separate file. Action files may be grouped into directories, to keep related actions together. As your application grows in functionality and complexity, you can easily keep things organized  by nesting action directories, as deeply as you wish.

By the way, in the Kiss vernacular, there is one single "controller," which is in the Kiss framework itself. The controller dispatches requests to your action code, which in turn accesses database models and yields output data to view templates. This interaction is explained in more detail further on in this documentation.

Action Class Hierarchy

Kiss works some magic on your action files, turning each one into a separate anonymous action class. Each actions directory also gets its own class, which becomes the superclass for the action files and nested subdirectories it contains. As you arrange your actions into nested directories, you create a useful and powerful hierarchy of class inheritance, with the ability to add shared class and instance methods at any subclass level. This feature is described in more depth in the Actions chapter.

REST Only If You Want To

Rails and Merb assume that your application will use a Representational State Transfer (REST) architecture, which suggests that each request should perform a single action on a single resource type. The REST architecture can work well for some applications, particularly simple ones such as basic API libraries that fetch or edit object data.

However, the model breaks down for more complex web applications, in which many types of resources may be touched to generate a single page or changed in a single transaction. Some applications are better served by a Remote Procedure Call (RPC) architecture, which lets you name and organize action names however you wish, and puts no restrictions on which or how many resources should be accessed per each request.

Rails and Merb strongly encourage the REST architecture by forcing you to define all the actions your application performs as methods grouped into "controller" files, one controller for each type of resource that your application manipulates. This design makes it difficult to organize nested actions more than one level deep. It also leads to difficult code organization decisions regarding complex actions that deal with multiple resource types, such as what to name them and which controller file to put them in. As some actions change in functionality over time, it can be difficult to move them from one controller to another, and maintainability suffers as a result.

We believe in letting developers choose the best architecture for their applications. That's why Kiss application actions are stored in separate files, which can be nested in any directory structure of your liking. If you want to use the REST architecture, you can group your actions into directories named for each resource type.  If you prefer the freedom of RPC, you can organize and name your actions however you see fit. It's completely up to you.

Dynamic Action and Model Classes

Automatic, Anonymous Class Definitions

In Kiss, you don't name your action or model classes explicitly in your Ruby code. You just provide the methods for each class in a single file, and Kiss creates the class and references it based on the filename. This makes it easy to rename tables or reorganize actions into subdirectories. The action class hierarchy also changes automatically to match how you organize your action files. Since the action classes are all anonymous, you don't have to worry about editing class names in your Ruby code as you're moving your action files around.

Action Class Files are Optional

As in Rails and Merb, you can have actions that do nothing but render a template. In this case, you don't need to define an empty action file; you just omit the file entirely, and Kiss will look for the appropriately named template and serve that.

Model Class Files are Optional, Too

With Rails and Merb, you must define a model class file for each database table you wish to access via ORM methods. Often, you just want to select a record from a table easily, and do not need to define any custom methods on that table, so the model class remains an empty nuisance.

In Kiss, model class files are optional. You can create a table in your database and use it immediately in your Kiss applications without creating a model file. Kiss automatically creates a model class for any table you wish to access. Learn more in the Models chapter.

Ready to Dive In?

Learn how to install Kiss, or create a Kiss application.