From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 7B5F9E00997; Tue, 28 Apr 2015 10:38:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, WEIRD_PORT autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.212.179 listed in list.dnswl.org] * 0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id C94ABE00932 for ; Tue, 28 Apr 2015 10:38:17 -0700 (PDT) Received: by wizk4 with SMTP id k4so149881100wiz.1 for ; Tue, 28 Apr 2015 10:38:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lH6Z6xlD5YmYoExt9joJttV4YfyF/Fg0Gtg88nz3wfA=; b=KZowIQyCtpm4MdujTt5wC3WAF0FpRYil+b4YQ4sRkad2y5Y6T9cVL20D8B3TYL5dDb /f1rYbXrtWpx7vDJj7VLdK29aZ5+iMYTt0NEaXGlZuEJAnoH7l2vvw8mdM4JUq88/5aO IVXZusN68Xuxw4hdSdkjPj48EJfiRIRlHHQmYEcWPzZ4RsgzphWol/6b8RJwZiEPSvPR Plj/qKbCGPkFqgCd3iYWDlb7Gn4RN34j7wlw7nWnYoPKMe1RvQOS2Boik90T6XGYGVTl DniEHORGM8/2VeBbdZ2zRvcHTHAwtaK3/d+vnkCNwLX+7/IMJroIG1BQg37O58YgGvAl ljgQ== X-Gm-Message-State: ALoCoQmNDn+YIvnh/d57y4nLaWNHn6gQ9xWqdmwGgtzEHwS4qWAxi6SAt46a2yQTcKPkguZG78Kd X-Received: by 10.180.109.136 with SMTP id hs8mr31585008wib.73.1430242696918; Tue, 28 Apr 2015 10:38:16 -0700 (PDT) Received: from [192.168.2.82] ([83.217.123.106]) by mx.google.com with ESMTPSA id u6sm35201810wjy.13.2015.04.28.10.38.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 10:38:16 -0700 (PDT) Message-ID: <553FC587.5090703@intel.com> Date: Tue, 28 Apr 2015 18:38:15 +0100 From: Michael Wood User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Damian, Alexandru" References: <55144E33.9020103@intel.com> <55156050.6000402@intel.com> <552E4D8D.7020405@intel.com> In-Reply-To: <552E4D8D.7020405@intel.com> Cc: "toaster@yoctoproject.org" Subject: Re: [RFC] Tables rework - michaelw/toaster-tables-poc X-BeenThere: toaster@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Web based interface for BitBake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 17:38:23 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit New branch with the toaster table being a subclass of the django View as discussed michaelw/toaster-tables-poc-v2 e.g. http://127.0.0.1:8000/toastergui/two-tables-poc/ http://127.0.0.1:8000/toastergui/recipes-poc/ http://127.0.0.1:8000/toastergui/layers-poc/ Note: the data is all just sample queries for demonstration known issue that the two-tables-poc rows selector changes both tables there are some duplicate ids that I need to fix Michael On 15/04/15 12:37, Michael Wood wrote: > On 14/04/15 16:52, Damian, Alexandru wrote: >> Hi, >> >> I've taken a look at the POC, looks pretty good - I have some >> comments below. >> >> * I am not sure why you re-implement the casting of the correct >> table type instead of using language inheritance; I'm referring to: >> >> table_new = tables_available[table_name] >> table_kargs = {'project_id' :request.session['project_id']} >> table = table_new(**table_kargs) >> >> ... >> tables_available = { >> 'recipes' : RecipeTable, >> 'layer' : LayersTable, >> # ...and so on >> } >> >> Instead of just directly sub-classing Table > ToasterTable > >> RecipeTable; >> This approach would ensure proper endpoints directly in the template >> view class, instead having to manually sync the /tables_available/ >> with the defined classes and magic keywords for the table name. Also, >> see next point. >> > > Thanks yeah I think I see what you're saying, basically have > ToasterTable subclass the django View so then each table will be a > view. Negating the need to have a class in-between. I'll add this to > the todo for a V2. > >> >> * I understand the need to have different endpoints for HTML and >> JSON returns; I would argue that these are just different views of >> the same object - the table object, also see the last point - and in >> REST fashion , they should have related URLs. >> >> I.E instead of using /layers-poc// and /table-poc/layers/ as >> HTML/JSON endpoints, I would use /layers-poc// and /layers-poc/.json/ >> . This ties into the inheritance point above, as the Toaster.get() >> can be written to return HTML/JSON based on the calling endpoint. >> > > I can see what you're saying, however I think that it's more important > that we have smaller modules with single responsibility / logical > cohesion for the two separate responsibilities of rendering a page vs > API JSON response. > > For example we have a page like the layerdetails page that loads the > Machines table and Recipes table, the modules in that page you'll be > accessing would have a whole load of code in them which is for > rendering a page that is nothing to do with the layerdetails page. > >> >> * There is not clear to me how the cache invalidation happens. >> Considering that frequently we change the database data through the >> Bitbake interface, as opposed to the user interface, we need some >> sort of policy on cache invalidation. >> > > It invalidates after a few seconds see > https://docs.djangoproject.com/en/1.7/topics/cache/#django.core.cache.caches > > It was just an example of something that we could look further into. > > >> >> * I like the concept of using AJAX to refresh the table content; I am >> a bit concerned about lack of graceful degradation, e.g. what the >> user sees if there is no JS enabled on the machine. I would suggest >> rendering the initial data content (in some way) in HTML and enable >> minimal pagination/search/interaction links to run using classic HTML >> href requests (this implementation needs to provide minimum >> navigation, and does not need be complete); the layer using AJAX to >> refresh the data should come on top of the basic functionality - e.g. >> change the links from HTML href to javascript actions - as to provide >> the better experience if JS is enabled; but we shouldn't penalize our >> users for not using JS. >> > > I don't see a need to support no javascript enabled users. Toaster > currently requires Javascript so nothing changes here. > > >> I'm not touching minor issues as this is clearly a POC for opening up >> the discussion and not a ready-to-drop replacement. >> >> >> Thank you and keep up the impressive work that went into this ! >> >> Cheers, >> Alex >> >> On Fri, Mar 27, 2015 at 1:51 PM, Michael Wood >> > wrote: >> >> On 27/03/15 11:44, Barros Pena, Belen wrote: >> >> 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. >> >> >> Sure, >> >> Currently we have a collection of defined ways to describe a table >> in Toaster on the back end and the front end. >> The first purpose is to consolidate this into a single object on >> the back-end and a single handler on the front end, doing this >> will hopefully mean fewer bugs and consistency in behaviour and >> look across all the tables. >> >> It also allows us to add features that can then be utilised across >> all tables, such as the one included in this patch which is an >> improvement to the user experience by avoiding having to do a page >> reload for every table operation. I also think it improves the >> speed of the page loading because we're only exposing the fields >> from the database that we require rather than an object that >> represents all the data and has an easy way to implement caching. >> >> >> 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 >> >> Don't think there would be any extra QA work. If anything it may >> be simpler because we can write some tests that check the JSON >> output. The easy switch path is that it can be done gradually if >> we want. The best time would probably be after 1.8 -- nothing >> stopping us branching and starting now. >> >> >> 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... >> >> No I don't have a list, (filters will be part of the table work I >> just didn't implement them for the POC) It'd be good to make one, >> then a better time estimate could be made. It took around 4 days >> to do the table stuff, but that included a lot of experimenting >> and reading around it. >> >> Yes I think we could expand this approach to other components, we >> have a few done already on the client side; typeahead and the >> layer dependency modal mechanism. >> We would need to do an audit and workout what other common >> components could be done. >> >> >> >> 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" > > 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@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/toaster >> >> >> -- _______________________________________________ >> toaster mailing list >> toaster@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/toaster >> >> >> >> >> -- >> Alex Damian >> Yocto Project >> SSG / OTC >> >> --------------------------------------------------------------------- >> Intel Corporation (UK) Limited >> Registered No. 1134945 (England) >> Registered Office: Pipers Way, Swindon SN3 1RJ >> VAT No: 860 2173 47 >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >