[ovirt-devel] Type Safety on the Frontend (refactoring of all async queries)
Hi All,
today a *major* frontend refactoring was merged [1].
Its purpose was to remove some of the most significant artifacts of legacy C# code.
Huge thanks to Vojtech and Alex for heavenly patience during code review!
For a complete description please see the commit message, but here are
some highlights for programmers that need to touch FE code:
1) AsyncQuery, AsyncCallback and Converter are now generic and typesafe
(formerly INewAsyncCallback and IAsyncConverter).
2) It is no longer possible (or desirable) to PASS MODEL to queries.
From within Model sublasses `new AsyncQuery<>(...)` will have the correct value
set
(see patch for impl details) and if you want to run a query on a different model
(so the infrastructure would set the progress spinner on that model instead),
usually for the purpose of a ListModel showing a popup window - where we want to
display the spinner on the dialog window instead, you can use the
`myWindowModel.asyncQuery(...)` helper factory to create query with model set
to myWindowModel.
// note: this also has the nice side-effect of eliminating the harmful pattern of using
// the model value from within callbacks by casting it to surrounding model type (while
that
// value is already available by feature of java inner classes)
3) AsyncDataProvider's API methods now deal with strongly typed queries. This is
facilitated
through usage of strongly typed Converters (please see some defined converters ->
usually
you just need a CastingConverter<> or a ListConverter<>).
Please use this architectural layer of strongly typed AsyncDataProvider to your
advantage.
(as plain Fronted.runQuery does not provide any guarantees and leaves you at risk of
mis-casting the return value).
If you have any more questions please feel free to ask me or look at the patch for
details
(warning: it's quite big!).
This kind of major change necessarily touched all areas of the code (those issuing
queries...)
and there is of course some probability that something may break. But I believe this risk
is
well outweight by the benefits. Nevertheless if you find any issue please let me know and
we can fix it together.
Thanks again to anyone who contributed to this noble effort.
Best regards :-)
Martin
[1] https://gerrit.ovirt.org/#/c/60822/