From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 7D5E2E009B8; Wed, 15 Apr 2015 04:37:54 -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 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.171 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 58AD1E0079F for ; Wed, 15 Apr 2015 04:37:51 -0700 (PDT) Received: by widdi4 with SMTP id di4so56657279wid.0 for ; Wed, 15 Apr 2015 04:37:50 -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=Iupzsf/SSSjO3Mr3zdqGNAtJEf8E/YBfeIz4WZFr2x8=; b=GxtxWPaYH3HP0zn+rFPToaraiGsqLfOWJUcdAGvmhaHa7GsaMpeF2Wxpqs/vbiAKmp Woo+WWgJaqTh7Z9mgjQULMEZiIhlYhNf2AXloP1Gad9zSJfdYQW9VDuda2mHOGeEEF4c vZyF7Bu52C9rA3UmM2JZjP8Kf+i86m14j9ycxSY3PpKQri+MdSyu16uGVmk9I/ywcJ7X SnYetGUiNCWGvWRTZJDlnV8uqUPwjsVQ4M1llf8VgJFw1dVBJRJytOYAiBWEdEg92hJO EtJRlaovC9G8N3ERB3kEYb6ch93ayrGRCWPo2rCF3Lg12rHc7KYn1j0BykBGk5dgDokN M2qA== X-Gm-Message-State: ALoCoQmOniFDVk9U/glrFmuN4BJ27itxuj2XKeEyhX9Xctl7yO+fBSskb09BYFeIxlva2wdz/Bgr X-Received: by 10.181.13.140 with SMTP id ey12mr14531556wid.44.1429097870776; Wed, 15 Apr 2015 04:37:50 -0700 (PDT) Received: from [192.168.2.119] ([83.217.123.106]) by mx.google.com with ESMTPSA id gt4sm6831588wib.21.2015.04.15.04.37.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 04:37:50 -0700 (PDT) Message-ID: <552E4D8D.7020405@intel.com> Date: Wed, 15 Apr 2015 12:37:49 +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> In-Reply-To: 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: Wed, 15 Apr 2015 11:37:54 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. >