[luci] A few beginner questions

Tim Merrifield tmerri4 at uic.edu
Fri Apr 10 22:21:24 CEST 2009


That is terrific info. Thanks so much for that!

One more question though. What if I want to create my own UCI file format?
How do I go about doing that?

Thanks!
Tim

On Fri, April 10, 2009 2:10 am, Steven Barth wrote:
> 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
>
> _______________________________________________
> luci mailing list
> luci at lists.subsignal.org
> https://lists.subsignal.org/mailman/listinfo/luci
>
>




More information about the luci mailing list