DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Reyna, David]

[-- Attachment #1: Type: text/plain, Size: 6129 bytes --]

Hi all,

I believe that I have completed the Recipe Details page, as per Belen's requirements. 

I unfortunately do not have my commit credentials setup as I am moving to a more SSH-friendly host. I hope to have that in place Monday. In the meantime I would like to do an informal review request, with the following content.

1) The diffs for the model and view are attached, plus "recipes.html" and "recipe.html" as normal files since they are new files. (FYI, "recipes.html" _plural_ is a fixed version of the previous template "recipe.html" _singular_).

2) Below is a proposed formal example "review request" with "Development notes" and "Test Instructions". As per our discussion, this is based on Wind River's review request process. The test instructions in particular are intended to (a) demonstrate what I as a developer did to confirm that it is working, (b) provide an easy way to compare the scope of testing verses the original design document, and (c) provide simple and complete instructions for a Tester who most likely will not be as familiar with the feature as the developers. Hopefully, such instructions can be then later be incorporated into a regression test.

3) This is my first review for Toaster. I will certainly be very interested in any Yocto standards that I may not have addressed.

4) My next steps are to get my host SSH set up, start looking at Ravi's code, plus try to understand why the URL links in the tables do not have normal URL coloring.

Thanks,
David

+++++++++++++++++++++++++++++++++++++++++
[Review Request] 4299 "recipes: View detailed information about a recipe"

Development Notes
=================

The implementation of the recipe "outcome" highlighting is done using a helper method in the "Task" class, which returns the CSS color style for the respective "outcome" value.

While it is not ideal to mix HTML fragments in class definitions, this choice was made because Django templates do not really support using conditionals to set local variables, and we want to avoid duplication of the table code for each case. The possible alternate implementations include custom filters, custom tags, or Javascript, each with their own tradeoffs.


Test Instructions
=================

1) Create a default Yocto project (qemux86), and start the Toaster.

  $ source poky/oe-init-build-env
  $ source toaster start
  $ bitbake core-image-minimal
  $ xdg-open http://localhost:8000/

2) Select the "core-image-minimal" build link

3) Select the "Recipes" link in the left sidebar

Observe that the recipes are listed in a table, and that each recipe name is a live URL link.

4) Click on the "busybox" recipe name link

Observe:
  a) The "breadcrumbs" at the top include is in this form form, and that all but the last entry are live links.
  
	     All builds > core-image-sato atom-pc (<time>) > Recipes > busybox_1.21.1-r0
	 
  b) The informational sidebar on the right contains information pertinent to the "busybox" recipe, 
  
  c) Some 14 task entries, starting with "do_patch" and ending with "do_build" If you hover over a recipe name, you will see a question-mark icon appear, and if you hover over that a tooltip will appear for that task.
  
  d) Any task outcome of "Succeeded" should be in normal black. Any outcome of "Failed" (not likely) would be red, and all other tasks should be in grey.
  
  e) The layer description will indicate the layer "meta", and the recipe will point to "busybox_1.21.1.bb".

  f) The right-hand sidebar about busybox is still present.
  
5) Observe that "Packages" link. It should have an appended value like "(4)". Now click on this link.

Observe:
  a) The number of packages matches the previous number in parenthesis.
  
  b) Each package has a version and a size. The size may be zero.
  
  c) Note that if you hover on a package name, it will reveal a URL of the following form. This link should take you to the corresponding package detail page once you have the fix for 4328 pulled.
  
	localhost:8000/gui/build/<number>/package/<number>  

6) Observe that "Build Dependencies" link. It should have an appended value like "(0)". Now click on this link.

Observe:
  a) No dependencies appear, and you get a message of the form:
  
  "$RECIPE_NAME_VERSION has no build dependencies."
 
7) Observe that "Reverse build dependencies" link. It should have an appended value like "(1)". Now click on this link.

Observe:
  a) The number of packages matches the previous number in parenthesis.
  
  b) The recipe dependency should be "packagegroup-core-boot", 
  
  c) There should be a respective version displayed, for example "1.0-r11"
 
  d) If you hover on the recipe name, it will reveal a URL of the following form. This link should take you to the corresponding recipe detail page.
  
	localhost:8000/gui/build/<number>/recipe/<number>

8) Click the breadcrumb "Recipes" at the top, locate the "gdbm" recipe, and select it.

9) Observe that "Packages" link. It should have an appended value like "(0)". Now click on this link.

Observe:
  a) No packages appear, and you get a message of the form:
  
  "$PACKAGE_NAME_VERSION does not build any packages."
 
10) Observe that "Build dependencies" link. It should have an appended value like "(2)". Now click on this link.

Observe:
  a) The number of build dependencies matches the previous number in parenthesis.
  
  b) The recipe dependency should have values like "gettext-native" and "libtool-cross". 
  
  c) There should be a respective versions displayed for each dependency.
 
  d) If you hover on a recipe name, it will reveal a URL of the following form. This link should take you to the corresponding recipe detail page.
  
	localhost:8000/gui/build/<number>/recipe/<number>

11) Observe that "Reverse build dependencies" link. It should have an appended value like "(0)". Now click on this link.

Observe:
  a) No reverse dependencies appear, and you get a message of the form:
  
  "$RECIPE_NAME_VERSION does not build any packages."
 
- David


[-- Attachment #2: models.py.diff --]
[-- Type: application/octet-stream, Size: 668 bytes --]

diff --git a/bitbake/lib/toaster/orm/models.py b/bitbake/lib/toaster/orm/models.py
index b45ca82..dd11808 100644
--- a/bitbake/lib/toaster/orm/models.py
+++ b/bitbake/lib/toaster/orm/models.py
@@ -123,6 +123,15 @@ class Task(models.Model):
     message = models.CharField(max_length=240)
     logfile = models.FilePathField(max_length=255, blank=True)
 
+    def outcome_highlight(self):
+        if   self.outcome==Task.OUTCOME_EXISTING:
+            ret=''
+        elif self.outcome==Task.OUTCOME_FAILED:
+            ret='class=error'
+        else:
+            ret='class=muted'
+        return ret
+
     class Meta:
         ordering = ('order', 'recipe' ,)
 

[-- Attachment #3: views.py.diff --]
[-- Type: application/octet-stream, Size: 1564 bytes --]

diff --git a/bitbake/lib/toaster/toastergui/views.py b/bitbake/lib/toaster/toastergui/views.py
index a918c25..d5f9c68 100644
--- a/bitbake/lib/toaster/toastergui/views.py
+++ b/bitbake/lib/toaster/toastergui/views.py
@@ -281,9 +281,20 @@ def recipe(request, build_id, recipe_id):
     template = "recipe.html"
     if Recipe.objects.filter(pk=recipe_id).count() == 0 :
         return redirect(builds)
+        
+    object = Recipe.objects.filter(pk=recipe_id)[0]
+    layer_version = Layer_Version.objects.filter(pk=object.layer_version_id)[0]
+    layer  = Layer.objects.filter(pk=layer_version.layer_id)[0]
+    tasks  = Task.objects.filter(recipe_id = recipe_id).filter(build_id = build_id)
+    packages = Package.objects.filter(recipe_id = recipe_id).filter(build_id = build_id)
+
     context = {
-            'build' : Build.objects.filter(pk=build_id)[0],
-            'object' : Recipe.objects.filter(pk=recipe_id)[0],
+            'build'   : Build.objects.filter(pk=build_id)[0],
+            'object'  : object,
+            'layer_version' : layer_version,
+            'layer'   : layer,
+            'tasks'   : tasks,
+            'packages': packages,
     }
     return render(request, template, context)
 
@@ -344,7 +355,7 @@ def tasks(request, build_id):
     return render(request, template, context)
 
 def recipes(request, build_id):
-    template = 'recipe.html'
+    template = 'recipes.html'
     mandatory_parameters = { 'count': 100,  'page' : 1};
     retval = _verify_parameters( request.GET, mandatory_parameters )
     if retval:

[-- Attachment #4: recipes.html --]
[-- Type: text/html, Size: 1507 bytes --]

[-- Attachment #5: recipe.html --]
[-- Type: text/html, Size: 9964 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Lerner, Dave]

Hi David,

I notice that you pluralized the recipe.html to recipes.html.  Doesn't that break the existing convention of singular for all templates?

What is your suggested naming convention for templates, singular vs plural?  If those conventions are settled on by the team, then we should apply that naming convention to the project before we create a number of other templates. 

What do others think of the template naming conventions?  
Dave


> -----Original Message-----
> From: Reyna, David
> Sent: Sunday, January 12, 2014 12:35 AM
> To: Damian, Alexandru (alexandru.damian@intel.com); belen.barros.pena@intel.com; Ravi
> Chintakunta (ravi.chintakunta@timesys.com); Lerner, Dave; Eggleton, Paul
> (paul.eggleton@intel.com)
> Cc: Reyna, David; toaster@yoctoproject.org
> Subject: DRY RUN [Review Request] 4299 "recipes: View detailed information about a
> recipe"
> 
> Hi all,
> 
> I believe that I have completed the Recipe Details page, as per Belen's requirements.
> 
> I unfortunately do not have my commit credentials setup as I am moving to a more SSH-
> friendly host. I hope to have that in place Monday. In the meantime I would like to do
> an informal review request, with the following content.
> 
> 1) The diffs for the model and view are attached, plus "recipes.html" and "recipe.html"
> as normal files since they are new files. (FYI, "recipes.html" _plural_ is a fixed
> version of the previous template "recipe.html" _singular_).
> 
> 2) Below is a proposed formal example "review request" with "Development notes" and
> "Test Instructions". As per our discussion, this is based on Wind River's review request
> process. The test instructions in particular are intended to (a) demonstrate what I as a
> developer did to confirm that it is working, (b) provide an easy way to compare the
> scope of testing verses the original design document, and (c) provide simple and
> complete instructions for a Tester who most likely will not be as familiar with the
> feature as the developers. Hopefully, such instructions can be then later be
> incorporated into a regression test.
> 
> 3) This is my first review for Toaster. I will certainly be very interested in any Yocto
> standards that I may not have addressed.
> 
> 4) My next steps are to get my host SSH set up, start looking at Ravi's code, plus try
> to understand why the URL links in the tables do not have normal URL coloring.
> 
> Thanks,
> David
> 
> +++++++++++++++++++++++++++++++++++++++++
> [Review Request] 4299 "recipes: View detailed information about a recipe"
> 
> Development Notes
> =================
> 
> The implementation of the recipe "outcome" highlighting is done using a helper method in
> the "Task" class, which returns the CSS color style for the respective "outcome" value.
> 
> While it is not ideal to mix HTML fragments in class definitions, this choice was made
> because Django templates do not really support using conditionals to set local
> variables, and we want to avoid duplication of the table code for each case. The
> possible alternate implementations include custom filters, custom tags, or Javascript,
> each with their own tradeoffs.
> 
> 
> Test Instructions
> =================
> 
> 1) Create a default Yocto project (qemux86), and start the Toaster.
> 
>   $ source poky/oe-init-build-env
>   $ source toaster start
>   $ bitbake core-image-minimal
>   $ xdg-open http://localhost:8000/
> 
> 2) Select the "core-image-minimal" build link
> 
> 3) Select the "Recipes" link in the left sidebar
> 
> Observe that the recipes are listed in a table, and that each recipe name is a live URL
> link.
> 
> 4) Click on the "busybox" recipe name link
> 
> Observe:
>   a) The "breadcrumbs" at the top include is in this form form, and that all but the
> last entry are live links.
> 
> 	     All builds > core-image-sato atom-pc (<time>) > Recipes > busybox_1.21.1-r0
> 
>   b) The informational sidebar on the right contains information pertinent to the
> "busybox" recipe,
> 
>   c) Some 14 task entries, starting with "do_patch" and ending with "do_build" If you
> hover over a recipe name, you will see a question-mark icon appear, and if you hover
> over that a tooltip will appear for that task.
> 
>   d) Any task outcome of "Succeeded" should be in normal black. Any outcome of "Failed"
> (not likely) would be red, and all other tasks should be in grey.
> 
>   e) The layer description will indicate the layer "meta", and the recipe will point to
> "busybox_1.21.1.bb".
> 
>   f) The right-hand sidebar about busybox is still present.
> 
> 5) Observe that "Packages" link. It should have an appended value like "(4)". Now click
> on this link.
> 
> Observe:
>   a) The number of packages matches the previous number in parenthesis.
> 
>   b) Each package has a version and a size. The size may be zero.
> 
>   c) Note that if you hover on a package name, it will reveal a URL of the following
> form. This link should take you to the corresponding package detail page once you have
> the fix for 4328 pulled.
> 
> 	localhost:8000/gui/build/<number>/package/<number>
> 
> 6) Observe that "Build Dependencies" link. It should have an appended value like "(0)".
> Now click on this link.
> 
> Observe:
>   a) No dependencies appear, and you get a message of the form:
> 
>   "$RECIPE_NAME_VERSION has no build dependencies."
> 
> 7) Observe that "Reverse build dependencies" link. It should have an appended value like
> "(1)". Now click on this link.
> 
> Observe:
>   a) The number of packages matches the previous number in parenthesis.
> 
>   b) The recipe dependency should be "packagegroup-core-boot",
> 
>   c) There should be a respective version displayed, for example "1.0-r11"
> 
>   d) If you hover on the recipe name, it will reveal a URL of the following form. This
> link should take you to the corresponding recipe detail page.
> 
> 	localhost:8000/gui/build/<number>/recipe/<number>
> 
> 8) Click the breadcrumb "Recipes" at the top, locate the "gdbm" recipe, and select it.
> 
> 9) Observe that "Packages" link. It should have an appended value like "(0)". Now click
> on this link.
> 
> Observe:
>   a) No packages appear, and you get a message of the form:
> 
>   "$PACKAGE_NAME_VERSION does not build any packages."
> 
> 10) Observe that "Build dependencies" link. It should have an appended value like "(2)".
> Now click on this link.
> 
> Observe:
>   a) The number of build dependencies matches the previous number in parenthesis.
> 
>   b) The recipe dependency should have values like "gettext-native" and "libtool-cross".
> 
>   c) There should be a respective versions displayed for each dependency.
> 
>   d) If you hover on a recipe name, it will reveal a URL of the following form. This
> link should take you to the corresponding recipe detail page.
> 
> 	localhost:8000/gui/build/<number>/recipe/<number>
> 
> 11) Observe that "Reverse build dependencies" link. It should have an appended value
> like "(0)". Now click on this link.
> 
> Observe:
>   a) No reverse dependencies appear, and you get a message of the form:
> 
>   "$RECIPE_NAME_VERSION does not build any packages."
> 
> - David

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Reyna, David]

