Mail archive
acf

[Acf] mvc.lua updates - inheritance fixes

From: Nathan Angelacos <nangel_at_nothome.org>
Date: Thu, 01 Mar 2007 16:57:14 -0500

This is a low-level change, but I want to document it for the records.
It documents a change between acf svn175 and acf svn181, and does some
cleanup of the code in acf-controller.lua (the app) as well as mvc.lua
(the framework)

The inheritance of functions and variables mostly worked with svn175,
but with svn181 it works in a clearly documented way:

child.model -> child.worker -> parent -> parent-worker -> grandparent ->
grandparent->worker (and so on) -> mvc [module code]


A clear demonstration of this is in acf-controller.lua, where the init
function put private view_resolver and exception handler in the parent's
tablespace. All that's gone. Overload view_resolver in acf, and its
done for the application. Do it in interfaces-controller, and its done
for interfaces and any child controllers.

cfe is defined in acf-controller (e.g. acf.worker.cfe) and is available
in all models and controllers, and looks like a local function to them.



This also simplifies controllers using other controllers:

foo = self:new("name of new controller")
vars = foo.worker.read()
foo=nil

Simple and straightforward... no worries about create_child, like svn175
required.




I've renamed acf-controller.lua to acf_www-controller.lua, because it is
now a realistic possibility to use different controllers with the same
backend - the overloading of view_resolver / exception_handlers now
works correctly.



mvc.lua was enhanced to be able to tell if a controller/action is
undefined, and will report that in a (more) friendly way. This is
necessary because of the inheritance. EVERY controller now had a "cfe"
and a "exception_handler" action. ;-)



A downside to this is acf_www is now "just another controller"... Try;
cgi-bin/acf/acf_www/cfe, and it will try to run the cfe function. ugh.
   The way around this is to move the application controller one level
higher than the application's controllers. For example, here's a quick
hack to acf:

    <?
    require("mvc")

    -- create a new container
    FRAMEWORK=mvc:new()

    -- set the configuration parameters
    -- This loads the container with the config info
    -- but does not load the application worker/model
    FRAMEWORK:read_config("acf")

    -- Create an application container -
    -- loads the application controller/model code
+ local x = FRAMEWORK.conf.appdir
+ FRAMEWORK.conf.appdir="/var/lib/acf/"
    APP=FRAMEWORK:new("acf_www")
+ FRAMEWORK.conf.appdir=x
+ x=nil

    -- Dispatch the application
    APP:dispatch()
    ?>

(move acf_www-controller.lua one level up before trying)

This monkeying around with FRAMEWORK.conf.appdir is necessary because
mvc:new wants to read the parent's conf.appdir to find the base
directory for controllers.

<thinking out loud>
Alternatively, acf_www-controller.init could set the directory to
directory + app, and that might be a cleaner solution
</thinking>

But doing the above steps means the acf_www controller is no longer
available to the web interface.



---
The good news here is mvc.lua and acf-controller.lua are now simpler, 
and no code changes were needed to any of the application controllers. 
They were insulated from these changes.    (Which is part of what we are 
trying to do with MVC, right?)
Cheers.
Received on Thu Mar 01 2007 - 16:57:14 GMT