On 05/25/2011 11:45 PM, Matt Wagner wrote:
Hi,
Since we were somewhat blocked on having functional tables in the
filter views, I went ahead and made some changes. This hardly
completes #1579, but it should get us moving.
I added a quick bit of JS to get the Select All / Select None toggle
working, but it doesn't work reliably since it binds on
document.ready and then we make all sorts of XHR calls which seem to
cause these to come unbound. Diagnosing this felt like too much of a
tangent for now.
The search, saved view dropdown, 'Save and Share', and filter
elements are all just non-functional placeholders for the time
being.
Best, Matt _______________________________________________
aeolus-devel mailing list aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
Hi Matt,
just a couple of notes. Ken, shout if something in following text is
wrong. This is just my notion of how could filter view look like, and it
can be completely wrong, so don't take me too serious:
- filter table should be universal helper (reusable in all filter views)
which generates html table and supports all required features specified
by Ken & Jonell
- generated html table will be w/o JS, if user has JS enabled,
completely different table will be used (slickgrid)
- filter_table could be something similar to existing paginated_table
helper which we still have in application_helper.rb file (of course much
nicer), but w/o JS. Or it can be completely different but should allow
us to generate well-arranged filter views. Maybe something like this:
filter_table(@header_hash, @records, opts) do |rec|
# block which generates haml chunk for one row
%td
rec.name
%td
rec.instances.count
...
end
This is not review nor NACK of your patch. The patch can surely be
pushed after proper review. I just don't think we should waste much time
with working on something what will go away once we get
specs/requirements and will implement a universal filter table.
Jan