Lua tables that contains objects are not rendered with pongo2
usernope opened this issue · 13 comments
I'm using algernon to try to output data from a lua script into a pongo2 template.
In the code below number_list outputs exactly as I'd expect but nothing renders for object_list.
What am I doing wrong?
data.lua
title = "This is the title"
number_list = {}
table.insert(number_list, 1)
table.insert(number_list, 2)
table.insert(number_list, 3)
object_list = {}
o1 = {1}
table.insert(object_list, o1)
o2 = {2}
table.insert(object_list, o2)
o3 = {3}
table.insert(object_list, o3)
index.po2
<html>
<head>
<title>{{title}}</title>
</head>
<body>
{{ title }}
<div>
{% for item in number_list %}
test 1: {{item}}
{% endfor %}
{% for item in object_list %}
test 2: {{item}}
{% endfor %}
</div>
</body>
</html>
Thanks for reporting! I'll look into this.
@usernope what is your expected output? <object> or some such?
If the output is really blank, Algernon's only failing is probably that it does not output <object> or <table> or similar.
@tooolbox I've tried it with just the text "test2" and it doesn't render it.
object_list seems to have a length of 0.
Ah, so the output contains no instances of the text test 2:
Interesting.
This, or approximately this, was working as of #79 so perhaps some kind of regression.
Hi, I'd just like to check if anyone has managed to reproduce the problem or if it's something on my side.
Thanks.
I reproduced with the latest release on Windows. Straight sequences and key-value tables work fine, but nesting a table makes the length zero. Also checked with {{ object_list | length }}
I had a suspicion which turned out to be true, though:
I don't use data.lua because I don't like polluting the global VM space, I use an index.lua that calls serve2 with a page.tmpl and that works fine (just tested). So the issue appears to be with the data.lua feature specifically. @usernope maybe try changing to a Lua handler as a workaround while this is otherwise investigated?
If I place data.lua and index.po2 in a directory and launch Algernon with algernon -e . or algernon -t ., it seems to work fine.
I get:
This is the title
test 1: 2 test 1: 3 test 1: 1
Could you please let me know:
- If you using Algernon from the
mainbranch, or the latest release version? - Which command are you using for launching Algernon?
@tooolbox Does this appear to work on Windows when using the latest main commit?
Hey @xyproto I believe the problem is the output should look roughly like this:
This is the title
test 1: 2 test 1: 3 test 1: 1
test 2: <table> test 2: <table> test 2: <table>
But you just get this:
This is the title
test 1: 2 test 1: 3 test 1: 1
The whole second loop generates no output and if you do {{ object_list | length }} the result is zero.
I tested and repro'd with latest release rather than latest commit, because I don't actually have a Go compiler on this windows box, long story 😅 But, quickly scanning over the interim commit messages, I don't see anything that would seem to affect this?
When adding some logging to Algernon, for what the Lua state contains, I get this:
INFO[3816] GOT <nil>: o2 ==> map[1:2] (map[int]int)
INFO[3816] GOT <nil>: number_list ==> map[1:1 2:2 3:3] (map[int]int)
INFO[3816] GOT <nil>: o1 ==> map[1:1] (map[int]int)
INFO[3816] GOT <nil>: _G ==> map[_GOPHER_LUA_VERSION:GopherLua 0.1 _VERSION:Lua 5.1 title:This is the title] (map[string]string)
INFO[3816] GOT <nil>: math ==> map[huge:9223372036854775807 pi:3] (map[string]int)
INFO[3816] GOT <nil>: o3 ==> map[1:3] (map[int]int)It looks like number_list is fine, and is considered to be a map[int]int, while object_list is interpreted as o1, o2and o3, for some reason.
I wonder if this could be an issue with the Lua interpreter, or if maps of objects just needs to be handled in a different way within Algernon. I'll check the type of object_list.
I think the "next action" here might be to switch to a different Lua implementation.
I think the "next action" here might be to switch to a different Lua implementation.
Oh my!
Well, is it really the Lua implementation, or is the implementation of the data.lua feature? Because as I noted above, it works fine when using an index.lua handler:
I don't use data.lua because I don't like polluting the global VM space, I use an index.lua that calls serve2 with a page.tmpl and that works fine (just tested). So the issue appears to be with the data.lua feature specifically. @usernope maybe try changing to a Lua handler as a workaround while this is otherwise investigated?
Just something to check into before you need to go to those lengths, I think.