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

[Barros Pena, Belen]

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
> 
>