From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id DD61AE0099B; Wed, 3 Jun 2015 04:50:29 -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: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.212.175 listed in list.dnswl.org] Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 3997CE00974 for ; Wed, 3 Jun 2015 04:50:26 -0700 (PDT) Received: by wibdt2 with SMTP id dt2so9547533wib.1 for ; Wed, 03 Jun 2015 04:50:25 -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=pwx1xdCFXI+Cs3jlBVrV1/42TSKkpgx6xzBaTISTsi8=; b=l9dO92WAp3SK6i17AJlIrAV36Hvsu0FEEKaW6hxtrMtysmlz2rQzhpmp/Oje5pnuLx Cp4hL+K4jIx6Mt25b4c3yWYG3h7e6lHP98tkmhxHN9BCjiRTrvQWOgX6xmHV7bIUoRa5 1I9mhZ2lreVAnRt5FPT8bPI8rSyJxByCVS5LC5GV8ZNVJqgZ00E8NzPdBQlJX4LIJQUB pkZZXpty7N/4Rl7WFZxfuYRfHM+LE4jfp6OO03M7rw++oZbriO+Pdr7C4QAlPbZgO98K zO+1dytqjtMbHXNRa8K/zkmSDG3XKD9dMvCwEW8W6OReyp+4ITO+mYNc/OeF2fn03/Dv xq0A== X-Gm-Message-State: ALoCoQn0PIPDiYbL9uZwYDBFFoCS15SMu+QnshJ+N4jazkXgLXnDKkq0ls8yLe5FvTC7619C3s1F X-Received: by 10.194.59.46 with SMTP id w14mr42703652wjq.106.1433332225723; Wed, 03 Jun 2015 04:50:25 -0700 (PDT) Received: from [192.168.2.168] ([83.217.123.106]) by mx.google.com with ESMTPSA id l6sm748975wjz.4.2015.06.03.04.50.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 04:50:24 -0700 (PDT) Message-ID: <556EEA00.9060202@intel.com> Date: Wed, 03 Jun 2015 12:50:24 +0100 From: Michael Wood User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Damian, Alexandru" , Paul Eggleton References: <10463429.tEhaCQsaL4@peggleto-mobl.ger.corp.intel.com> <29860128.xIv3j5I9NJ@peggleto-mobl.ger.corp.intel.com> In-Reply-To: Cc: "toaster@yoctoproject.org" Subject: Re: [review-request] adamian/20150515_fix_table_header 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, 03 Jun 2015 11:50:29 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit If you're still really sure this is a good idea you will need to fix the current regressions introduced in the front end code which consumes these APIs. - New build button doesn't work and New build button changes libtoaster ctx vars which leak a project change into other users of this value - Layerdetails page doesn't work Maybe a better way round this problem is to make a urls.py scanner which generates a js file, then we essentially have a client side reverse() function useable from js e.g. import toastergui.urls as urls import re args_regex = re.compile(r"(\(\?P\<(.*?)\>.*?\))") for url in urls.urlpatterns: args = args_regex.findall(url.regex.pattern) js_url = url.regex.pattern for arg in args: js_url = js_url.replace(*arg) print js_url and so on... Michael On 02/06/15 12:32, Damian, Alexandru wrote: > I have pushed an extra patch that adds JSON support to all > Project-based URLS. > > To be remarked, the "importlayer" and "newproject" views are not > converted - even if the code "fits" - because they are not REST-style > APIs. > > The "unmanaged" versions, returning "landing_not_managed" are > converted just for illustrations, I am working on another patchset > that drops those views as part of the "unmanaged" code drop. > > > > > On Tue, Jun 2, 2015 at 10:11 AM, Damian, Alexandru > > wrote: > > > > On Mon, Jun 1, 2015 at 4:33 PM, Paul Eggleton > > wrote: > > On Monday 01 June 2015 14:49:18 Damian, Alexandru wrote: > > On Mon, Jun 1, 2015 at 2:43 PM, Paul Eggleton > > > > wrote: > > > > > > Hi Alex, > > > > > > On Friday 29 May 2015 14:58:57 Damian, Alexandru wrote: > > > > On Thu, May 21, 2015 at 11:25 AM, Michael Wood > > > > > > > > > wrote: > > > > > Conflating the web pages and the APIs into a single > URL pattern/schema > > > > > just doesn't make sense to me because: > > > > > > > > > > - We will have pages calling themselves with a > different parameter > > > > > > (e.g. > > > > > > > > the tables pages) > > > > > > > > ​And this is quite ok, since it will return the same > data, but in a > > > > different format. The whole idea of REST is to allow a > unique point of > > > > entry for each resource - so the table data in HTML > format and in JSON > > > > format will be at the same URI.​ > > > > > > > > > - This is not how REST frameworks are implemented in > any other > > > > > > application > > > > > > > > I've seen before > > > > > > > > ​I've taken the browsable-api from Django REST framework > as model; which > > > > has the same concept of exposing data in different > formats based on a > > > > GET > > > > parameter > > > > > > > > http://www.django-rest-framework.org/topics/browsable-api/​ > > > > > > > > > - In the future we may want to version the name-space e.g. > > > > > /api/1.3/projects/ > > > > > > > > And this approach will make it easier - we will only > have to port a > > > > > > single > > > > > > > set of URLs ​and not pairs for JSON and HTML content. > > > > > > > > > - Keeping the API self contained allows for greater > future flexibility > > > > > because it de-couples them from the page structure. > > > > > > > > ​Exactly my point - the HTML page structure is created > in templates, > > > > > > while > > > > > > > the data itself is built in the view context; this > approach enforces > > > > > > actual > > > > > > > encapsulation of data in the context, a issue we > confronted in the past. > > > > > > I'm not sure you guys are talking about the same things. > If this API is > > > only > > > for internal use by the application itself, fine - but if > it's also for > > > > ​This not just internal, but also external support. > > > > > external applications, we probably don't want to break > those external > > > applications if we have to change the page URL structure. > Unifying the > > > page URLs and REST API URLs will force us to keep them the > same, right? > > > > ​Yes, it will force us to keep them the same. It will also > ease the > > maintaining work.​ > > So what do we do when we need to change the URL structure for > the user-facing > side but preserve the API for existing applications? > > > ​My plan is to drop support for ​current API should the URL > structure of the toastergui change in radical ways. This is way > less drastic than it sounds - > > The reasoning is: since this is a REST API, it closely reflects > the inner concepts and objects that Toaster manipulates. We're > going to radically change the URL structure only if the way that > Toaster operates changes dramatically. At that point, maintaining > support for a backward-compatible way is going to be a very > difficult affair, anyway - we already have the experience with the > SimpleUI/separate API that we've just deleted. > > Also, if we going to alter the Toaster capabilities in a > significant way that impacts the URL structure, the existing code > in ToasterGUI application is not going to cut it - at this point, > is going to be far easier to add a new application (e.g. > toastergui2 ) to hold new code which can expose a different URL > structure if needed. > > So, in short, if the URL structure needs changing, and we need to > support a backward compatible API, the changes are going to > happen in a new application. > > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > > > > -- > Alex Damian > Yocto Project > SSG / OTC > > > > > -- > 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. >