I used "recipes.html" for the page listing all recipes, and "recipe.html" for the individual recipe detail page. I can use different naming of course.

- David

> -----Original Message-----
> From: Lerner, Dave
> Sent: Sunday, January 12, 2014 9:56 AM
> To: Reyna, David
> Cc: toaster@yoctoproject.org
> Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
> information about a recipe"
> 
> Hi David,
> 
> I notice that you pluralized the recipe.html to recipes.html.  Doesn't
> that break the existing convention of singular for all templates?
> 
> What is your suggested naming convention for templates, singular vs
> plural?  If those conventions are settled on by the team, then we
> should apply that naming convention to the project before we create a
> number of other templates.
> 
> What do others think of the template naming conventions?
> Dave
> 

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]

Hi David,

This is outstanding ! Thank you !

I have some comments about the form, not the content of the patch, which
should make future work a bit easier.

- Indeed, we use the pluralized name for pages showing an object list (i.e.
tables), and the singular for the detail page for the a single object.

- We can do patches over email, instead of git push, but it's harder to
work this way. However, the email patches should be proper git patches for
easy use.

You can get them like this:

$ git commit                  # you commit normally to git
$ git format-patch -n1   # you get a mailable version of the last patch
from git;
0001-patch-name-as-it-appears-in-subject-line.patch     # the command will
output the filename just written

Now, there are two options to send this file.
   - if sendmail, or any MTA for that matter, works on your machine, you
just do:
$ git send-email --to
toaster@yoctoproject.org0001-patch-name-as-it-appears-in-subject-line.patch
     # replace with the
file name just written

   - otherwise, open up your mail client, and copy/paste the contents of
the file written in the mail, starting line 6, or just after the empty line
after the Subject: line. Copy/paste the Subject: line content as your
Subject:. Send this email :).



- The test procedure is outstanding !  I think we should use it for all the
patches. For easier reference, I propose to get the test procedure in the
bugzilla item that the patch addresses, as a comment.
The patch commit message should reference the bugzilla issue like this:

[YOCTO #0000]          # replace with the real bugzilla issue number


Hope all of this makes sense :)

I'll get to review the content of the patches separately.

Cheers,
Alex



On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com>wrote:

> I used "recipes.html" for the page listing all recipes, and "recipe.html"
> for the individual recipe detail page. I can use different naming of course.
>
> - David
>
> > -----Original Message-----
> > From: Lerner, Dave
> > Sent: Sunday, January 12, 2014 9:56 AM
> > To: Reyna, David
> > Cc: toaster@yoctoproject.org
> > Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
> > information about a recipe"
> >
> > Hi David,
> >
> > I notice that you pluralized the recipe.html to recipes.html.  Doesn't
> > that break the existing convention of singular for all templates?
> >
> > What is your suggested naming convention for templates, singular vs
> > plural?  If those conventions are settled on by the team, then we
> > should apply that naming convention to the project before we create a
> > number of other templates.
> >
> > What do others think of the template naming conventions?
> > Dave
> >
>
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>



-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 4321 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 4694 bytes --]

Hi,

I have comments about the content of the patch, as well.

a). models.py; I am not very fond of having display code in the models,
because it breaks the MVC separation. The display code should live in the
templates, e.g.

    {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
{%endif%}

If this is repeated elsewhere, like in this particular case, you should
define a new tag in
./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns
the code:

@register.simple_tag
def task_outcome_highlight(task):
    if task.outcome == Task.OUTCOME_EXISTING:
        ret = ''
  .... etc ...

and then use it in the template:  {% task_outcome_highlight task %}

b). html format; please don't use tabs; use 4-space instead of a tab; this
makes for a nice consistency with the HTML code, and fits the HTML code in
page better.

c). recipe.html; please extend "basebuildpage.html" which fills in the
breadcrumb and all the layout for viewing pages in a build context. see
configvars.html for an example.

d). recipes.html; the latest versions of the basetable_top will
automatically generate correct table header based on the context
description; please don't include your own table header, but edit the page
context  to correctly set the table data; see the build view / build.html
as a how-to guide.

Hope this helps,
Alex






On Mon, Jan 13, 2014 at 12:42 PM, Damian, Alexandru <
alexandru.damian@intel.com> wrote:

> Hi David,
>
> This is outstanding ! Thank you !
>
> I have some comments about the form, not the content of the patch, which
> should make future work a bit easier.
>
> - Indeed, we use the pluralized name for pages showing an object list
> (i.e. tables), and the singular for the detail page for the a single object.
>
> - We can do patches over email, instead of git push, but it's harder to
> work this way. However, the email patches should be proper git patches for
> easy use.
>
> You can get them like this:
>
> $ git commit                  # you commit normally to git
> $ git format-patch -n1   # you get a mailable version of the last patch
> from git;
> 0001-patch-name-as-it-appears-in-subject-line.patch     # the command will
> output the filename just written
>
> Now, there are two options to send this file.
>    - if sendmail, or any MTA for that matter, works on your machine, you
> just do:
> $ git send-email --to toaster@yoctoproject.org0001-patch-name-as-it-appears-in-subject-line.patch      # replace with the
> file name just written
>
>    - otherwise, open up your mail client, and copy/paste the contents of
> the file written in the mail, starting line 6, or just after the empty line
> after the Subject: line. Copy/paste the Subject: line content as your
> Subject:. Send this email :).
>
>
>
> - The test procedure is outstanding !  I think we should use it for all
> the patches. For easier reference, I propose to get the test procedure in
> the bugzilla item that the patch addresses, as a comment.
> The patch commit message should reference the bugzilla issue like this:
>
> [YOCTO #0000]          # replace with the real bugzilla issue number
>
>
> Hope all of this makes sense :)
>
> I'll get to review the content of the patches separately.
>
> Cheers,
> Alex
>
>
>
> On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com>wrote:
>
>> I used "recipes.html" for the page listing all recipes, and "recipe.html"
>> for the individual recipe detail page. I can use different naming of course.
>>
>> - David
>>
>> > -----Original Message-----
>> > From: Lerner, Dave
>> > Sent: Sunday, January 12, 2014 9:56 AM
>> > To: Reyna, David
>> > Cc: toaster@yoctoproject.org
>> > Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
>> > information about a recipe"
>> >
>> > Hi David,
>> >
>> > I notice that you pluralized the recipe.html to recipes.html.  Doesn't
>> > that break the existing convention of singular for all templates?
>> >
>> > What is your suggested naming convention for templates, singular vs
>> > plural?  If those conventions are settled on by the team, then we
>> > should apply that naming convention to the project before we create a
>> > number of other templates.
>> >
>> > What do others think of the template naming conventions?
>> > Dave
>> >
>>
>> _______________________________________________
>> toaster mailing list
>> toaster@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/toaster
>>
>
>
>
> --
> Alex Damian
> Yocto Project
> SSG / OTC
>



