[Toaster] [RFC] Tables rework - michaelw/toaster-tables-poc

[Barros Pena, Belen]

Hi Michael,

Thanks for this. I have a couple of questions, if that's ok.

1. Can you share some context about what is prompting this refactoring of
the front-end code? I know the background because I talk to you all the
time, but it might be useful to other people on the list.

2. Can you provide more details about the "easy switch path"? :) When
would be a good time to do it, what kind of extra QA work would be
required (if any), etc

3. Do you think this approach can be expanded to the other UI components
(filters, sorting, edit values in forms, layer dependencies modal dialogs,
type ahead, etc)? Do you have a full list of what those components would
be? How much work / time will it take to create them and making the
switch, etc... 

Sorry for all the questions: I am keen on doing this so that we have a
solid foundation for the impending feature creep, but I am having some
trouble picturing how much time / effort is involved.

Thanks!

Belén 

On 26/03/2015 18:21, "Michael Wood" <michael.g.wood at intel.com> wrote:

>Here is the current WIP of the proof of concept of the Tables widget for
>toaster
>
>http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=michaelw/toa
>ster-tables-poc
>( http://tinyurl.com/op63pgj )
>
>
>I've tried to prefix/postfix 'poc' to make it easier to identify which
>are for the proof of concept
>
>Brief overview of the files/changes:
>
>----------------------
>poc_view.py:
>
>Table(View):
>     - Handles the HTTP requests to get the table data
>     - Adds some basic caching (future - this can be tied into the
>request but for now is just global)
>
>
>ToasterTable(object):
>     - Adds a base class for common table functionality
>     - A lot of this is bringing in all the parts we already have in
>views.py and standardising them in a single class
>     - In many tables we have what I've named "static data" this is
>where we have a column that contains html data, for example a button.
>     - Outputs the data for the page requested as a JSON document
>
>
>RecipeTable(ToasterTable):
>     - Example of a table which has static data
>
>LayersTable(ToasterTable):
>     - Example of a simple table
>
>----------------------
>
>tables.js:
>     - This consumes the table data
>     - Adds handlers for all the table chrome buttons
>     - Implements the add/remove columns
>     - Implements paging
>
>----------------------
>
>table-poc.html:
>     - Template that just contains the html for the table layout (i.e.
>search bar, table, buttons etc)
>     - can be considered the same as conflating the "basetable_top.html"
>+ "basetable_bottom.html" templates
>
>----------------------
>
>generic-table-page-poc.html:
>     - This is a normal table page in toaster with navigation, zone
>alert and which includes the table-poc.html template the context
>variable table_name is passed into this template to select which table
>to display
>
>----------------------
>
>two-tables-poc.html:
>     - Exactly the same as generic-table-page-poc.html (above) but has
>two tables in it.
>
>----------------------
>
>changes to urls.py:
>     - Add the poc-table this calls into to Table(View) to handle the
>requests made from the ajax calls (could be renamed xhr_table for
>consistency)
>     - Add urls for the test pages: /layers-poc/  and /recipes-poc/ and
>/two-tables-poc/ note that they don't need their own views defined
>because the only thing changing is the table_name and that's passed in.
>
>----------------------
>
>Notes:
>
>The whole lot is 642 lines which means the maintenance burden shouldn't
>be too high
>There's a fairly easy path to switching our existing tables - one at a
>time if needed
>There are bugs and features missing - This is just the proof of concept!
>
>Thanks,
>
>Michael
>
>
>
>
>
>
>
>
>
>-- 
>_______________________________________________
>toaster mailing list
>toaster at yoctoproject.org
>https://lists.yoctoproject.org/listinfo/toaster