[luci] A few beginner questions

[Steven Barth]

Hello Tim,

> 1.) When I make changes to a controller (for instance the
> myapplication/luasrc/controller/myapp/mymodule.lua described in the
> Modules How To) what additional steps are need to push these changes out?
> The documentation makes it seem like I should see these changes
> immediately via the browser. But the only way I can get this to work is to
> stop the web server and restart it using "make runhttpd". Maybe the better
> question is, what is the development process like? Am i missing some
> compilation step?
"make runhttpd" copies the files over from the source directory to the host 
directory where the files are actually run, so thats why there is no immediate 
effect when changing a file, also there is some caching involved with templates 
etc. thats mainly useful for the emebedded devices. If you are working on a 
specific application like "applications/myapplication" you can do:
make runhttpd MODULES="applications/myapplication"
to only refresh the files of this application.


>
> 2.) Can someone give me a high level explanation of the different parts of
> Luci? What is happening behind the scenes? What happens when a user tries
> to access a page?
The first thing what happens is that the SGI (thats the connector between the 
webserver and the LuCI webframework, like a CGI binary) accepts a request. 
Then it creates a request-object which is stored in luci.http.context.request. 
This request object will be used to communicate with the Server (getting POST-
Data, sending headers, response data, ...). This is done with the luci.http.* 
functions (See API documentation).

As a second step the LuCI dispatching tree is generated. This is a kind of 
virtual filesystem tree inside LuCI where all pages and actions (called nodes) 
in our case are placed. This generation happens by calling the index-Function 
of all controllers. In this index-function with a call to 
luci.dispatcher.entry({"foo", "bar", "baz"}, ...) a controller could for 
example register the node foo/bar/baz. The functions mainly involved are the 
luci.dispatcher.* functions (See API documentation).

The third step is the requested URL will be split into parts like this:
Request: /cgi-bin/luci/foo/bar/baz the Path dispatched by LuCI is 
"foo/bar/baz" in this case. This means the node "baz" which is a child of node 
"bar" which is a child of "foo" in our virtual filesystem is called. 
If this node (and all of its parent nodes exist) - if some controller 
registered them - then the associated action (which can be a Lua function, a 
template to render or a CBI form to parse) will be done.

For Lua functions and templates this is simple: Just executing or rendering. 
For CBI forms (these are the autogenerated forms used for UCI mainpulation and 
other kinds of tasks) the so-called CBI-model - files in model/cbi/ which 
describe the mapping of configuration options to a form or describe a form 
which does some other tasks like wizards - is parsed. If the user submitted 
some data with the request (like a form) this data will be validated and an 
appropriate aciton will be taken (like writing UCI configurations). As a last 
step the CBI generates an HTML-Form out of the CBI-Model which is sent to the 
user's browser.


>
> 3.) I can't seem to tell what the difference is between an application and
> a module. Can someone explain the difference here or point me in the right
> direction?
There is no real difference a module in our case is just a set of many 
applications that belong together and are more or less self-contained for a 
specific task (like basic configuration).
In our case most of the "applications" outside a module are depending on at 
least one "module" to be installed and working properly.


> -Tim
Regards

Cyrus