[Toaster] [review-request] adamian/20150515_fix_table_header
Michael Wood
michael.g.wood at intel.com
Wed Jun 3 04:50:24 PDT 2015
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 at intel.com <mailto:alexandru.damian at intel.com>> wrote:
>
>
>
> On Mon, Jun 1, 2015 at 4:33 PM, Paul Eggleton
> <paul.eggleton at linux.intel.com
> <mailto:paul.eggleton at 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 at linux.intel.com
> <mailto:paul.eggleton at 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 at intel.com <mailto:michael.g.wood at 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.
>
More information about the toaster
mailing list