Mail archive

[Acf] new code in acf trunk

From: Nathan Angelacos <>
Date: Sun, 28 Jan 2007 18:47:20 +0000

A new codebase has been imported into the acf trunk - and much of the
old controllers/models were removed.

The intent of this snapshot is:

1. show how <appname>-controller.lua can be used to extend the mvc.lua
core. There's just enough in acf-controller.lua to override mvc.lua's
default behavior.
2. show a non-trivial example of the framework (maintaining an interface

Much of this should/will be documented in the wiki. Natanael, could you
please direct me to a page on the wiki where acf documentation can go?

Quick start:

1. install subversion and haserl on your alpine box
2. svn co svn:// var/lib/acf
3. edit /etc/inetd.conf:

www stream tcp nowait root /bin/busybox httpd -h /var/lib/acf/www

4. /etc/init.d/inetd.conf restart
5. create /etc/acf/acf.conf:


6. Use your browser to go to http://<host>/cgi-bin/acf/interfaces/read

Quick Tour:
(I'll assume for the hostname
        goes to READ, and the URL is updated to reflect that
        goes to READ, and the URL is updated
        mvc error (this is a TODO item for mvc.lua)

use the interface to create / delete interfaces. The current validation
just checks to make sure the interface name is unique, and the method is
 valid. Create / delete / update interfaces without names, incorrect
methods, etc.
        creates a new interface at the top of the file named lo2
        shows the new interface file, complaining that lo2 already
        shows the update page, explaining that method is invalid
        deletes lo2
        no change. lo2 doesn't exist, so returned to list.

Guided Tour:

acf-controller.lua extends the mvc.lua core with two additional functions:

A) cfe (a function that returns a configuration framework entity -
basically a common nomenclature for things that can be edited.) cfe is
available in all controllers/views/models because it is available in the
application controller.

B) the exception_handler is extended to know how to handle an
http-redirect. (more on this later) The view resolver is extended to
resolve a view with an action hint. (Later, templates will be added)

The interfaces suite:

Basically, all configuration suites should include CRUD (Create Read
Update Delete) functionality. The interfaces "read" action shows an
abbreviated list of all the defined interfaces. If you look at the
controller/view pair, you'll notice that the controller returns the
entire dataset it gets from the model - the View decides to show just
part of it.

Update / Create and Delete are all handled in the controller, and the
model cares for ensuring the interfaces file is always maintained in a
valid state.

Regarding the http-redirect in the exception handler. By definition,
the controller can't change the view, and it can't tell the view how to
display view data. It also can't control what data the view sends it.
All it can do is attempt to process the request, and fall through. The
application/mvc framework will take care of the view resolving.

The way to abort early is to raise an error. This alerts the
application that "something weird has happened", and allows the app (or
framework) to do something other than flow to the normal view.

The acf-controller.lua exception handler was extended. If the error
message is a string, the error is passed on to the normal mvc.lua
exception handler. If a table is passed as the error message,
acf-controlelr checks the type field for "redir" - and if so, it
generates a http redirect message. (This code really belongs in the
acf-model or acf-view... but that's a TODO - it works for a demo now)

Why is this good?

Here's a couple of flows:

You want to update lo. You get a page showing the interface. You make
modifications and push submit. If validation fails, the /same/ page is
shown, with error messages. If validation succeeds, the file is
committed, and you are redirected to the main list page.

Here's how it works:

request: update?iface=lo
controller->model (get info)->controller->interfaces-update.view

request: update?iface=lo&method=invalid&cmd=save
controller->model (get info)->controller-> model (commit - FAILS)->

request: update?iface=lo&method=loopback&cmd=save
controller->model (get info)->controller-> model (commit - succeeds)->
        controller (raise exception to redirect) ->
        acf-exception-handler->tell browser to redirect.

request: update?iface=DOESNOTEXIST
controller->model (get info - FAILS)->controller (raise exception) ->
        acf-exception-handler->tell browser to redirect

We had a problem with the last webconf where a commit would end up
showing a different view, but the URI was still the "commit" URI.  This
resolves that.   The view can ASK for info, and the controller fulfills
the request.   A commit does its job, and the controller can return the
info it committed.  But from an application perspective, we want the
user to go back to another page.  So by raising an exception, we can
tell the browser - oh... you want to go over here now.
This would work for the CLI as well - instead of a http 302 error, the
acf-cli-controller exception handler could print:
OK.  Please run <scriptname> interfaces read   to see results.
What i'm really aiming for here is to make sure enough of the framework
and early app stuff is there to build on in the future (rather than
starting from scratch every time.)   If you see glaring errors in this
approach, i'm open do discussing them.  Otherwise, i'll document more of
this in a tutorial format (how to build the "interfaces" suite) in the
wiki, and then continue with building out the acf app part of the framework.
Received on Sun Jan 28 2007 - 18:47:20 UTC