Mail archive

[Acf] RFC: attempt to "simplify" acf

From: Natanael Copa <>
Date: Mon, 30 Oct 2006 20:12:37 +0100


I have been looking at Nathan's deom of Lua acf. Done some testing with
it and finally I think I have managed to understand what thins MVC
things is all about and what Nathan have been talkinb about all time.

I have tried to reimplement it, making it more object oriented and
making the *Framework* alot simpler. It does mean that it requires
somewhat more from the acf programmer.

I have uploaded some ideas to

The intersting parts are:


I'll try to explain what I have tried to do and how I have been
thinking. (I guess this i mostly for Nathan, but I send it here anyway)

I'll refer to the current acf as the "old" and my demo as "new", but
remeber this is just ideas. It would be nice with some feedback.

The front webconf.
The old webconf is kind of a fron controller. The new is more a front
view which creates a front controller object (cf).

The old webconf tried to be a frontend for all kinds of views, textview,
xml view etc etc. The new does not. It tries *only* to be the web view.
However, since cf is an object, it would be easy to create an xml view
or text view (for ajax stuff for example)

The cf (declared in lib/cf.lua) will contain a cf.model, cf.controller
and cf.view. those are loaded from path_info. Look at the code below:

#!/usr/bin/haserl --shell=lua
require "cf"

cf = WebCfObject:new()

cf:init( ENV.PATH_INFO, FORM )
cf:init_uri( ENV.SCRIPT_NAME )
<div id="content">
if cf.success then
        cf.view:content( )

The ENV.PATH_INFO and FORM are passed over to cf:init. If we were making
a cliconf that is executed from commandline, we would not have FORM or
ENV.PATH_INFO. We would still be able to create a "prefix/name/action"
string and a indata table (similar to FORM) by parsing the argv.

cf:init(path_info, indata) will create cf.prefix,, cf.action
based on path_info (look at the code. its not trying to be smart..) and
then it also creates cf.controller, cf.model and cf.view from that info.

Note that the cf.view is just like cf.model and cf.controller, a lua
script. Its not handeled as a special case. All are equal, and all are

If any of this fails, cf.success is set to false and cf.error_msg has a
error message (I did some attempt to make it possible to localize it
with local translations. I dont' know if its worth it)

The new cf, will not try to load any core.controller and core.model, nor
will it trigger a acf_core.controller or acf_core.model in case any of
the files are missing. It will just set cf.success and cf.error_msg.
(the idea is: "don't try to be smart")

the cf:init_uri() only exist in WebCfObject and not in the parent,
CfObject. CLI controllers, won't have the uri. Thats also why its called

the cf:run_controller will do the actual execution of the controller. If
the action does not exist, cf.success will be set to false with a proper
error message in cf.error_msg.

Another difference here is that old webconf first checked if file exist
and if it did, it ran dofile(). The new just runs loadfile() and if nil
is returned, set cf.success to false. The extra check if file exist is
not needed since loadfile does exactly the same thing as dofile, except
it won't trigger the assert upon failure.

The rest of the webconf can be considered as the old "generic.view". It
will create the header and the footer. (yes, if you dont want that, then
dont use webconf. creat another front controller)

The new webconf will always try to run cf.view:content() unless the
cf.success is set to false. Its up to the view to handle errors.

The missing parts so far are authentification and menu rendering. I'm
thinking of a auth.lua lib that contains an object to handle that. I'm
also thinking of adding session handling in haserl so you have a global
SESSION variable, just like ENV and FORM.

Menu rendering is what i intend to take a closer look at as next step.
I'm thinking of just let it be a lua table to make things more simple.

To conclude:
In old webconf you didnt need to create a view. The framework would take
care of it and do various different things, depending on what files it
found. The new framework dont even attempt to be smart. It requires that
the following files are there:

If any of those are not there, everyting will fail. It doesnt mean we
cant use any "generic" view. It could be a symblink.

We could also have some good use for scaffolding.

Check it out with:

  apk_add subversion make
  svn co svn://
  cd ncopa && make install-all

Natanael Copa

PS. a quick thought.. what if we included the menu in name.view.lua?
Received on Mon Oct 30 2006 - 20:12:37 UTC