-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 6686 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Reyna, David]

[-- Attachment #1: Type: text/plain, Size: 5836 bytes --]

Hi Alex,

(a) Models.py

> {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ... {%endif%}
Have you actually tried that code? I tried this first, but Django does not support it, as also reflected in many google searches on the subject.

I will move to trying a custom filter. I do hope that “Task.*” is defined for the context of the filter as well as the template.

(b) Ok, 4-space tabs it is!

(c) I explicitly removed "basebuildpage.html" because that content does not appear anywhere in the Recipe Details design document (as opposed to say Ravi’s Task document). I assumed that this was on purpose.
I will restore it then.
d) I see that Ravi used the basetable_top structure. I will adopt that as well.
(e) You wrote “Indeed, we use the pluralized name for pages showing an object list (i.e. tables), and the singular for the detail page for the a single object.”

Ok, I will stay with my current page names.

- David

From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
Sent: Monday, January 13, 2014 5:43 AM
To: Reyna, David
Cc: Lerner, Dave; toaster@yoctoproject.org
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

Hi,

I have comments about the content of the patch, as well.
a). models.py; I am not very fond of having display code in the models, because it breaks the MVC separation. The display code should live in the templates, e.g.

    {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ... {%endif%}
If this is repeated elsewhere, like in this particular case, you should define a new tag in ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns the code:
@register.simple_tag
def task_outcome_highlight(task):
    if task.outcome == Task.OUTCOME_EXISTING:
        ret = ''
  .... etc ...
and then use it in the template:  {% task_outcome_highlight task %}
b). html format; please don't use tabs; use 4-space instead of a tab; this makes for a nice consistency with the HTML code, and fits the HTML code in page better.

c). recipe.html; please extend "basebuildpage.html" which fills in the breadcrumb and all the layout for viewing pages in a build context. see configvars.html for an example.
d). recipes.html; the latest versions of the basetable_top will automatically generate correct table header based on the context description; please don't include your own table header, but edit the page context  to correctly set the table data; see the build view / build.html as a how-to guide.
Hope this helps,
Alex





On Mon, Jan 13, 2014 at 12:42 PM, Damian, Alexandru <alexandru.damian@intel.com<mailto:alexandru.damian@intel.com>> wrote:
Hi David,

This is outstanding ! Thank you !
I have some comments about the form, not the content of the patch, which should make future work a bit easier.
- Indeed, we use the pluralized name for pages showing an object list (i.e. tables), and the singular for the detail page for the a single object.

- We can do patches over email, instead of git push, but it's harder to work this way. However, the email patches should be proper git patches for easy use.

You can get them like this:

$ git commit                  # you commit normally to git
$ git format-patch -n1   # you get a mailable version of the last patch from git;
0001-patch-name-as-it-appears-in-subject-line.patch     # the command will output the filename just written
Now, there are two options to send this file.
   - if sendmail, or any MTA for that matter, works on your machine, you just do:
$ git send-email --to toaster@yoctoproject.org<mailto:toaster@yoctoproject.org> 0001-patch-name-as-it-appears-in-subject-line.patch      # replace with the file name just written
   - otherwise, open up your mail client, and copy/paste the contents of the file written in the mail, starting line 6, or just after the empty line after the Subject: line. Copy/paste the Subject: line content as your Subject:. Send this email :).


- The test procedure is outstanding !  I think we should use it for all the patches. For easier reference, I propose to get the test procedure in the bugzilla item that the patch addresses, as a comment.
The patch commit message should reference the bugzilla issue like this:
[YOCTO #0000]          # replace with the real bugzilla issue number

Hope all of this makes sense :)

I'll get to review the content of the patches separately.
Cheers,
Alex


On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com<mailto:david.reyna@windriver.com>> wrote:
I used "recipes.html" for the page listing all recipes, and "recipe.html" for the individual recipe detail page. I can use different naming of course.

- David

> -----Original Message-----
> From: Lerner, Dave
> Sent: Sunday, January 12, 2014 9:56 AM
> To: Reyna, David
> Cc: toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
> Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
> information about a recipe"
>
> Hi David,
>
> I notice that you pluralized the recipe.html to recipes.html.  Doesn't
> that break the existing convention of singular for all templates?
>
> What is your suggested naming convention for templates, singular vs
> plural?  If those conventions are settled on by the team, then we
> should apply that naming convention to the project before we create a
> number of other templates.
>
> What do others think of the template naming conventions?
> Dave
>
_______________________________________________
toaster mailing list
toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/toaster


--
Alex Damian
Yocto Project
SSG / OTC



--
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 15746 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 6766 bytes --]

David

My mistake on a). Indeed, the class names are not available in the
template.

The trick here is to use the constants through the object, because they
carry over. e.g.

{% if task.outcome == task.OUTCOME_FAILED %} ... etc

more details:
http://stackoverflow.com/questions/11221881/access-models-constants-from-templates-without-using-context-processors


Alex


On Mon, Jan 13, 2014 at 2:33 PM, Reyna, David <david.reyna@windriver.com>wrote:

>  Hi Alex,
>
>
>
> (a) Models.py
>
>
>
> > {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
> {%endif%}
>
> Have you actually tried that code? I tried this first, but Django does not
> support it, as also reflected in many google searches on the subject.
>
>
>
> I will move to trying a custom filter. I do hope that “Task.*” is defined
> for the context of the filter as well as the template.
>
>
>
> (b) Ok, 4-space tabs it is!
>
>
>
> (c) I explicitly removed "basebuildpage.html" because that content does
> not appear anywhere in the Recipe Details design document (as opposed to
> say Ravi’s Task document). I assumed that this was on purpose.
>
> I will restore it then.
>
> d) I see that Ravi used the basetable_top structure. I will adopt that as
> well.
>
> (e) You wrote “Indeed, we use the pluralized name for pages showing an
> object list (i.e. tables), and the singular for the detail page for the a
> single object.”
>
>
>
> Ok, I will stay with my current page names.
>
>
>
> - David
>
>
>
> *From:* Damian, Alexandru [mailto:alexandru.damian@intel.com]
> *Sent:* Monday, January 13, 2014 5:43 AM
> *To:* Reyna, David
> *Cc:* Lerner, Dave; toaster@yoctoproject.org
> *Subject:* Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
> detailed information about a recipe"
>
>
>
> Hi,
>
> I have comments about the content of the patch, as well.
>
> a). models.py; I am not very fond of having display code in the models,
> because it breaks the MVC separation. The display code should live in the
> templates, e.g.
>
>
>     {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
> {%endif%}
>
> If this is repeated elsewhere, like in this particular case, you should
> define a new tag in
> ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns
> the code:
>
> @register.simple_tag
>
> def task_outcome_highlight(task):
>
>     if task.outcome == Task.OUTCOME_EXISTING:
>
>         ret = ''
>
>   .... etc ...
>
> and then use it in the template:  {% task_outcome_highlight task %}
>
> b). html format; please don't use tabs; use 4-space instead of a tab; this
> makes for a nice consistency with the HTML code, and fits the HTML code in
> page better.
>
>
>
> c). recipe.html; please extend "basebuildpage.html" which fills in the
> breadcrumb and all the layout for viewing pages in a build context. see
> configvars.html for an example.
>
> d). recipes.html; the latest versions of the basetable_top will
> automatically generate correct table header based on the context
> description; please don't include your own table header, but edit the page
> context  to correctly set the table data; see the build view / build.html
> as a how-to guide.
>
> Hope this helps,
> Alex
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jan 13, 2014 at 12:42 PM, Damian, Alexandru <
> alexandru.damian@intel.com> wrote:
>
> Hi David,
>
> This is outstanding ! Thank you !
>
> I have some comments about the form, not the content of the patch, which
> should make future work a bit easier.
>
> - Indeed, we use the pluralized name for pages showing an object list
> (i.e. tables), and the singular for the detail page for the a single object.
>
>
> - We can do patches over email, instead of git push, but it's harder to
> work this way. However, the email patches should be proper git patches for
> easy use.
>
>
> You can get them like this:
>
>
> $ git commit                  # you commit normally to git
>
> $ git format-patch -n1   # you get a mailable version of the last patch
> from git;
>
> 0001-patch-name-as-it-appears-in-subject-line.patch     # the command will
> output the filename just written
>
> Now, there are two options to send this file.
>
>    - if sendmail, or any MTA for that matter, works on your machine, you
> just do:
>
> $ git send-email --to toaster@yoctoproject.org0001-patch-name-as-it-appears-in-subject-line.patch      # replace with the
> file name just written
>
>    - otherwise, open up your mail client, and copy/paste the contents of
> the file written in the mail, starting line 6, or just after the empty line
> after the Subject: line. Copy/paste the Subject: line content as your
> Subject:. Send this email :).
>
>
>
>   - The test procedure is outstanding !  I think we should use it for all
> the patches. For easier reference, I propose to get the test procedure in
> the bugzilla item that the patch addresses, as a comment.
>
> The patch commit message should reference the bugzilla issue like this:
>
> [YOCTO #0000]          # replace with the real bugzilla issue number
>
>
>
> Hope all of this makes sense :)
>
>
>
> I'll get to review the content of the patches separately.
>
> Cheers,
> Alex
>
>
>
>
>
> On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com>
> wrote:
>
> I used "recipes.html" for the page listing all recipes, and "recipe.html"
> for the individual recipe detail page. I can use different naming of course.
>
> - David
>
>
> > -----Original Message-----
> > From: Lerner, Dave
> > Sent: Sunday, January 12, 2014 9:56 AM
> > To: Reyna, David
> > Cc: toaster@yoctoproject.org
> > Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
> > information about a recipe"
> >
>
> > Hi David,
> >
> > I notice that you pluralized the recipe.html to recipes.html.  Doesn't
> > that break the existing convention of singular for all templates?
> >
> > What is your suggested naming convention for templates, singular vs
> > plural?  If those conventions are settled on by the team, then we
> > should apply that naming convention to the project before we create a
> > number of other templates.
> >
> > What do others think of the template naming conventions?
> > Dave
> >
>
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>
>
>
>   --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>
>
>
>
> --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>



-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 16016 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 7011 bytes --]

Hi guys,

About point c). above, the "recipe.html" and all object detail pages.

I made another mistake - Belen just confirmed that any and all object
details pages should not have the navigation tab on the left. This means
that "basebuildpage.html" is not suitable as a base template for these
pages.

What we should do is clone the "basebuildpage.html" to a new page
"basebuilddetailpage.html", remove the navigation tab, and use this as a
base for detail pages.
This would allow us to make sure we have common markup, including
breadcrumbs, through all the detail pages.

Sorry for the confusion,
Alex




On Mon, Jan 13, 2014 at 2:33 PM, Reyna, David <david.reyna@windriver.com>wrote:

