Re: [review-request] adamian/20150515_fix_table_header

[Michael Wood <michael.g.wood@intel.com>]

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 
> <alexandru.damian@intel.com <mailto:alexandru.damian@intel.com>> wrote:
>
>
>
>     On Mon, Jun 1, 2015 at 4:33 PM, Paul Eggleton
>     <paul.eggleton@linux.intel.com
>     <mailto:paul.eggleton@linux.intel.com>> wrote:
>
>         On Monday 01 June 2015 14:49:18 Damian, Alexandru wrote:
>         > On Mon, Jun 1, 2015 at 2:43 PM, Paul Eggleton
>         <paul.eggleton@linux.intel.com
>         <mailto:paul.eggleton@linux.intel.com>
>         > > 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
>         <michael.g.wood@intel.com <mailto:michael.g.wood@intel.com>
>         > > >
>         > > > 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.
>