Alpine Configuration Framework Design: Difference between revisions
(Remove self references ('ACF' is a redirect back to this page)) |
m (hyperlink cleanup.) |
||
Line 7: | Line 7: | ||
Other competitors in the arena were Webmin, Ruby on Rails, PHP with templates. | Other competitors in the arena were Webmin, Ruby on Rails, PHP with templates. | ||
A full webmin (Perl), RoR or PHP implementation each require several MB of installed code, and can have very slow startup times, especially when used in "cgi" mode. After evaluating many options, we found that [ | A full webmin (Perl), RoR or PHP implementation each require several MB of installed code, and can have very slow startup times, especially when used in "cgi" mode. After evaluating many options, we found that [https://www.lua.org Lua] has the following advantages: | ||
*It is small (typically ~200KB of compiled code) | *It is small (typically ~200KB of compiled code) | ||
*It compiles and runs much faster than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=php PHP], [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=perl Perl] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=ruby Ruby] | *It compiles and runs much faster than [https://web.archive.org/web/20100707143932/http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=php PHP], [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=perl Perl]{{dead link}} or [https://web.archive.org/web/20100313062645/http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=ruby Ruby] | ||
*It provides a "normal" scripting language with [ | *It provides a "normal" scripting language with [https://en.wikipedia.org/wiki/Lua_(programming_language)#Features features] similar to PHP, perl, java, [[awk]], etc. | ||
Haserl + Lua provides a 'good enough' toolset to build a full-featured web application. | Haserl + Lua provides a 'good enough' toolset to build a full-featured web application. | ||
Line 33: | Line 33: | ||
Of course, as with all MVC designs, the ACF MVC design is not quite 'pure' MVC and has evolved over time. Most of the '''controller''' functionality is handled by the framework code. The framework code will also automatically generate views for HTML, JSON, and a few other viewtypes if no '''view''' is defined. Also, many '''model''' functions are implemented in helper libraries. We have attempted to make it as easy as possible to develop new ACF modules. | Of course, as with all MVC designs, the ACF MVC design is not quite 'pure' MVC and has evolved over time. Most of the '''controller''' functionality is handled by the framework code. The framework code will also automatically generate views for HTML, JSON, and a few other viewtypes if no '''view''' is defined. Also, many '''model''' functions are implemented in helper libraries. We have attempted to make it as easy as possible to develop new ACF modules. | ||
For good background information on what ACF attempts to do, please see Terence Parr's paper "Enforcing Strict Model-View Separation in Template Engines" at [ | For good background information on what ACF attempts to do, please see Terence Parr's paper "Enforcing Strict Model-View Separation in Template Engines" at [https://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf https://www.cs.usfcs.edu] or the [[Media:Mvc.templates.pdf|local copy]] of the pdf. | ||
= Starting ACF = | = Starting ACF = | ||
Line 65: | Line 65: | ||
== Other useful links == | == Other useful links == | ||
#[ | #[https://www.lua.org/manual/5.1/ Lua 5.1 Reference Manual] | ||
#[ | #[https://www.lua.org/pil/ Programming in Lua (first edition)] | ||
#[[Managing ACF]] | #[[Managing ACF]] | ||
Line 93: | Line 93: | ||
Now you can start editing your myskin.css.<br>If you have ACF running on the computer, you can browse to https://<hostname>/cgi-bin/acf/acf-util/skins/read and switch to your new skin (called myskin) and see the results of your changes. | Now you can start editing your myskin.css.<br>If you have ACF running on the computer, you can browse to https://<hostname>/cgi-bin/acf/acf-util/skins/read and switch to your new skin (called myskin) and see the results of your changes. | ||
Pack your myskin folder, containing your css file (and images, if there are any).<br>Send this patch to acf@lists.alpinelinux.org ''('''Note:''' Don't forget to [ | Pack your myskin folder, containing your css file (and images, if there are any).<br>Send this patch to acf@lists.alpinelinux.org ''('''Note:''' Don't forget to [[Alpine_Linux:Mailing_lists|subscribe]] before sending your patch)'' | ||
= ACF Packages = | = ACF Packages = | ||
Look at [ | Look at [[ACF packages]] to see available ACF modules and their status. | ||
[[Category:ACF]] [[Category:Lua]] | [[Category:ACF]] [[Category:Lua]] |
Revision as of 22:30, 27 July 2023
Alpine Configuration Framework
The Alpine Configuration Framework (ACF) is a mvc-style application for configuring an Alpine Linux device. The primary focus is for a web interface - ACF's main goal is to be a light-weight MVC "webmin".
Why Haserl + Lua
Other competitors in the arena were Webmin, Ruby on Rails, PHP with templates.
A full webmin (Perl), RoR or PHP implementation each require several MB of installed code, and can have very slow startup times, especially when used in "cgi" mode. After evaluating many options, we found that Lua has the following advantages:
- It is small (typically ~200KB of compiled code)
- It compiles and runs much faster than PHP, Perl[Dead Link] or Ruby
- It provides a "normal" scripting language with features similar to PHP, perl, java, awk, etc.
Haserl + Lua provides a 'good enough' toolset to build a full-featured web application.
Why ACF is MVC
The MVC design pattern is used to separate presentation information from control logic. By MVC we mean:
- Model - code that reads / writes a config file, starts / stops daemons, or does other work modifying the router.
- View - code that formats data for output
- Controller - code that glues the two together
Note the lack of words like: HTML, XML, OO, AJAX, etc. The purpose of ACF's MVC is simply to separate the configuration logic from the presentation of the output.
The flow of a single transaction is:
start -> execute requested function in controller, optionally reading/writing a file using functions in the model -> execute the view to format the output -> end
Every transaction follows this pattern. For ACF developers, the focus should be on getting a model that does a proper job of abstracting the config file into useable entities and then building a controller that presents useable "actions" based on the model. The presentation layer should be last on the priority list.
Of course, as with all MVC designs, the ACF MVC design is not quite 'pure' MVC and has evolved over time. Most of the controller functionality is handled by the framework code. The framework code will also automatically generate views for HTML, JSON, and a few other viewtypes if no view is defined. Also, many model functions are implemented in helper libraries. We have attempted to make it as easy as possible to develop new ACF modules.
For good background information on what ACF attempts to do, please see Terence Parr's paper "Enforcing Strict Model-View Separation in Template Engines" at https://www.cs.usfcs.edu or the local copy of the pdf.
Starting ACF
Installing ACF is really simple. Just type this in your terminal and follow the instructions to setup ACF:
setup-acf
(This script will install mini-httpd, create a certificate, starts mini-httpd in HTTPS mode and installs some basic acf-packages.)
To view ACF, simply browse to your machine https://<hostname>/
See also Managing Your ACF Installation
As of 1.9 you will get prompted for a password for the 'root' account so this is no issue for newer Alpine Linux versions.
ACF Developer's Guides
- mvc.lua reference - mvc.lua is the core of ACF
- mvc.lua example - build a simple (command-line) application
- acf www-controller reference - ACF www application functions
- acf www-controller example - webify the above examples
- ACF how to write - Step by step howto for writing ACF modules
- ACF core principles - Things that are standard across the application
- LPOSIX - Documentation for the Lua Posix functions
- ACF Libraries - Document the libraries and common functions
- Writing ACF Views - Guide for writing a view
- Writing ACF Controllers - Guide for writing a controller
- Writing ACF Models - Guide for writing a model
Other useful links
ACF Layout
ACF has support for multiple skins.
Only a few skins are available. Feel free to contribute in programming css-stylesheets for ACF.
How to contribute
First, download ACF using git or installing available ACF modules using 'apk add'.
Easiest is if you download the latest Alpine Linux ISO, boot a box from the ISO and then run 'setup-alpine' and 'setup-acf'. That way you get a running environment fast and easy!
Some example skins are available:
- /usr/share/acf/www/skins/alps/
- /usr/share/acf/www/skins/cloud/
- /usr/share/acf/www/skins/ice/
- /usr/share/acf/www/skins/snow/
- /usr/share/acf/www/skins/wik/
Make a new skin folder.
mkdir -p /etc/acf/skins/myskin
Create a css file called as the folder.
touch /etc/acf/skins/myskin/myskin.css
Now you can start editing your myskin.css.
If you have ACF running on the computer, you can browse to https://<hostname>/cgi-bin/acf/acf-util/skins/read and switch to your new skin (called myskin) and see the results of your changes.
Pack your myskin folder, containing your css file (and images, if there are any).
Send this patch to acf@lists.alpinelinux.org (Note: Don't forget to subscribe before sending your patch)
ACF Packages
Look at ACF packages to see available ACF modules and their status.