>  Hi Alex,
>
>
>
> (a) Models.py
>
>
>
> > {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
> {%endif%}
>
> Have you actually tried that code? I tried this first, but Django does not
> support it, as also reflected in many google searches on the subject.
>
>
>
> I will move to trying a custom filter. I do hope that “Task.*” is defined
> for the context of the filter as well as the template.
>
>
>
> (b) Ok, 4-space tabs it is!
>
>
>
> (c) I explicitly removed "basebuildpage.html" because that content does
> not appear anywhere in the Recipe Details design document (as opposed to
> say Ravi’s Task document). I assumed that this was on purpose.
>
> I will restore it then.
>
> d) I see that Ravi used the basetable_top structure. I will adopt that as
> well.
>
> (e) You wrote “Indeed, we use the pluralized name for pages showing an
> object list (i.e. tables), and the singular for the detail page for the a
> single object.”
>
>
>
> Ok, I will stay with my current page names.
>
>
>
> - David
>
>
>
> *From:* Damian, Alexandru [mailto:alexandru.damian@intel.com]
> *Sent:* Monday, January 13, 2014 5:43 AM
> *To:* Reyna, David
> *Cc:* Lerner, Dave; toaster@yoctoproject.org
> *Subject:* Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
> detailed information about a recipe"
>
>
>
> Hi,
>
> I have comments about the content of the patch, as well.
>
> a). models.py; I am not very fond of having display code in the models,
> because it breaks the MVC separation. The display code should live in the
> templates, e.g.
>
>
>     {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
> {%endif%}
>
> If this is repeated elsewhere, like in this particular case, you should
> define a new tag in
> ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns
> the code:
>
> @register.simple_tag
>
> def task_outcome_highlight(task):
>
>     if task.outcome == Task.OUTCOME_EXISTING:
>
>         ret = ''
>
>   .... etc ...
>
> and then use it in the template:  {% task_outcome_highlight task %}
>
> b). html format; please don't use tabs; use 4-space instead of a tab; this
> makes for a nice consistency with the HTML code, and fits the HTML code in
> page better.
>
>
>
> c). recipe.html; please extend "basebuildpage.html" which fills in the
> breadcrumb and all the layout for viewing pages in a build context. see
> configvars.html for an example.
>
> d). recipes.html; the latest versions of the basetable_top will
> automatically generate correct table header based on the context
> description; please don't include your own table header, but edit the page
> context  to correctly set the table data; see the build view / build.html
> as a how-to guide.
>
> Hope this helps,
> Alex
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jan 13, 2014 at 12:42 PM, Damian, Alexandru <
> alexandru.damian@intel.com> wrote:
>
> Hi David,
>
> This is outstanding ! Thank you !
>
> I have some comments about the form, not the content of the patch, which
> should make future work a bit easier.
>
> - Indeed, we use the pluralized name for pages showing an object list
> (i.e. tables), and the singular for the detail page for the a single object.
>
>
> - We can do patches over email, instead of git push, but it's harder to
> work this way. However, the email patches should be proper git patches for
> easy use.
>
>
> You can get them like this:
>
>
> $ git commit                  # you commit normally to git
>
> $ git format-patch -n1   # you get a mailable version of the last patch
> from git;
>
> 0001-patch-name-as-it-appears-in-subject-line.patch     # the command will
> output the filename just written
>
> Now, there are two options to send this file.
>
>    - if sendmail, or any MTA for that matter, works on your machine, you
> just do:
>
> $ git send-email --to toaster@yoctoproject.org0001-patch-name-as-it-appears-in-subject-line.patch      # replace with the
> file name just written
>
>    - otherwise, open up your mail client, and copy/paste the contents of
> the file written in the mail, starting line 6, or just after the empty line
> after the Subject: line. Copy/paste the Subject: line content as your
> Subject:. Send this email :).
>
>
>
>   - The test procedure is outstanding !  I think we should use it for all
> the patches. For easier reference, I propose to get the test procedure in
> the bugzilla item that the patch addresses, as a comment.
>
> The patch commit message should reference the bugzilla issue like this:
>
> [YOCTO #0000]          # replace with the real bugzilla issue number
>
>
>
> Hope all of this makes sense :)
>
>
>
> I'll get to review the content of the patches separately.
>
> Cheers,
> Alex
>
>
>
>
>
> On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com>
> wrote:
>
> I used "recipes.html" for the page listing all recipes, and "recipe.html"
> for the individual recipe detail page. I can use different naming of course.
>
> - David
>
>
> > -----Original Message-----
> > From: Lerner, Dave
> > Sent: Sunday, January 12, 2014 9:56 AM
> > To: Reyna, David
> > Cc: toaster@yoctoproject.org
> > Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
> > information about a recipe"
> >
>
> > Hi David,
> >
> > I notice that you pluralized the recipe.html to recipes.html.  Doesn't
> > that break the existing convention of singular for all templates?
> >
> > What is your suggested naming convention for templates, singular vs
> > plural?  If those conventions are settled on by the team, then we
> > should apply that naming convention to the project before we create a
> > number of other templates.
> >
> > What do others think of the template naming conventions?
> > Dave
> >
>
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>
>
>
>   --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>
>
>
>
> --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>



-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 16181 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Barros Pena, Belen]

On 13/01/2014 14:46, "Damian, Alexandru" <alexandru.damian@intel.com>
wrote:

>Hi guys,
>
>
>About point c). above, the "recipe.html" and all object detail pages.
>
>
>I made another mistake - Belen just confirmed that any and all object
>details pages should not have the navigation tab on the left. This means
>that "basebuildpage.html" is not suitable as a base template for these
>pages.
>
>
>What we should do is clone the "basebuildpage.html" to a new page
>"basebuilddetailpage.html", remove the navigation tab, and use this as a
>base for detail pages.

Just a note about the layout of these detail pages:

* The detail pages for tasks use a single column layout (span11)

* The detail pages for recipes and packages use a 2-column layout (span7
for the left column and span4 for the right column)

I hope this is a not a problem.

Cheers,

Belén


>
>
>This would allow us to make sure we have common markup, including
>breadcrumbs, through all the detail pages.
>
>
>Sorry for the confusion,
>
>Alex
>
>
>
>
>
>
>
>
>On Mon, Jan 13, 2014 at 2:33 PM, Reyna, David
><david.reyna@windriver.com> wrote:
>
>Hi Alex,
> 
>(a) Models.py
> 
>> {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
>>{%endif%}
>
>Have you actually tried that code? I tried this first, but Django does
>not support it, as also reflected in many google searches on the subject.
> 
>I will move to trying a custom filter. I do hope that ³Task.*² is defined
>for the context of the filter as well as the template.
> 
>(b) Ok, 4-space tabs it is!
> 
>(c) I explicitly removed "basebuildpage.html" because that content does
>not appear anywhere in the Recipe Details design document
> (as opposed to say Ravi¹s Task document). I assumed that this was on
>purpose. 
>I will restore it then.
>d) I see that Ravi used the basetable_top structure. I will adopt that as
>well.
>(e) You wrote ³Indeed, we use the pluralized name for pages showing an
>object list (i.e. tables), and the singular for the detail page for the a
>single object.²
> 
>Ok, I will stay with my current page names.
> 
>- David
> 
>From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
>
>Sent: Monday, January 13, 2014 5:43 AM
>To: Reyna, David
>Cc: Lerner, Dave; 
>toaster@yoctoproject.org <mailto:toaster@yoctoproject.org>
>Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
>detailed information about a recipe"
>
>
> 
>Hi,
>
>I have comments about the content of the patch, as well.
>
>a). models.py; I am not very fond of having display code in the models,
>because it breaks the MVC separation. The display code should live in the
>templates, e.g.
>
>
>    {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
>{%endif%}
>
>If this is repeated elsewhere, like in this particular case, you should
>define a new tag in
>./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns
>the code:
>
>@register.simple_tag
>
>def task_outcome_highlight(task):
>
>    if task.outcome == Task.OUTCOME_EXISTING:
>
>        ret = ''
>
>  .... etc ...
>
>and then use it in the template:  {% task_outcome_highlight task %}
>
>b). html format; please don't use tabs; use 4-space instead of a tab;
>this makes for a nice consistency with the HTML code, and fits the HTML
>code in page better.
>
> 
>
>c). recipe.html; please extend "basebuildpage.html" which fills in the
>breadcrumb and all the layout for viewing pages in a build context. see
>configvars.html for an example.
>
>d). recipes.html; the latest versions of the basetable_top will
>automatically generate correct table header based on the context
>description; please don't include your own table header, but edit the
>page context 
> to correctly set the table data; see the build view / build.html as a
>how-to guide.
>
>Hope this helps,
>Alex
> 
> 
> 
> 
>
>
>
>
>
>
>
>
>
>
> 
>On Mon, Jan 13, 2014 at 12:42 PM, Damian, Alexandru
><alexandru.damian@intel.com> wrote:
>Hi David,
>
>This is outstanding ! Thank you !
>
>I have some comments about the form, not the content of the patch, which
>should make future work a bit easier.
>
>- Indeed, we use the pluralized name for pages showing an object list
>(i.e. tables), and the singular for the detail page for the a single
>object.
>
>
>- We can do patches over email, instead of git push, but it's harder to
>work this way. However, the email patches should be proper git patches
>for easy use.
>
>
>You can get them like this:
>
>
>$ git commit                  # you commit normally to git
>
>$ git format-patch -n1   # you get a mailable version of the last patch
>from git;
>
>
>0001-patch-name-as-it-appears-in-subject-line.patch     # the command
>will output the filename just written
>
>Now, there are two options to send this file.
>
>   - if sendmail, or any MTA for that matter, works on your machine, you
>just do:
>$ git send-email --to
>toaster@yoctoproject.org <mailto:toaster@yoctoproject.org>
>0001-patch-name-as-it-appears-in-subject-line.patch      # replace with
>the file name just written
>
>   - otherwise, open up your mail client, and copy/paste the contents of
>the file written in the mail, starting line 6, or just after the empty
>line after the Subject: line. Copy/paste the Subject: line content as
>your Subject:. Send this
> email :).
>
>
>
>
>
>- The test procedure is outstanding !  I think we should use it for all
>the patches. For easier reference, I propose to get the test procedure in
>the bugzilla item that the patch addresses, as a comment.
>
>The patch commit message should reference the bugzilla issue like this:
>
>[YOCTO #0000]          # replace with the real bugzilla issue number
>
> 
>
>Hope all of this makes sense :)
>
> 
>
>I'll get to review the content of the patches separately.
>
>
>Cheers,
>Alex
>
> 
>
>
>
>
> 
>On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com>
>wrote:
>I used "recipes.html" for the page listing all recipes, and "recipe.html"
>for the individual recipe detail page. I can use different naming of
>course.
>
>- David
>
>> -----Original Message-----
>> From: Lerner, Dave
>> Sent: Sunday, January 12, 2014 9:56 AM
>> To: Reyna, David
>> Cc: toaster@yoctoproject.org
>> Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
>> information about a recipe"
>>
>
>> Hi David,
>>
>> I notice that you pluralized the recipe.html to recipes.html.  Doesn't
>> that break the existing convention of singular for all templates?
>>
>> What is your suggested naming convention for templates, singular vs
>> plural?  If those conventions are settled on by the team, then we
>> should apply that naming convention to the project before we create a
>> number of other templates.
>>
>> What do others think of the template naming conventions?
>> Dave
>>
>
>_______________________________________________
>toaster mailing list
>toaster@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/toaster
>
>
>
>
>
>
>
>
>-- 
>Alex Damian
>Yocto Project
>
>SSG / OTC 
>
>
>
>
>
>
>
>-- 
>Alex Damian
>Yocto Project
>
>SSG / OTC 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>-- 
>Alex Damian
>Yocto Project
>
>SSG / OTC 
>
>

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Reyna, David]

