* Re: Design for the configuration variables page (6588)
2014-08-22 5:45 ` Reyna, David
@ 2014-08-22 9:55 ` Barros Pena, Belen
2014-08-22 11:21 ` Reyna, David
0 siblings, 1 reply; 4+ messages in thread
From: Barros Pena, Belen @ 2014-08-22 9:55 UTC (permalink / raw)
To: Reyna, David L (Wind River), toaster; +Cc: Eggleton, Paul
Thanks for reviewing the document, David. Some comments inline.
On 22/08/2014 06:45, "Reyna, David" <david.reyna@windriver.com> wrote:
>Hi Belen,
>
>I have taken a pass at your excellent document. I have a few questions,
>more than for other documents given the nature of the content, some
>presumably for Alex.
>
>1) I myself am fine with the initial limited list of configuration
>variables. Let us start easy and build up later.
>
>I assume that the class for Projects will be updated to initialize this
>list, hard coded for now.
>
>2) [Alex] How does the interface know if a configure variable can be
>blank, in other words when it can show the "delete" button as per your
>design? Is the easy plan to just hardcode the behavior for the default
>variables, and not attempt to assert this rule for the hand-added
>variables?
From the design standpoint, I applied a very simple principle: no variable
can be blank in the interface. You either set a variable to a non-empty
value (i.e. not blank) or you delete it. The default list of variables
cannot be deleted, so they must be set to a non-empty value.
The only exception to this rule is IMAGE_INSTALL_append, and the reason is
to expose the variable so that it is easier to discover that you can use
it to customise the content of the rootfs.
This approach might be too simplistic, though, and you might want to the
ability to set certain variables to blank values through Toaster.
>
>Here is the table object that I understand maps to the project's
>"Configuration Variable".
>
>class ProjectVariable(models.Model):
> project = models.ForeignKey(Project)
> name = models.CharField(max_length=100)
> value = models.TextField(blank = True)
>
>3) [Alex] How did we want changes propagated back to the database? I
>observe that there is no "Submit" button, unless "Save" and "Add Value"
>are the mini-submit buttons.
There is no 'global' save in this page: you make changes per variable, so
changes should go into the database when you click a variable's "save"
button (the mini-submit buttons, as you call them).
>
>The sample implementation has Javascript automatically updating the view
>when "Add Value" is clicked (which is cool). Does that JS action also do
>a Jquery or something and instantly update the database?
>
>Along these lines, I observe that there is no "Cancel" button so people
>cannot change their minds. I myself am ok with that for now - we can
>embellish this later.
There is a "cancel" action again per variable. So if I click "change"
DISTRO which is set to 'poky', I change the value to 'poky-bleeding', then
I click the "cancel" action, the variable goes back to 'poky'. If I click
'save', it will change to 'poky-bleeding' and there is no undo: you need
to change the variable value back if you change your mind. Since nothing
really happens when you change a variable until you start a build, having
an 'undo' option for variables is probably overkill.
>
>4) You write in your example for IMAGE_FSTYPES:
>
>It appears that IMAGE_FSTYPES is a special variable with special
>handling. Is that list hard coded in the view data, or can I get that
>list from somewhere?
As far as I know, the list comes from the IMAGE_TYPES variable. I could be
wrong though.
>
>5) Were does the strings for PACKAGE_CLASSES come from? Are they simply
>hard coded in this initial version of the view?
>
>6) Can I assume that the SDKMACHINE variable can only be the values
>'i686' or 'x86_64', and this is hard coded into the view?
I have no answers to those 2. They reflect what we currently to in Hob, so
I've assumed the values we show there are the correct values, and that
they come from somewhere (hopefully they are not hardcoded).
>
>7) [Alex] Where does the blacklist come from?
I think we need to put it together ourselves. I will send around a first
version, so people can add to it.
>
>Thanks,
>David
>
>> -----Original Message-----
>> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
>> Sent: Thursday, August 21, 2014 8:15 AM
>> To: toaster@yoctoproject.org
>> Cc: Reyna, David; EGGLETON, PAUL; DAMIAN, ALEXANDRU
>> Subject: Design for the configuration variables page (6588)
>>
>> Design document attached to the Bugzilla issue, as usual
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6588
>>
>> I would need people to go through the document (it's not too long):
>>there
>> might be changes needed.
>>
>> Also, we need to come up with a final list of blacklisted variables.
>>
>> Thanks!
>>
>> Belén
>>
>
^ permalink raw reply [flat|nested] 4+ messages in thread