Merge lp:~rvb/maas/ui-power-parameters into lp:maas/trunk
| Status: | Merged |
|---|---|
| Approved by: | Raphaël Badin on 2012-06-12 |
| Approved revision: | 631 |
| Merged at revision: | 630 |
| Proposed branch: | lp:~rvb/maas/ui-power-parameters |
| Merge into: | lp:maas/trunk |
| Prerequisite: | lp:~rvb/maas/api-power-parameters |
| Diff against target: |
423 lines (+196/-38) 10 files modified
src/maasserver/config_forms.py (+3/-0) src/maasserver/context_processors.py (+2/-2) src/maasserver/static/js/node_add.js (+26/-3) src/maasserver/static/js/tests/test_node_add.html (+34/-15) src/maasserver/static/js/tests/test_node_add.js (+64/-0) src/maasserver/templates/maasserver/js-conf.html (+2/-0) src/maasserver/templates/maasserver/node_edit.html (+0/-2) src/maasserver/templates/maasserver/snippets.html (+14/-6) src/maasserver/tests/test_config_forms.py (+5/-0) src/maasserver/tests/test_views.py (+46/-10) |
| To merge this branch: | bzr merge lp:~rvb/maas/ui-power-parameters |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Gavin Panella (community) | 2012-06-11 | Approve on 2012-06-11 | |
|
Review via email:
|
|||
Commit Message
Add power_type and power_parameters to the add node UI.
Description of the Change
This branch add the fields power_type and power_parameters to the "add node" UI (if the user is an admin).
= Notes =
- I've changed DictCharField to return the empty string instead of '<fieldset>
- I've added power_parameters.js and enums.js in js-conf.html (i.e. globally).
- no need for the "architecture" snippet (in snippet.html) to be a snippet on its own, I've included it in the general snippet "add-node".
| Raphaël Badin (rvb) wrote : | # |
Thanks for the review Gavin!
> [1]
> [...]
> Saving the result of this lookup will be more efficient and be clearer
> to read:
> [...]
Done.
> [2]
> Not for this branch, but it would be cool to have a this.patch()
> method, like in the Python test suite, that arranges a clean-up hook.
> [...]
Indeed. We clearly lack our python test arsenal in Javascript…
> [3]
>
> + <input type="text" maxlength="30" name="hostname" id="id_hostname" />
> ...
> + this.add_
> + this.add_
>
> Why do some IDs have hyphens and some underscores? Is this Django
> versus YUI?
That's right, it's just a convention I use to remind me of what comes from Django and what does not.
> [4]
>
> + self.assertEqual(
> + 1, len(snippets),
> + "The snippet '%s' does not exist." % template_selector)
>
> There could be two.
Right, I've changed the error message.
> [5]
> [...]
> The above is a bit of an anti-pattern. The `reverse` condition should
> ideally be moved elsewhere, like up into the calling functions:
> [...]
Good point, I confess I was a little bit lazy on this one… fixed!


[1]
+ setupPowerParam eterField: function() { isValue( Y.one(' #id_power_ type')) ) { bindTo( Y.one(' #id_power_ type'), 'change');
+ if (Y.Lang.
...
+ widget.
Saving the result of this lookup will be more efficient and be clearer
to read:
setupPowerP arameterField: function() { #id_power_ type'); isValue( power_type_ node)) {
widget. bindTo( power_type_ node, 'change');
var power_type_node = Y.one('
if (Y.Lang.
...
[2]
+ setUpPowerTypeEnum: function() { POWER_TYPE_ ENUM for the sake of testing. TYPE_ENUM = module. POWER_TYPE_ ENUM; POWER_TYPE_ ENUM = ENUM;
+ // Override module.
+ this.POWER_
+ module.
+ },
Not for this branch, but it would be cool to have a this.patch()
method, like in the Python test suite, that arranges a clean-up hook.
[3]
+ <input type="text" maxlength="30" name="hostname" id="id_hostname" /> node_template = Y.one(' #add-node' ).getContent( ); node_admin_ snippet = Y.one(' #add-node- admin') .getContent( );
...
+ this.add_
+ this.add_
Why do some IDs have hyphens and some underscores? Is this Django
versus YUI?
[4]
+ self.assertEqual(
+ 1, len(snippets),
+ "The snippet '%s' does not exist." % template_selector)
There could be two.
[5]
+ def _assertTemplate ExistsAndContai ns(self, content, template_selector, xistsAndContain s(self, content, template_selector, plateExistsAndC ontains( xistsAndDoesNot Contain( self, content, template_selector, plateExistsAndC ontains(
+ contains_selector, reverse=False):
...
+ if reverse:
+ self.assertEqual(
+ 0, len(selects),
+ "The element '%s' does exist." % contains_selector)
+ else:
+ self.assertEqual(
+ 1, len(selects),
+ "The element '%s' does not exist." % contains_selector,)
+
+ def assertTemplateE
...
+ self._assertTem
+ content, template_selector, contains_selector)
+
+ def assertTemplateE
...
+ self._assertTem
+ content, template_selector, contains_selector, reverse=True)
The above is a bit of an anti-pattern. The `reverse` condition should
ideally be moved elsewhere, like up into the calling functions:
def findTemplate(self, content, selector): content) .cssselect( template_ selector)
self.assertEqu al( snippets[ 0].text)
snippets = fromstring(
1, len(snippets),
"The snippet '%s' does not exist." % selector) # XXX: See [4]
return fromstring(
def assertTemplateE xistsAndContain s(self, content, template_selector, te(content, template_selector)
self.assertNot Equal( cssselect( contains_ selector) ),
...
template = self.findTempla
0, len(template.
"The element '%s' does not exist." % contains_selector)
def assertTemplateE xistsAndDoesNot Contain( self, content, template_selector, te(content, template_selector)
self.assertEqu al( cssselect( contains_ selector) ),
...
template = self.findTempla
0, len(template.
"The element '%s' should not exist." % contains_se...