[-- Attachment #1: Type: text/plain, Size: 7093 bytes --]

Hi Alex,

Should I wait for a new "basebuilddetailpage.html" file, or should I go with what I have today and update later?

- David

From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
Sent: Monday, January 13, 2014 6:46 AM
To: Reyna, David
Cc: Lerner, Dave; toaster@yoctoproject.org
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

Hi guys,
About point c). above, the "recipe.html" and all object detail pages.

I made another mistake - Belen just confirmed that any and all object details pages should not have the navigation tab on the left. This means that "basebuildpage.html" is not suitable as a base template for these pages.
What we should do is clone the "basebuildpage.html" to a new page "basebuilddetailpage.html", remove the navigation tab, and use this as a base for detail pages.
This would allow us to make sure we have common markup, including breadcrumbs, through all the detail pages.
Sorry for the confusion,
Alex



On Mon, Jan 13, 2014 at 2:33 PM, Reyna, David <david.reyna@windriver.com<mailto:david.reyna@windriver.com>> wrote:
Hi Alex,

(a) Models.py

> {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ... {%endif%}
Have you actually tried that code? I tried this first, but Django does not support it, as also reflected in many google searches on the subject.

I will move to trying a custom filter. I do hope that “Task.*” is defined for the context of the filter as well as the template.

(b) Ok, 4-space tabs it is!

(c) I explicitly removed "basebuildpage.html" because that content does not appear anywhere in the Recipe Details design document (as opposed to say Ravi’s Task document). I assumed that this was on purpose.
I will restore it then.
d) I see that Ravi used the basetable_top structure. I will adopt that as well.
(e) You wrote “Indeed, we use the pluralized name for pages showing an object list (i.e. tables), and the singular for the detail page for the a single object.”

Ok, I will stay with my current page names.

- David

From: Damian, Alexandru [mailto:alexandru.damian@intel.com<mailto:alexandru.damian@intel.com>]
Sent: Monday, January 13, 2014 5:43 AM
To: Reyna, David
Cc: Lerner, Dave; toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

Hi,

I have comments about the content of the patch, as well.
a). models.py; I am not very fond of having display code in the models, because it breaks the MVC separation. The display code should live in the templates, e.g.

    {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ... {%endif%}
If this is repeated elsewhere, like in this particular case, you should define a new tag in ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns the code:
@register.simple_tag
def task_outcome_highlight(task):
    if task.outcome == Task.OUTCOME_EXISTING:
        ret = ''
  .... etc ...
and then use it in the template:  {% task_outcome_highlight task %}
b). html format; please don't use tabs; use 4-space instead of a tab; this makes for a nice consistency with the HTML code, and fits the HTML code in page better.

c). recipe.html; please extend "basebuildpage.html" which fills in the breadcrumb and all the layout for viewing pages in a build context. see configvars.html for an example.
d). recipes.html; the latest versions of the basetable_top will automatically generate correct table header based on the context description; please don't include your own table header, but edit the page context  to correctly set the table data; see the build view / build.html as a how-to guide.
Hope this helps,
Alex





On Mon, Jan 13, 2014 at 12:42 PM, Damian, Alexandru <alexandru.damian@intel.com<mailto:alexandru.damian@intel.com>> wrote:
Hi David,

This is outstanding ! Thank you !
I have some comments about the form, not the content of the patch, which should make future work a bit easier.
- Indeed, we use the pluralized name for pages showing an object list (i.e. tables), and the singular for the detail page for the a single object.

- We can do patches over email, instead of git push, but it's harder to work this way. However, the email patches should be proper git patches for easy use.

You can get them like this:

$ git commit                  # you commit normally to git
$ git format-patch -n1   # you get a mailable version of the last patch from git;
0001-patch-name-as-it-appears-in-subject-line.patch     # the command will output the filename just written
Now, there are two options to send this file.
   - if sendmail, or any MTA for that matter, works on your machine, you just do:
$ git send-email --to toaster@yoctoproject.org<mailto:toaster@yoctoproject.org> 0001-patch-name-as-it-appears-in-subject-line.patch      # replace with the file name just written
   - otherwise, open up your mail client, and copy/paste the contents of the file written in the mail, starting line 6, or just after the empty line after the Subject: line. Copy/paste the Subject: line content as your Subject:. Send this email :).

- The test procedure is outstanding !  I think we should use it for all the patches. For easier reference, I propose to get the test procedure in the bugzilla item that the patch addresses, as a comment.
The patch commit message should reference the bugzilla issue like this:
[YOCTO #0000]          # replace with the real bugzilla issue number

Hope all of this makes sense :)

I'll get to review the content of the patches separately.
Cheers,
Alex


On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com<mailto:david.reyna@windriver.com>> wrote:
I used "recipes.html" for the page listing all recipes, and "recipe.html" for the individual recipe detail page. I can use different naming of course.

- David

> -----Original Message-----
> From: Lerner, Dave
> Sent: Sunday, January 12, 2014 9:56 AM
> To: Reyna, David
> Cc: toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
> Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
> information about a recipe"
>
> Hi David,
>
> I notice that you pluralized the recipe.html to recipes.html.  Doesn't
> that break the existing convention of singular for all templates?
>
> What is your suggested naming convention for templates, singular vs
> plural?  If those conventions are settled on by the team, then we
> should apply that naming convention to the project before we create a
> number of other templates.
>
> What do others think of the template naming conventions?
> Dave
>
_______________________________________________
toaster mailing list
toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/toaster


--
Alex Damian
Yocto Project
SSG / OTC



--
Alex Damian
Yocto Project
SSG / OTC



--
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 24532 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Lerner, Dave]

Hi Alex,

You wrote in a reply to David Reyna (he's David and I'll be Dave)...

> 
> - Indeed, we use the pluralized name for pages showing an object list (i.e. tables), and
> the singular for the detail page for the a single object.
> 
> 

Should we rename the exiting package.html to packages.html since package.html shows the package table for a build?  That's where I picked up what I thought was the naming convention.

Dave Lerner

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 7780 bytes --]

David,

Could you please go ahead and do this yourself ?

Thank you,
Alex


On Mon, Jan 13, 2014 at 2:57 PM, Reyna, David <david.reyna@windriver.com>wrote:

>  Hi Alex,
>
>
>
> Should I wait for a new "basebuilddetailpage.html" file, or should I go
> with what I have today and update later?
>
>
>
> - David
>
>
>
> *From:* Damian, Alexandru [mailto:alexandru.damian@intel.com]
> *Sent:* Monday, January 13, 2014 6:46 AM
>
> *To:* Reyna, David
> *Cc:* Lerner, Dave; toaster@yoctoproject.org
> *Subject:* Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
> detailed information about a recipe"
>
>
>
> Hi guys,
>
> About point c). above, the "recipe.html" and all object detail pages.
>
>
> I made another mistake - Belen just confirmed that any and all object
> details pages should not have the navigation tab on the left. This means
> that "basebuildpage.html" is not suitable as a base template for these
> pages.
>
> What we should do is clone the "basebuildpage.html" to a new page
> "basebuilddetailpage.html", remove the navigation tab, and use this as a
> base for detail pages.
>
> This would allow us to make sure we have common markup, including
> breadcrumbs, through all the detail pages.
>
> Sorry for the confusion,
>
> Alex
>
>
>
>
>
>
>
> On Mon, Jan 13, 2014 at 2:33 PM, Reyna, David <david.reyna@windriver.com>
> wrote:
>
> Hi Alex,
>
>
>
> (a) Models.py
>
>
>
> > {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
> {%endif%}
>
> Have you actually tried that code? I tried this first, but Django does not
> support it, as also reflected in many google searches on the subject.
>
>
>
> I will move to trying a custom filter. I do hope that “Task.*” is defined
> for the context of the filter as well as the template.
>
>
>
> (b) Ok, 4-space tabs it is!
>
>
>
> (c) I explicitly removed "basebuildpage.html" because that content does
> not appear anywhere in the Recipe Details design document (as opposed to
> say Ravi’s Task document). I assumed that this was on purpose.
>
> I will restore it then.
>
> d) I see that Ravi used the basetable_top structure. I will adopt that as
> well.
>
> (e) You wrote “Indeed, we use the pluralized name for pages showing an
> object list (i.e. tables), and the singular for the detail page for the a
> single object.”
>
>
>
> Ok, I will stay with my current page names.
>
>
>
> - David
>
>
>
> *From:* Damian, Alexandru [mailto:alexandru.damian@intel.com]
> *Sent:* Monday, January 13, 2014 5:43 AM
> *To:* Reyna, David
> *Cc:* Lerner, Dave; toaster@yoctoproject.org
> *Subject:* Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
> detailed information about a recipe"
>
>
>
> Hi,
>
> I have comments about the content of the patch, as well.
>
> a). models.py; I am not very fond of having display code in the models,
> because it breaks the MVC separation. The display code should live in the
> templates, e.g.
>
>
>     {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ...
> {%endif%}
>
> If this is repeated elsewhere, like in this particular case, you should
> define a new tag in
> ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns
> the code:
>
> @register.simple_tag
>
> def task_outcome_highlight(task):
>
>     if task.outcome == Task.OUTCOME_EXISTING:
>
>         ret = ''
>
>   .... etc ...
>
> and then use it in the template:  {% task_outcome_highlight task %}
>
> b). html format; please don't use tabs; use 4-space instead of a tab; this
> makes for a nice consistency with the HTML code, and fits the HTML code in
> page better.
>
>
>
> c). recipe.html; please extend "basebuildpage.html" which fills in the
> breadcrumb and all the layout for viewing pages in a build context. see
> configvars.html for an example.
>
> d). recipes.html; the latest versions of the basetable_top will
> automatically generate correct table header based on the context
> description; please don't include your own table header, but edit the page
> context  to correctly set the table data; see the build view / build.html
> as a how-to guide.
>
> Hope this helps,
> Alex
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jan 13, 2014 at 12:42 PM, Damian, Alexandru <
> alexandru.damian@intel.com> wrote:
>
> Hi David,
>
> This is outstanding ! Thank you !
>
> I have some comments about the form, not the content of the patch, which
> should make future work a bit easier.
>
> - Indeed, we use the pluralized name for pages showing an object list
> (i.e. tables), and the singular for the detail page for the a single object.
>
>
> - We can do patches over email, instead of git push, but it's harder to
> work this way. However, the email patches should be proper git patches for
> easy use.
>
>
> You can get them like this:
>
>
> $ git commit                  # you commit normally to git
>
> $ git format-patch -n1   # you get a mailable version of the last patch
> from git;
>
> 0001-patch-name-as-it-appears-in-subject-line.patch     # the command will
> output the filename just written
>
> Now, there are two options to send this file.
>
>    - if sendmail, or any MTA for that matter, works on your machine, you
> just do:
>
> $ git send-email --to toaster@yoctoproject.org0001-patch-name-as-it-appears-in-subject-line.patch      # replace with the
> file name just written
>
>    - otherwise, open up your mail client, and copy/paste the contents of
> the file written in the mail, starting line 6, or just after the empty line
> after the Subject: line. Copy/paste the Subject: line content as your
> Subject:. Send this email :).
>
>
>
> - The test procedure is outstanding !  I think we should use it for all
> the patches. For easier reference, I propose to get the test procedure in
> the bugzilla item that the patch addresses, as a comment.
>
> The patch commit message should reference the bugzilla issue like this:
>
> [YOCTO #0000]          # replace with the real bugzilla issue number
>
>
>
> Hope all of this makes sense :)
>
>
>
> I'll get to review the content of the patches separately.
>
> Cheers,
> Alex
>
>
>
>
>
> On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com>
> wrote:
>
> I used "recipes.html" for the page listing all recipes, and "recipe.html"
> for the individual recipe detail page. I can use different naming of course.
>
> - David
>
>
> > -----Original Message-----
> > From: Lerner, Dave
> > Sent: Sunday, January 12, 2014 9:56 AM
> > To: Reyna, David
> > Cc: toaster@yoctoproject.org
> > Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
> > information about a recipe"
> >
>
> > Hi David,
> >
> > I notice that you pluralized the recipe.html to recipes.html.  Doesn't
> > that break the existing convention of singular for all templates?
> >
> > What is your suggested naming convention for templates, singular vs
> > plural?  If those conventions are settled on by the team, then we
> > should apply that naming convention to the project before we create a
> > number of other templates.
> >
> > What do others think of the template naming conventions?
> > Dave
> >
>
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>
>
>
>   --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>
>
>
>
> --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>
>
>
>
> --
>
> Alex Damian
>
> Yocto Project
>
> SSG / OTC
>



