Re: [Acf] new code in acf trunk
On Sun, 2007-01-28 at 18:47 +0000, Nathan Angelacos wrote:
> A new codebase has been imported into the acf trunk - and much of the
> old controllers/models were removed.
I started early this morning. Havent come more than to fix broken lua
apk. (or was it haserl)
> 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?
Create a new page Under Developer Docs (documentation)
> Quick start:
> 1. install subversion and haserl on your alpine box
> 2. svn co svn://dev.alpinelinux.org/acf/trunk var/lib/acf
just a though. acf is a web app, not variable data. Wouldnt /usr/lib/acf
be more FHS?
> 3. edit /etc/inetd.conf:
> www stream tcp nowait root /bin/busybox httpd -h /var/lib/acf/www
you should be able to run busybox httpd as non-root without any problem.
I think haserl is suid root.
> 4. /etc/init.d/inetd.conf restart
you mean: /etc/init.d/inetd 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 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
> 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:
> Why is this good?
> Here's a couple of flows:
> 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.
Well done! Good work!
I'm trying to allocate a few minutes for this today to test it.
BTW. The "make install DESTDIR=/tmp/image" is broken. It's critical for
Received on Mon Jan 29 2007 - 15:38:49 GMT