[Toaster] [review-request] reconcile non-manage-mode landing classes [6483]

[Damian, Alexandru]

Hi David,

In some parts of the project, we build URLs dynamically from JS because we
don't know what the user will input there. To build the final URLs we need
the base address to which an ID is appended, and the base was provided by
the entries deleted in your patch

See the follow-up patch that brings back those URLs with different name.

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=adamian/20150309_bugz&id=4004aebb1b505967410494ed152b44eab0bf6cb4

Cheers,
Alex

On Wed, Mar 11, 2015 at 3:53 PM, Reyna, David L (Wind River) <
david.reyna at windriver.com> wrote:

>  Hi Alex,
>
>
>
> > “This patch breaks a number of pages due to removal of "url()" entries
> that were used to build valid URLs in Javascript.”
>
>
>
> My patch did remove two URLs. I did so because the view class they point
> to require an additional parameter, and thus these URLs fail when used, as
> Belen’s test case revealed.
>
>
>
>   - url(r'^layer/$', 'layerdetails', name='layerdetails'),
>
>   - url(r'^project/$', 'project', name='project'),
>
>
>
> Are you saying that they are required for other reasons, even though they
> are wrong? I am curious how they affected “building valid URLs in
> Javascript”.
>
>
>
> - David
>
>
>
> *From:* Damian, Alexandru [mailto:alexandru.damian at intel.com]
> *Sent:* Monday, March 09, 2015 5:01 AM
> *To:* BARROS PENA, BELEN
> *Cc:* Reyna, David; toaster at yoctoproject.org
> *Subject:* Re: [Toaster] [review-request] reconcile non-manage-mode
> landing classes [6483]
>
>
>
> Hi,
>
> This patch breaks a number of pages due to removal of "url()" entries that
> were used to build valid URLs in Javascript.
>
> I've taken this patch with a subsequent patch fixing this issue.
>
>   Thanks,
>
> Alex
>
>
>
> On Fri, Feb 27, 2015 at 1:17 PM, Barros Pena, Belen <
> belen.barros.pena at intel.com> wrote:
>
> Thanks, David.
>
> This seems to work for me.
>
> Cheers
>
> Belén
>
>
> On 27/02/2015 09:08, "Reyna, David" <david.reyna at windriver.com> wrote:
>
> >Hi Belén,
> >
> >Thanks to your re-opening this defect I have analyzed the managed mode
> >URLs, view classes, and their non-managed landing classes, and I
> >discovered many mismatches. This patch addresses them.
> >
> >   git push -f poky-contrib dreyna/landing_not_managed_6483_v2
> >
> >For the three mismatches that you found, here are the root causes:
> >
> >Mismatch class parameters versus landing wrapper:
> >
> >http://127.0.0.1:8000/toastergui/project/<project_id>/configuration
> ><http://127.0.0.1:8000/toastergui/project/<project_id>/configuration>
> >  http://127.0.0.1:8000/toastergui/project/<project_id>/builds
> >Dead URL:
> >  http://127.0.0.1:8000/toastergui/layer/<layer_id>/
> >
> >Here are the details:
> >
> >1) Dead URL¹s
> >
> >There are two URL¹s that are obsolete and replaced by newer calls. I have
> >removed them both since they are wrong.
> >
> >
> >url(r'^layer/$', 'layerdetails', name='layerdetails'),
> >
> >url(r'^project/$', 'project', name='project'),
> >
> >In both cases the newer view classes require a layerid/pid. Here are the
> >adjacent and real URLs.
> >
> >  url(r'^layer/(?P<layerid>\d+)/$', 'layerdetails', name='layerdetails'),
> >  url(r'^project/(?P<pid>\d+)/$', 'project', name='project'),
> >
> >2) Mismatch parameter lists between classes and their landing wrappers
> >
> >The ³l² ones are the landing wrappers. These are now matched with their
> >respective real class.
> >
> >   def projectconf(request, pid):
> >l  def projectconf(request):
> >   def projectbuilds(request, pid):
> >l  def projectbuilds(request):
> >   def xhr_configvaredit(request, pid):
> >l  def xhr_configvaredit(request):
> >
> >3) Wrapper class with no real class
> >
> >The class ³targetdetails² exists as a wrapper but apparently the real
> >class was removed. I have deleted it.
> >
> >4) Managed class (and wrapper landing page) that is not called by anything
> >
> >The class ³build_artifact² is not called by anything, and appears to be
> >superseded by ³build_artifact_storage_dir².
> >
> >I propose that we keep both until the class owner formally deletes them.
> >
> >- David
> >
> >
>
>
>
>
> --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>



-- 
Alex Damian
Yocto Project
SSG / OTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20150311/0c4b49dd/attachment-0001.html>