[Toaster] [review-request] adamian/20150515_fix_table_header
Damian, Alexandru
alexandru.damian at intel.com
Wed Jun 3 07:33:40 PDT 2015
On Wed, Jun 3, 2015 at 12:50 PM, Michael Wood <michael.g.wood at intel.com>
wrote:
>
> 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
>
Yep, working on these.
>
> 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...
>
Great idea, I already struggled with this to generate URLs for automated
HTML5 validation. I'll implement something like this and dump it in a
context in base.html.
>
> 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.
>>
>>
> ---------------------------------------------------------------------
> 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.
>
--
Alex Damian
Yocto Project
SSG / OTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20150603/ba0e61db/attachment-0001.html>
More information about the toaster
mailing list