Alpine Configuration Framework Design: Difference between revisions

From Alpine Linux
(Copied page from old wiki)
 
(Explain why haserl+lua & what we mean by MVC)
Line 1: Line 1:
The Alpine Configuration Framework (ACF) is a mvc-style application for configuring an Alpine device.  These pages document some of the underlying principles of the framework
== Documentation for the Alpine Configuration Framework ==
 
The Alpine Configuration Framework (ACF) is a mvc-style application for configuring an Alpine device.  The primary focus is for a web interface - ACF's main goal is to be a light-weight MVC "webmin".
 
==== Why Haserl + Lua was chosen over Webmin, Ruby on Rails, or 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 [[http://www.lua.org Lua]] has the following advantages:
 
* It is small (typically ~200KB of compiled code)
* It compiles and runs much faster than PHP or Perl
* 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 the controller actions and getting a model that does a proper job of abstracting the config file into useable entities.
 


* [[Introduction to the mvc.lua core module]]  (The core "mvc" part of the application)
* [[Introduction to the mvc.lua core module]]  (The core "mvc" part of the application)
* [[ACF core principles]] (Things that are standard across the application)
* [[ACF core principles]] (Things that are standard across the application)

Revision as of 17:20, 22 October 2007

Documentation for the Alpine Configuration Framework

The Alpine Configuration Framework (ACF) is a mvc-style application for configuring an Alpine device. The primary focus is for a web interface - ACF's main goal is to be a light-weight MVC "webmin".

Why Haserl + Lua was chosen over Webmin, Ruby on Rails, or 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 or Perl
  • 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 the controller actions and getting a model that does a proper job of abstracting the config file into useable entities.