On Wed, Jun 3, 2015 at 12:50 PM, Michael Wood <[email protected]> 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 < >> [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. >> >> > --------------------------------------------------------------------- > 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
-- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