-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 19800 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Reyna, David]

[-- Attachment #1: Type: text/plain, Size: 7747 bytes --]

> Could you please go ahead and do this yourself ?
Ok.

- David

From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
Sent: Monday, January 13, 2014 7:05 AM
To: Reyna, David
Cc: Lerner, Dave; toaster@yoctoproject.org
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

David,
Could you please go ahead and do this yourself ?
Thank you,
Alex

On Mon, Jan 13, 2014 at 2:57 PM, Reyna, David <david.reyna@windriver.com<mailto:david.reyna@windriver.com>> wrote:
Hi Alex,

Should I wait for a new "basebuilddetailpage.html" file, or should I go with what I have today and update later?

- David

From: Damian, Alexandru [mailto:alexandru.damian@intel.com<mailto:alexandru.damian@intel.com>]
Sent: Monday, January 13, 2014 6:46 AM

To: Reyna, David
Cc: Lerner, Dave; toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

Hi guys,
About point c). above, the "recipe.html" and all object detail pages.

I made another mistake - Belen just confirmed that any and all object details pages should not have the navigation tab on the left. This means that "basebuildpage.html" is not suitable as a base template for these pages.
What we should do is clone the "basebuildpage.html" to a new page "basebuilddetailpage.html", remove the navigation tab, and use this as a base for detail pages.
This would allow us to make sure we have common markup, including breadcrumbs, through all the detail pages.
Sorry for the confusion,
Alex



On Mon, Jan 13, 2014 at 2:33 PM, Reyna, David <david.reyna@windriver.com<mailto:david.reyna@windriver.com>> wrote:
Hi Alex,

(a) Models.py

> {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ... {%endif%}
Have you actually tried that code? I tried this first, but Django does not support it, as also reflected in many google searches on the subject.

I will move to trying a custom filter. I do hope that “Task.*” is defined for the context of the filter as well as the template.

(b) Ok, 4-space tabs it is!

(c) I explicitly removed "basebuildpage.html" because that content does not appear anywhere in the Recipe Details design document (as opposed to say Ravi’s Task document). I assumed that this was on purpose.
I will restore it then.
d) I see that Ravi used the basetable_top structure. I will adopt that as well.
(e) You wrote “Indeed, we use the pluralized name for pages showing an object list (i.e. tables), and the singular for the detail page for the a single object.”

Ok, I will stay with my current page names.

- David

From: Damian, Alexandru [mailto:alexandru.damian@intel.com<mailto:alexandru.damian@intel.com>]
Sent: Monday, January 13, 2014 5:43 AM
To: Reyna, David
Cc: Lerner, Dave; toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

Hi,

I have comments about the content of the patch, as well.
a). models.py; I am not very fond of having display code in the models, because it breaks the MVC separation. The display code should live in the templates, e.g.

    {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ... {%endif%}
If this is repeated elsewhere, like in this particular case, you should define a new tag in ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns the code:
@register.simple_tag
def task_outcome_highlight(task):
    if task.outcome == Task.OUTCOME_EXISTING:
        ret = ''
  .... etc ...
and then use it in the template:  {% task_outcome_highlight task %}
b). html format; please don't use tabs; use 4-space instead of a tab; this makes for a nice consistency with the HTML code, and fits the HTML code in page better.

c). recipe.html; please extend "basebuildpage.html" which fills in the breadcrumb and all the layout for viewing pages in a build context. see configvars.html for an example.
d). recipes.html; the latest versions of the basetable_top will automatically generate correct table header based on the context description; please don't include your own table header, but edit the page context  to correctly set the table data; see the build view / build.html as a how-to guide.
Hope this helps,
Alex





On Mon, Jan 13, 2014 at 12:42 PM, Damian, Alexandru <alexandru.damian@intel.com<mailto:alexandru.damian@intel.com>> wrote:
Hi David,

This is outstanding ! Thank you !
I have some comments about the form, not the content of the patch, which should make future work a bit easier.
- Indeed, we use the pluralized name for pages showing an object list (i.e. tables), and the singular for the detail page for the a single object.

- We can do patches over email, instead of git push, but it's harder to work this way. However, the email patches should be proper git patches for easy use.

You can get them like this:

$ git commit                  # you commit normally to git
$ git format-patch -n1   # you get a mailable version of the last patch from git;
0001-patch-name-as-it-appears-in-subject-line.patch     # the command will output the filename just written
Now, there are two options to send this file.
   - if sendmail, or any MTA for that matter, works on your machine, you just do:
$ git send-email --to toaster@yoctoproject.org<mailto:toaster@yoctoproject.org> 0001-patch-name-as-it-appears-in-subject-line.patch      # replace with the file name just written
   - otherwise, open up your mail client, and copy/paste the contents of the file written in the mail, starting line 6, or just after the empty line after the Subject: line. Copy/paste the Subject: line content as your Subject:. Send this email :).

- The test procedure is outstanding !  I think we should use it for all the patches. For easier reference, I propose to get the test procedure in the bugzilla item that the patch addresses, as a comment.
The patch commit message should reference the bugzilla issue like this:
[YOCTO #0000]          # replace with the real bugzilla issue number

Hope all of this makes sense :)

I'll get to review the content of the patches separately.
Cheers,
Alex


On Sun, Jan 12, 2014 at 6:49 PM, Reyna, David <david.reyna@windriver.com<mailto:david.reyna@windriver.com>> wrote:
I used "recipes.html" for the page listing all recipes, and "recipe.html" for the individual recipe detail page. I can use different naming of course.

- David

> -----Original Message-----
> From: Lerner, Dave
> Sent: Sunday, January 12, 2014 9:56 AM
> To: Reyna, David
> Cc: toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
> Subject: RE: DRY RUN [Review Request] 4299 "recipes: View detailed
> information about a recipe"
>
> Hi David,
>
> I notice that you pluralized the recipe.html to recipes.html.  Doesn't
> that break the existing convention of singular for all templates?
>
> What is your suggested naming convention for templates, singular vs
> plural?  If those conventions are settled on by the team, then we
> should apply that naming convention to the project before we create a
> number of other templates.
>
> What do others think of the template naming conventions?
> Dave
>
_______________________________________________
toaster mailing list
toaster@yoctoproject.org<mailto:toaster@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/toaster


--
Alex Damian
Yocto Project
SSG / OTC



--
Alex Damian
Yocto Project
SSG / OTC



--
Alex Damian
Yocto Project
SSG / OTC



--
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 28892 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Good question, Dave

For packages, we have 2 lists, in different parts of the design, that
display a list of packages.

- all packages build. This is currently the "bpackage" view which uses
"bpackage.html"; the view/page should be renamed to
"buildpackages/buildpackages.html"

- packages for an image. Currently this is "tpackage", and uses
"package.html". This should be renamed to
"targetpackages/targetpackages.html"

But we have a single package detail page, and this should be
"package/package.html".

Hope this is not too troublesome.

Alex


On Mon, Jan 13, 2014 at 3:01 PM, Lerner, Dave <dave.lerner@windriver.com>wrote:

> Hi Alex,
>
> You wrote in a reply to David Reyna (he's David and I'll be Dave)...
>
> >
> > - Indeed, we use the pluralized name for pages showing an object list
> (i.e. tables), and
> > the singular for the detail page for the a single object.
> >
> >
>
> Should we rename the exiting package.html to packages.html since
> package.html shows the package table for a build?  That's where I picked up
> what I thought was the naming convention.
>
> Dave Lerner
>



-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 2209 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Barros Pena, Belen]

On 13/01/2014 15:10, "Damian, Alexandru" <alexandru.damian@intel.com>
wrote:

>Good question, Dave
>
>
>For packages, we have 2 lists, in different parts of the design, that
>display a list of packages.
>
>
>- all packages build. This is currently the "bpackage" view which uses
>"bpackage.html"; the view/page should be renamed to
>"buildpackages/buildpackages.html"
>
>
>- packages for an image. Currently this is "tpackage", and uses
>"package.html". This should be renamed to
>"targetpackages/targetpackages.html"
>
>
>But we have a single package detail page, and this should be
>"package/package.html".

