table_for, wasn't it there?
I’m trying to make the scaffolding/administration template as small and easy to understand as possible.
At the same time, trying yo make it easier to read for the user, the current “listification” of the objects uses inspect/to_s to show them, which makes really hard to grasp what they are when you’ve not redefined the methods properly.
So I was trying to replace the ugly table code with an helper.
# Creates a table automatically based on the structure of the
# objects passed as argument. Objects have to be non-empty
# because the headers are built via reflection on the objects.
def objects_table_for(objects, options={})
keys=objects.first.class.properties.keys - [:oid]
headers=keys+['Actions']
values=objects.map do |o|
ary=[]
keys.each do |k|
ary << o.send(k)
end
ary << %~<a href="edit/#{o.oid}">edit</a> <a href="delete/#{o.oid}" onclick="confirm('Are you sure?')">del</a>~
end
options= {:alternating_rows=>true,
:id=>'objects_table',
:values=>values,
:headers=>headers}.update(options)
table(options)
end
Suggestions on the above code and on the name are welcome before I send a patch against devlab and repo.
Anyway, this allows me to reploace 20 lines of view code with one, at the cost of making it less configurable, but making it much more easy to find something.
Two problems still open: it seem that scaffolding does something if the things are Orderable, but I don’t understand what, please provide an hint if you can.
Also, Date/Time will be shown in a classical to_s fashion, I’m wondering if I should add an option, if I should yield a block and or use some kind of Setting, suggestions welcome.
Oh, sorry again for not updating the blog, I’m coding nicely behind the scene, just in a floating state, as you can imagine if you take a look at my dev memo (in italian)
Sorry, comments are closed for this article.