[Freeipa-devel] [PATCH] 32-47 #2040, #1515 Refactor UI widgets
Endi Sukma Dewata
edewata at redhat.com
Fri Dec 2 17:54:56 UTC 2011
The UI seems to be working like before, so patches #32-47 are ACKed. But
I'd rather wait until the unit tests are completely fixed before pushing.
I'm going to rebase the HBAC Test patches on top of these.
I have some comments below, but they can be addressed separately.
On 11/30/2011 10:37 AM, Petr Vobornik wrote:
>> 6. Open a self service permission, click 'select all' checkbox. The
>> update should have become enabled.
> Fixed [aci patch #43]
When resetting the page the 'select all' remains checked. This is an
existing problem.
>> 10. In sudo.js you use apply() to call push() like this:
>>
>> spec.fields.push.apply(spec.fields, [...]);
>>
>> Why not call spec.fields.push(...) directly?
>>
> Fixed. My mindset was: i want to push an array. It would be probably OK
> if the array was already defined somewhere else. [sudo, hbac patch #45]
There are 2 more in line 242 & 249.
11. Create a permission with target 'type'. Edit it, change the type,
the attributes will change accordingly. Then click undo/reset, the
attributes do not revert back. This is an existing problem.
12. In IPA.checkboxes_field the 'checkbox_load' should have been
'checkboxes_load'. The commented code is not necessary, checkboxes field
is different because it can be empty whereas checkbox field always has a
value (on/off).
13. The IPA.field.test_dirty() can call widget.save() directly instead
of field.save(). It will make more sense because we're comparing the
widget's current value with the field's original value. Also this way we
don't have to support 2 modes in field.save(): with param and no param.
14. The IPA.rule_details_widget probably can be removed or converted
into a field. The category radio widget and the tables probably can be
defined directly under the section.
15. The IPA.column still depends on entity to get the column labels. If
the table is used by a field that contains pkey of another entity, the
field should get the entity's metadata and set the column labels when
creating the table. If the table is used by search facet, the facet
should supply the labels.
16. The IPA.entity_select_widget should be converted into a subclass of
IPA.combobox_field which uses the IPA.combobox_widget. The existing
class only contains data handling logic, it doesn't change the UI.
17. The IPA.attributes_widget probably can be converted into a subclass
of IPA.checkboxes_field which uses the IPA.table_widget.
18. Similarly, the IPA.rights_widget can be converted into a subclass of
IPA.checkboxes_field which uses the IPA.checkboxes_widget. In general if
the UI doesn't change we should reuse existing widgets and we should do
the behavior customization in the field.
19. The IPA.permission_target_widget can switch inheritance from
different super classes (ie. collapsible or non-collapsible section)
depending on the parameter. While this is possible in JS, the concept is
difficult to translate to other OO framework (in case someday we want to
change). Here's the current class hierarchy:
section (composite widget)
+ collapsible section (details section)
+ details table section
+ permission target section <--
+ non-collapsible details table section
+ permission target section <--
I think the decision whether to use a collapsible or non-collapsible
section should be separate from the permission target section. One
solution is to use the following class hierarchy:
section (composite widget)
+ table section
+ permission target section
+ collapsible table section <--
+ collapsible section
+ collapsible table section <--
In the details facet definition the permission target section should be
specified as a member widget (not a subclass) of collapsible section. In
the dialog box the permission target section should be used directly.
For other widgets in the details facet, they can be put under a
collapsible table section. The class can be implemented either as a
subclass of table section or collapsible section, whichever is easier,
but it doesn't mean it can switch inheritance.
--
Endi S. Dewata
More information about the Freeipa-devel
mailing list