A Cookbook.

Apotomo. Stay minimal. Go big.

Nine points about Apotomo.

A Widget is a Component is a Cell.

Build your application with components. A component might be a static page, a navigation menu or a complex form with different workflows. They’re all widgets in Apotomo. Widgets are derived cells, which means they behave like superfast mini-controllers, utilizing all of Rails’ functionality including views, helpers and models.

We want Stateful Components.

Widgets are finite state machines. This means you don’t have to care about restoring states of your component, Apotomo does it. When a component is invoked due to some event it is automatically set to the exact state it was rendered the last time.

No longer think in requests, think in events in a persistent environment.

Update Widgets via AJAX.

Since the GUI is separated into independent widget components, a click may result in one widget sending back it’s new view, in updating multiple areas or even the whole screen. You, as the application programmer, don’t have to care about where to put your content. Apotomo handles the updating of your GUI and the asynchron communication between GUI and application.

Use ExtJS.

Apotomo provides different widget families. Some coarse widgets like Frame, Page, ChildSwitch or TabPanel allow a fast and clean application design. The ExtJS widgets map components to real ExtJS widgets, meaning you can use ExtJS’ TreePanel or Window without touching JavaScript at all. Apotomo is the bridge between your components and the ExtJS frontend.

Build a widget tree, just as in real GUIs!

Nest the widgets in pure ruby as you need them. Maybe a TabPanel should contain a form, or the top page should contain a counter? Drag ‘em around as you want it. The widgets will care about the rendering and updating of their children.

Let Events speak.

Events are fired by user gestures or explicitly by widgets. Depending on the type of event, widgets can take actions like updating itself, inform other widgets, or even spend a cold beer!

Events can bubble.

The widget tree concept opens a way for an event system known from real GUI systems: if an event is fired, and is not handled by the current widget, it bubbles up to its parent. Event handlers can be attached to any widget. This allows sophisticated design like Event Aggregators.

Parameter requests can bubble.

Widgets no longer access request parameters directly, they kindly ask for it with the #param method. If the value for the parameter is not found the question travels up, asking its parent. Access control and stateful behaviour is what we get from that..

No longer address controllers, address widgets!

A small addressing mechanism allows referencing to widgets and states. A form is no longer sent to a specific controller action, but to some widget state.

As an additional advantage we get “stateful bookmarks”, meaning you can quickly access different parts of your application with bookmarks.

Got interested? Have a look at the cookbook…