Actually, for packages installed, we have 2 package details pages. The
build package details:

http://www.yoctoproject.org/toaster/package-built-details-included-busybox.
html

is just a stub, a way of redirecting users to the target package details
page

http://www.yoctoproject.org/toaster/package-included-details.html

I decided to keep the build package details page for installed packages to
avoid disorientation: if you were sent directly from the packages built
table to the packages installed details page you could lose track of your
location within the application. Keeping the build package details page
seemed safer.

Cheers

Belén


>
>Hope this is not too troublesome.
>
>
>Alex
>
>
>
>
>On Mon, Jan 13, 2014 at 3:01 PM, Lerner, Dave
><dave.lerner@windriver.com> wrote:
>
>Hi Alex,
>
>You wrote in a reply to David Reyna (he's David and I'll be Dave)...
>
>>
>> - Indeed, we use the pluralized name for pages showing an object list
>>(i.e. tables), and
>> the singular for the detail page for the a single object.
>>
>>
>
>
>Should we rename the exiting package.html to packages.html since
>package.html shows the package table for a build?  That's where I picked
>up what I thought was the naming convention.
>
>Dave Lerner
>
>
>
>
>
>
>-- 
>Alex Damian
>Yocto Project
>
>SSG / OTC 
>
>

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Lerner, Dave]

Hi Belen,
I'm stuck on two issues.

I'm still confused on the navigation, mapping of your view named diagram to actual mouse clicks, that you want to get fire views "Design 1.5.1 Package Details" vs firing the views in "Design 1.1.1 Included Package Detail image".

To get to "Design 1.5.1 Package Details" views I assume that from the All Builds page:
In the Target column of the Table, click on an image
  On the left side click on Packages
	views per Design 1.5.1

How do I get to the "Design 1.1.1 Package Details" views?
Dave

> -----Original Message-----
> From: toaster-bounces@yoctoproject.org [mailto:toaster-bounces@yoctoproject.org] On
> Behalf Of Barros Pena, Belen
> Sent: Monday, January 13, 2014 9:24 AM
> To: Damian, Alexandru; Lerner, Dave
> Cc: toaster@yoctoproject.org
> Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information
> about a recipe"
> 
> On 13/01/2014 15:10, "Damian, Alexandru" <alexandru.damian@intel.com>
> wrote:
> 
> >Good question, Dave
> >
> >
> >For packages, we have 2 lists, in different parts of the design, that
> >display a list of packages.
> >
> >
> >- all packages build. This is currently the "bpackage" view which uses
> >"bpackage.html"; the view/page should be renamed to
> >"buildpackages/buildpackages.html"
> >
> >
> >- packages for an image. Currently this is "tpackage", and uses
> >"package.html". This should be renamed to
> >"targetpackages/targetpackages.html"
> >
> >
> >But we have a single package detail page, and this should be
> >"package/package.html".
> 
> Actually, for packages installed, we have 2 package details pages. The
> build package details:
> 
> http://www.yoctoproject.org/toaster/package-built-details-included-busybox.
> html
> 
> is just a stub, a way of redirecting users to the target package details
> page
> 
> http://www.yoctoproject.org/toaster/package-included-details.html
> 
> I decided to keep the build package details page for installed packages to
> avoid disorientation: if you were sent directly from the packages built
> table to the packages installed details page you could lose track of your
> location within the application. Keeping the build package details page
> seemed safer.
> 
> Cheers
> 
> Belén
> 
> 
> >
> >Hope this is not too troublesome.
> >
> >
> >Alex
> >
> >
> >
> >
> >On Mon, Jan 13, 2014 at 3:01 PM, Lerner, Dave
> ><dave.lerner@windriver.com> wrote:
> >
> >Hi Alex,
> >
> >You wrote in a reply to David Reyna (he's David and I'll be Dave)...
> >
> >>
> >> - Indeed, we use the pluralized name for pages showing an object list
> >>(i.e. tables), and
> >> the singular for the detail page for the a single object.
> >>
> >>
> >
> >
> >Should we rename the exiting package.html to packages.html since
> >package.html shows the package table for a build?  That's where I picked
> >up what I thought was the naming convention.
> >
> >Dave Lerner
> >
> >
> >
> >
> >
> >
> >--
> >Alex Damian
> >Yocto Project
> >
> >SSG / OTC
> >
> >
> 
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Barros Pena, Belen]

On 13/01/2014 15:44, "Lerner, Dave" <dave.lerner@windriver.com> wrote:

>Hi Belen,
>I'm stuck on two issues.
>
>I'm still confused on the navigation, mapping of your view named diagram
>to actual mouse clicks, that you want to get fire views "Design 1.5.1
>Package Details" vs firing the views in "Design 1.1.1 Included Package
>Detail image".
>
>To get to "Design 1.5.1 Package Details" views I assume that from the All
>Builds page:
>In the Target column of the Table, click on an image
>  On the left side click on Packages
>	views per Design 1.5.1
>
>How do I get to the "Design 1.1.1 Package Details" views?

From the All builds page:

1. In the Target column of the table, click on an image
2. On the left side navigation click on a target (image) name (in the
design prototype, core-image-sato)

That will bring you to 1.1 Image information, where the selected tab is
Packages included. Select a package on the table to get to 1.1.1 Included
package details.

This file in the wiki night help:

https://wiki.yoctoproject.org/wiki/images/4/4c/Toaster_1.6_content_structur
e.pdf

It shows the Toaster structure.

Cheers

Belén


>Dave
>
>> -----Original Message-----
>> From: toaster-bounces@yoctoproject.org
>>[mailto:toaster-bounces@yoctoproject.org] On
>> Behalf Of Barros Pena, Belen
>> Sent: Monday, January 13, 2014 9:24 AM
>> To: Damian, Alexandru; Lerner, Dave
>> Cc: toaster@yoctoproject.org
>> Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
>>detailed information
>> about a recipe"
>> 
>> On 13/01/2014 15:10, "Damian, Alexandru" <alexandru.damian@intel.com>
>> wrote:
>> 
>> >Good question, Dave
>> >
>> >
>> >For packages, we have 2 lists, in different parts of the design, that
>> >display a list of packages.
>> >
>> >
>> >- all packages build. This is currently the "bpackage" view which uses
>> >"bpackage.html"; the view/page should be renamed to
>> >"buildpackages/buildpackages.html"
>> >
>> >
>> >- packages for an image. Currently this is "tpackage", and uses
>> >"package.html". This should be renamed to
>> >"targetpackages/targetpackages.html"
>> >
>> >
>> >But we have a single package detail page, and this should be
>> >"package/package.html".
>> 
>> Actually, for packages installed, we have 2 package details pages. The
>> build package details:
>> 
>> 
>>http://www.yoctoproject.org/toaster/package-built-details-included-busybo
>>x.
>> html
>> 
>> is just a stub, a way of redirecting users to the target package details
>> page
>> 
>> http://www.yoctoproject.org/toaster/package-included-details.html
>> 
>> I decided to keep the build package details page for installed packages
>>to
>> avoid disorientation: if you were sent directly from the packages built
>> table to the packages installed details page you could lose track of
>>your
>> location within the application. Keeping the build package details page
>> seemed safer.
>> 
>> Cheers
>> 
>> Belén
>> 
>> 
>> >
>> >Hope this is not too troublesome.
>> >
>> >
>> >Alex
>> >
>> >
>> >
>> >
>> >On Mon, Jan 13, 2014 at 3:01 PM, Lerner, Dave
>> ><dave.lerner@windriver.com> wrote:
>> >
>> >Hi Alex,
>> >
>> >You wrote in a reply to David Reyna (he's David and I'll be Dave)...
>> >
>> >>
>> >> - Indeed, we use the pluralized name for pages showing an object list
>> >>(i.e. tables), and
>> >> the singular for the detail page for the a single object.
>> >>
>> >>
>> >
>> >
>> >Should we rename the exiting package.html to packages.html since
>> >package.html shows the package table for a build?  That's where I
>>picked
>> >up what I thought was the naming convention.
>> >
>> >Dave Lerner
>> >
>> >
>> >
>> >
>> >
>> >
>> >--
>> >Alex Damian
>> >Yocto Project
>> >
>> >SSG / OTC
>> >
>> >
>> 
>> _______________________________________________
>> toaster mailing list
>> toaster@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/toaster

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Reyna, David]

Hi Alex,

There is something seriously fragile about Django tags and filters. 

1) When I try to use “simple_tag”, all I get is “Invalid block tag: 'task_outcome_highlight', expected 'empty' or 'endfor', even for the most trivial tag:

@register.filter
def task_outcome_highlight(task)
    return 'class=error'

...and...

{% task_outcome_highlight task %}

2) I then tried filters. I first used a filter out of the Djago docs, and it worked.

WORKS:

@register.filter(name='cut')
def cut(value, arg):
    """Removes all values of arg from the given string"""
    return value.replace(arg, '')

...and...

{{ "1230456"|cut:"0" }}

3) However, if I make change to that filter, for example changing its name, I get nothing but filter format errors.

FAILS (when renamed to "cu"):

@register.filter(name='cu')
def cu (value, arg):
    """Removes all values of arg from the given string"""
    return value.replace(arg, '')

...and...

{{ "1230456"|cu:"0" }}

4) I have tried stopping and starting the server. If I rename the filter back to "cut", it will start working again.

I have spent hours on something that should be done in 10 minutes.

- David

========================

From: Damian, Alexandru [mailto:alexandru.damian@intel.com] 
Sent: Monday, January 13, 2014 5:43 AM
To: Reyna, David
Cc: Lerner, Dave; toaster@yoctoproject.org
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

Hi,

I have comments about the content of the patch, as well.
a). models.py; I am not very fond of having display code in the models, because it breaks the MVC separation. The display code should live in the templates, e.g.

    {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ... {%endif%}
If this is repeated elsewhere, like in this particular case, you should define a new tag in ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns the code:
@register.simple_tag
def task_outcome_highlight(task):
    if task.outcome == Task.OUTCOME_EXISTING:
        ret = ''
  .... etc ...
and then use it in the template:  {% task_outcome_highlight task %}
b). html format; please don't use tabs; use 4-space instead of a tab; this makes for a nice consistency with the HTML code, and fits the HTML code in page better.

c). recipe.html; please extend "basebuildpage.html" which fills in the breadcrumb and all the layout for viewing pages in a build context. see configvars.html for an example.
d). recipes.html; the latest versions of the basetable_top will automatically generate correct table header based on the context description; please don't include your own table header, but edit the page context  to correctly set the table data; see the build view / build.html as a how-to guide.
Hope this helps,
Alex

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Ravi Chintakunta]

Hi David,

