lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


>      My intended configuration would be like the scenario number 3
> you've described:
> 3) Lua Pages with calls to a library: URL -> page.lp <->
> lib.lua -> results
> A simple way to separate business and presentation logic
>      The Lua page runs the library at the very beginning.
> Sometimes the
> library would decide to make a redirect, which is impossible with the
> current CGILua.

Well, it depends on how you create "page.lp". If it does not generate any
HTML per se, you can decide on different output pages from your "lib.lua".
For example (untested):

<% require("lib.lua") %>

if cgi.x == 1 then
elsif cgi.x == 2 then

Would that work for you?

>      MVC is always a good thing to aim for. But the current Lua pages
> are more code-like than template-like. Take Smarty
> ( for instance. If I want to output a
> table with
> the name and telephone of a bunch of people I don't have to
> write a loop
> in my PHP page if I am using Smarty, there is a tag that
> iterates over
> associative arrays.

I assume that would be the "{section ...}" construct, right? To be sincere
they look a lot like a loop for me, but you can think in the following
Smarty excerpt

{section name=count loop=$users}

as the following LP

<% for count, user in ipairs(users) do %>
      <td><%= %></td>
      <td><%= %></td>

Or, if you prefer something less verbose, you can create an iterator (PIL
7.x) and use:

<% for user in users() do %>
      <td><%= %></td>
      <td><%= %></td>

This is the kind of things that we are studying for the new context-aware
templates. One could do something like

users = {{name="a", phone="123"}, {name="b", phone="456"}}
cgilua.includehtml("page.lp", {users = users})

and CGILua would create the "users()" iterator automagically. We still have
to iron out the details, but it's doable.