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
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?
1. install subversion and haserl on your alpine box
2. svn co svn://dev.alpinelinux.org/acf/trunk 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
(I'll assume 192.168.0.1 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
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
no change. lo2 doesn't exist, so returned to list.
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
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
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:
controller->model (get info)->controller->interfaces-update.view
controller->model (get info)->controller-> model (commit - FAILS)->
controller->model (get info)->controller-> model (commit - succeeds)->
controller (raise exception to redirect) ->
acf-exception-handler->tell browser to redirect.
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