I added the custom tag and pushed it yesterday:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ravi/all-tasks-feature&id=c04cbe928b0796a1a770399df7d10c7f7cb66ce7

You can see the usage of the tag here:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ravi/all-tasks-feature&id=844be60f5c5a73623a56a14689d9bbe6ee29a541

For the tag to be used, the projecttags has to be loaded in the file by calling:

{% load projecttags %}


Thanks,
Ravi
________________________________________
From: toaster-bounces@yoctoproject.org [toaster-bounces@yoctoproject.org] On Behalf Of Reyna, David [david.reyna@windriver.com]
Sent: Wednesday, January 15, 2014 1:34 AM
To: Damian, Alexandru
Cc: toaster@yoctoproject.org
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

Hi Alex,

There is something seriously fragile about Django tags and filters.

1) When I try to use “simple_tag”, all I get is “Invalid block tag: 'task_outcome_highlight', expected 'empty' or 'endfor', even for the most trivial tag:

@register.filter
def task_outcome_highlight(task)
    return 'class=error'

...and...

{% task_outcome_highlight task %}

2) I then tried filters. I first used a filter out of the Djago docs, and it worked.

WORKS:

@register.filter(name='cut')
def cut(value, arg):
    """Removes all values of arg from the given string"""
    return value.replace(arg, '')

...and...

{{ "1230456"|cut:"0" }}

3) However, if I make change to that filter, for example changing its name, I get nothing but filter format errors.

FAILS (when renamed to "cu"):

@register.filter(name='cu')
def cu (value, arg):
    """Removes all values of arg from the given string"""
    return value.replace(arg, '')

...and...

{{ "1230456"|cu:"0" }}

4) I have tried stopping and starting the server. If I rename the filter back to "cut", it will start working again.

I have spent hours on something that should be done in 10 minutes.

- David

========================

From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
Sent: Monday, January 13, 2014 5:43 AM
To: Reyna, David
Cc: Lerner, Dave; toaster@yoctoproject.org
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

Hi,

I have comments about the content of the patch, as well.
a). models.py; I am not very fond of having display code in the models, because it breaks the MVC separation. The display code should live in the templates, e.g.

    {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %} ... {%endif%}
If this is repeated elsewhere, like in this particular case, you should define a new tag in ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that returns the code:
@register.simple_tag
def task_outcome_highlight(task):
    if task.outcome == Task.OUTCOME_EXISTING:
        ret = ''
  .... etc ...
and then use it in the template:  {% task_outcome_highlight task %}
b). html format; please don't use tabs; use 4-space instead of a tab; this makes for a nice consistency with the HTML code, and fits the HTML code in page better.

c). recipe.html; please extend "basebuildpage.html" which fills in the breadcrumb and all the layout for viewing pages in a build context. see configvars.html for an example.
d). recipes.html; the latest versions of the basetable_top will automatically generate correct table header based on the context description; please don't include your own table header, but edit the page context  to correctly set the table data; see the build view / build.html as a how-to guide.
Hope this helps,
Alex



_______________________________________________
toaster mailing list
toaster@yoctoproject.org
https://lists.yoctoproject.org/listinfo/toaster

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Reyna, David]

Hi Ravi,

> I added the custom tag and pushed it yesterday:

I am glad you got it working. Is this in your private branch? I missed the review request email if not.

> {% load projecttags %}

I was indeed missing this. Shouldn't something as fundamental as this be part of the "basebuild[details]page.html"? I had assumed so and thus got into trouble.

> return 'style=color:red' else: return 'style=color:black'

By the way, Belen had defined these class colors in her CSS style sheet...

  'class=error'
  'class=muted'

... where no color specified defaults to "color:black".

We may want to use her CSS values in case Belen changes her mind on the colors :-)

- David

> -----Original Message-----
> From: Ravi Chintakunta [mailto:ravi.chintakunta@timesys.com]
> Sent: Wednesday, January 15, 2014 4:10 AM
> To: Reyna, David; Damian, Alexandru
> Cc: toaster@yoctoproject.org
> Subject: RE: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
> detailed information about a recipe"
> 
> Hi David,
> 
> I added the custom tag and pushed it yesterday:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-
> contrib/commit/?h=ravi/all-tasks-
> feature&id=c04cbe928b0796a1a770399df7d10c7f7cb66ce7
> 
> You can see the usage of the tag here:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-
> contrib/commit/?h=ravi/all-tasks-
> feature&id=844be60f5c5a73623a56a14689d9bbe6ee29a541
> 
> For the tag to be used, the projecttags has to be loaded in the file by
> calling:
> 
> {% load projecttags %}
> 
> 
> Thanks,
> Ravi
> ________________________________________
> From: toaster-bounces@yoctoproject.org [toaster-
> bounces@yoctoproject.org] On Behalf Of Reyna, David
> [david.reyna@windriver.com]
> Sent: Wednesday, January 15, 2014 1:34 AM
> To: Damian, Alexandru
> Cc: toaster@yoctoproject.org
> Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
> detailed information about a recipe"
> 
> Hi Alex,
> 
> There is something seriously fragile about Django tags and filters.
> 
> 1) When I try to use "simple_tag", all I get is "Invalid block tag:
> 'task_outcome_highlight', expected 'empty' or 'endfor', even for the
> most trivial tag:
> 
> @register.filter
> def task_outcome_highlight(task)
>     return 'class=error'
> 
> ...and...
> 
> {% task_outcome_highlight task %}
> 
> 2) I then tried filters. I first used a filter out of the Djago docs,
> and it worked.
> 
> WORKS:
> 
> @register.filter(name='cut')
> def cut(value, arg):
>     """Removes all values of arg from the given string"""
>     return value.replace(arg, '')
> 
> ...and...
> 
> {{ "1230456"|cut:"0" }}
> 
> 3) However, if I make change to that filter, for example changing its
> name, I get nothing but filter format errors.
> 
> FAILS (when renamed to "cu"):
> 
> @register.filter(name='cu')
> def cu (value, arg):
>     """Removes all values of arg from the given string"""
>     return value.replace(arg, '')
> 
> ...and...
> 
> {{ "1230456"|cu:"0" }}
> 
> 4) I have tried stopping and starting the server. If I rename the
> filter back to "cut", it will start working again.
> 
> I have spent hours on something that should be done in 10 minutes.
> 
> - David
> 
> ========================
> 
> From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
> Sent: Monday, January 13, 2014 5:43 AM
> To: Reyna, David
> Cc: Lerner, Dave; toaster@yoctoproject.org
> Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View
> detailed information about a recipe"
> 
> Hi,
> 
> I have comments about the content of the patch, as well.
> a). models.py; I am not very fond of having display code in the models,
> because it breaks the MVC separation. The display code should live in
> the templates, e.g.
> 
>     {% if task.outcome == Task.OUTCOME_FAILED %}class=error{% elif %}
> ... {%endif%}
> If this is repeated elsewhere, like in this particular case, you should
> define a new tag in
> ./bitbake/lib/toaster/toastergui/templatetags/projecttags.py that
> returns the code:
> @register.simple_tag
> def task_outcome_highlight(task):
>     if task.outcome == Task.OUTCOME_EXISTING:
>         ret = ''
>   .... etc ...
> and then use it in the template:  {% task_outcome_highlight task %}
> b). html format; please don't use tabs; use 4-space instead of a tab;
> this makes for a nice consistency with the HTML code, and fits the HTML
> code in page better.
> 
> c). recipe.html; please extend "basebuildpage.html" which fills in the
> breadcrumb and all the layout for viewing pages in a build context. see
> configvars.html for an example.
> d). recipes.html; the latest versions of the basetable_top will
> automatically generate correct table header based on the context
> description; please don't include your own table header, but edit the
> page context  to correctly set the table data; see the build view /
> build.html as a how-to guide.
> Hope this helps,
> Alex
> 
> 
> 
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster

FW: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Reyna, David]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

[including toaster email list]

Hi Alex,

> The "extends" tag isn't behaving exactly like an inheritance, so you need to re-do all "load" and the like for each page.

Oh, that is why it is not predefinable in one of the “extends” pages. :-( This answers a question I just posed to Ravi.

Perhaps at the end we can gather all such additions into a “base_load.html” page to make it common across all pages, if we find more such objects to load.

- David

From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
Sent: Wednesday, January 15, 2014 3:23 AM
To: Reyna, David
Subject: Re: [Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

I suppose you get a "Invalid block tag".

I  think you need a {% load projecttags %} at the top of the task.html. The "extends" tag isn't behaving exactly like an inheritance, so you need to re-do all "load" and the like for each page.
I know that this is a pain point in the Django documentation.

Alex

[-- Attachment #2: Type: text/html, Size: 5706 bytes --]

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Paul Eggleton]

On Wednesday 15 January 2014 15:19:19 Reyna, David wrote:
> > {% load projecttags %}
> 
> I was indeed missing this. Shouldn't something as fundamental as this be
> part of the "basebuild[details]page.html"? I had assumed so and thus got
> into trouble.

You can't do this with Django's templating; the load needs to be in the 
template file in which the tags are being used, so we need to have the load in 
each template where we need it.

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Ravi Chintakunta]

Hi David,

>  > return 'style=color:red' else: return 'style=color:black'
>  
>  By the way, Belen had defined these class colors in her CSS style
>  sheet...
>  
>    'class=error'
>    'class=muted'
>  
>  ... where no color specified defaults to "color:black".
>  
>  We may want to use her CSS values in case Belen changes her mind on
>  the colors :-)
>  

Yes, I agree.

I have pushed my commit

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ravi/all-tasks-feature&id=2423a9336b66d8c83a139ad50890ffbb88ecd181

to remove the hard coded colors and use the css.

Thanks,
Ravi

Re: DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Barros Pena, Belen]

On 15/01/2014 17:21, "Ravi Chintakunta" <ravi.chintakunta@timesys.com>
wrote:

>Hi David,
>
>>  > return 'style=color:red' else: return 'style=color:black'
>>  
>>  By the way, Belen had defined these class colors in her CSS style
>>  sheet...
>>  
>>    'class=error'
>>    'class=muted'
>>  
>>  ... where no color specified defaults to "color:black".

I am not sure this is important, but just in case. The default colour for
anchor tags inside tables is #333333. The hover effect is set to black
(#000000). Those styles are defined in lines 110 and 111 of default.css

Cheers

Belén

>>  
>>  We may want to use her CSS values in case Belen changes her mind on
>>  the colors :-)
>>  
>
>Yes, I agree.
>
>I have pushed my commit
>
>http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ravi/all-
>tasks-feature&id=2423a9336b66d8c83a139ad50890ffbb88ecd181
>
>to remove the hard coded colors and use the css.
>
>Thanks,
>Ravi
>_______________________________________________
>toaster mailing list
>toaster@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/toaster