Mail archive

Re: [Acf] Some ACF things to work on

From: Nathan Angelacos <>
Date: Wed, 06 Feb 2008 13:41:37 -0500

Copying the ACF mailing list, as we should probably have a record of
this. :-)

Mika Havela wrote:
> I have been looking into the menu builder system this morning.
> What I come up with so far is:
> 1) Added function get_submenuitems() int lib/menubuilder.lua (When
> calling this, you get a table with available tabs based on the .menu
> files. Later in this mail I describe how this table looks.)
> 2) For now, I'm fetching the submenu-table from the same place where
> the stub-code was before (in acf_www-controller.lua). As I understand
> your thought... this is wrong.
> 3) Now the submenu table looks a bit different, so I modified
> template-html.lsp to reflect these changes (and see to that the
> template-html.lsp wont brake if it doesn't get any submenu items - It
> just displays things without the submenues if there is none).
Ok, sounds good.

> These changes works just fine! But I think that the submenus are
> updated on each request (and as I understand you... this is not good).
> I'm attaching the diffs for you so you can see what I have done (but I
> haven't committed anything in core - except some small modifications
> on .menu files)

Right; we'd like to build the menu once, on logon.
> Now to some questions so I can continue and make things better (see below)
> On Feb 4, 2008 5:04 PM, Nathan Angelacos <> wrote:
>> Mika,
>> I have a project for you with ACF core. The menu builder system. I
>> think the pieces are there to get it working. Right now Mike Mason is
>> working on the authorization system, could I have you work on the menu
>> system?
>> Here's what we have:
>> right now, if you put data into the sessiondata table, it will
>> automatically be available for you the next request. (Try it - its cool!)
> I'm looking in acf_www-controller.lua, function mvc.on_load(),
> There you create a self.sessiondata = {}.
> Later on you feed this with some hash-IDnumber (into
> So when you say (above) that "If you put data into sessiondata table"
> I assume that I could do:
> self.sessiondata.submenu = {"item1", "item2", "item3",}
> and later on in the code call for this self.sessiondata.submenu to
> display the items in the menu.
> (I know that "item1", "item2", won't work as submenuitems - Its just a example)
> But when I put (whatever) into self.sessiondata then I get a error (I
> think it has to do with the config-file or when you save sessiondata
> information).
> The only thing I can do is to feed the with
> whatever I want without breaking things (just to test of course).

mmm. I'd be interested in the specific error. What you describe is
the way it should work.

In fact the "self" isn't strictly needed:
  sessiondata.submenu = { "item1", "item2"} will work just as well as
> So if I'm not misunderstanding things... We could (and maybe this is
> what you mean) add the submenu (and the main menu) into the
> self.sessiondata after successful login, and then you won't need to
> recreate the menu... it will be there in the and
> self.sessiondata.submenu until something clears those tables (or takes
> away some items that shouldn't be displayed for the user for some
> reason).

Yes, that's exactly what I have in mind.

> So ether I missunderstood your above mentioned "sessiondata table"
> (and I'm not supposed to be able to add items to self.sessiondata), or
> I understood right (but then something is wrong because it breaks when
> I add with some items).

You understood correctly. It should work.
>> What we need is to pull the "stub code" out of acf_www that generates
>> the basic sub-menu tabs (the "actions") and replace it with a library or
>> something that prints the tabs from the menu files.
> Stub code is gone! And lib/menubuilder.lua now creates a table with
> submenus based on .menu files (as mentioned above).

>> What I had been thinking is:
>> When you log on, the menubuilder model/controller generates the "menu
>> table" from the menu files, and then stores that table in sessiondata.
>> It is now available for each request after that, without having to
>> regenerate it. (Later, when mikes' authorization code is done, the
>> menubuilder model/controller can delete menu items that you are not
>> authorized to see. But that's later)
> As mentioned above, I tested to add this into sessiondata-table but
> the view brakes.

Do an svn up, and then could you please give me the exact error you get?

>> Next, the view probably needs to be able to call a library that knows
>> how to "present' the menu. I think right now alot of the menubuilder
>> code is in acf_www-controller, and that's wrong... but it got us started.
> Don't really understand.
> The submenu table looks like this (based on the changes I did):
> ["submenu"]["fetchmail"] = {}
> ["submenu"]["fetchmail"][1]["tab"] = "Status"
> ["submenu"]["fetchmail"][1]["action"] = "status"
> ["submenu"]["fetchmail"][2]["tab"] = "Expert_configuration"
> ["submenu"]["fetchmail"][2]["action"] = expert"
> ["submenu"]["lbu"] = {}
> ["submenu"]["lbu"][1]["tab"] = "Status"
> ["submenu"]["lbu"][1]["action"] = "status"
> ...

what I mean is the template-html.lsp should have something like
"require ("render_menu"), and redner_menu is a lua library that knows
how to present your menu table you describe above.

> The "Stub code" in the acf_www-controller.lua is replaced with:
> submenu = submenu[pageinfo.controller]
> This filters the submenu so it only contains the objects for the
> current controller.
> To get above "stub replacement code" working, you need to re-read the
> lib/menubuilder.lua.
> But if we get to put the whole submenu table into sessiondata, then
> the previous code could look like:
> submenu = self.sessiondata.submenu[pageinfo.controller]
> and then you wouldn't need to recreate the submenus (they will always
> be available as far as they exist in self.sessiondata.submenu).
Yes, exactly.

> Above you mention "that knows how to 'present' the menu".
> My thoughts above... are they as you thought?
> Or did you have some other thought (in that case I understood you wrong).

by "present" I meant "generate appropriate html based on the menu table"
  Its a library that is called in the view.

>> Finally, I had been running into lots of problems before with "how do we
>> know which menu item is "highlighted" or "current"? For now, don't
>> worry about it. The answer is "its the last item from the "cookie
>> crumb" list that we are going to display - but we don't have that part
>> there yet either. :-) )
> The diffs I sent you, they highlight the current tab and everything
> works just fine.

for most cases - but its possible to have actions that don't have a menu
item. Which menu item is highlighted then.

> When it comes to 'cookie crumb' I haven't looked at that (still not
> sure if I got the submenu thing right and I don't think you asked me
> to look at the cookie crumb ether).
Well, you've done such a good job so far... once we get this working,
we'll talk about the cookie crumb idea. :-)

>> Do you think you could work on this for us? It requires more "design
>> thought," since its part of the core - but I think you can handle it.
> Hmmm... I gave things a thought... but I don't know if my suggested
> code (the diffs) covers the "design thought".
> But as far as I can see... it works ;-)

Yes, I think you have the right idea. Go ahead and submit your code
to svn, and let's see why the sessiondata generates errors.

Received on Wed Feb 06 2008 - 13:41:37 GMT