Bug 1123620 - [RFE] dialog validations: automatically mark a side-section as invalid if it contains at least one invalid field
Summary: [RFE] dialog validations: automatically mark a side-section as invalid if it ...
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: ---
Hardware: Unspecified
OS: Unspecified
medium vote
Target Milestone: ---
: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Pavel Stehlik
Whiteboard: ux
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-27 10:21 UTC by Lior Vernia
Modified: 2015-11-18 23:16 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2015-11-18 23:16:32 UTC
oVirt Team: ---
ylavi: ovirt-future?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?

Attachments (Terms of Use)

Description Lior Vernia 2014-07-27 10:21:37 UTC
Description of problem:

In composite dialogs which comprise multiple left tabs, it is customary to mark the tab(s) as invalid where and GUI widgets had failed validation. This is currently done in a manual fashion, leading to sizeable boiler-plate code wherever this logic is implemented.

This can and should be automated, as the logic is quite simple - if any widget under the hierarchy of a tab is invalid then mark the tab is invalid - and the required information (which widgets belong to which tab) can be deduced from the DOM layout of the dialog.

Outline of possible solution:

Currently our validation scheme works as such: it is triggered on the model side, as part of the dialog approval flow. Each member of the model is [in]validated, which potentially triggers an event on the view side to mark a widget as [in]valid. This can only happen if the widget implements HasValidation, and the vast majority of our widgets implement that via inheritance from AbstractValidatedWidget.

To build on this scheme (rather than change flows), I suggest to modify the treatment on the view side. As part of AbstractValidatedWidget.markAs[In]Valid(), we may also traverse up the DOM element parent tree and search for tabs - or more generally, for widgets that would implement an interface such as HasCompositeValidation (which could extend HasValidation).

DialogTab would be the first widget to implement this interface, which would expose at the very least a method markDescendentAsValid(boolean valid, Widget descendent). DialogTab would keep a HashSet that would remember its descendents that had been marked as invalid, whenever markDescendentAsValid() is called it would update this set. The tab itself will be rendered valid if and only if the set is empty.

While conceptually non-trivial, this solution should take little coding and would work well with our current validation scheme. A missing detail is how to obtain widgets back from DOM elements - Google does suggest a couple of fishy solutions, but at worst we could keep a map of this ourselves.

* A different alternative would be to change our validation scheme to be triggered automatically as part of the dialog lifecycle methods rather than manually from the model side, and then traverse the DOM tree from root to leaf. Traversal in post-order will enable [in]validating tabs (as an example) without having to keep a set to "remember" which widgets had been marked as invalid. This would save even more boiler-plate code (with respect to triggering validation on the model side) but will require wider changes.

Comment 1 Yaniv Lavi 2015-04-07 07:06:39 UTC
Is this a dup of BZ #1057386 ?

Comment 2 Lior Vernia 2015-04-07 08:07:23 UTC

Comment 3 Einav Cohen 2015-04-07 15:16:14 UTC
(In reply to Lior Vernia from comment #2)
> No.

correct :)

Comment 5 Einav Cohen 2015-11-18 23:16:32 UTC
this is a code-change (no impact on user - only developer) not worth investing in at this point IMO -> closing.

Note You need to log in before you can comment on or make changes to this bug.