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
<[email protected] <mailto:[email protected]>> wrote:
On Mon, Jun 1, 2015 at 4:33 PM, Paul Eggleton
<[email protected]
<mailto:[email protected]>> wrote:
On Monday 01 June 2015 14:49:18 Damian, Alexandru wrote:
> On Mon, Jun 1, 2015 at 2:43 PM, Paul Eggleton
<[email protected]
<mailto:[email protected]>
> > 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
<[email protected] <mailto:[email protected]>
> > >
> > > 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.
--
_______________________________________________
toaster mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/toaster
