Great work, Martin!
Always happy to see improvements in UI code :)
Vojtech
----- Original Message -----
From: "Martin Betak" <mbetak(a)redhat.com>
To: "devel" <devel(a)ovirt.org>
Cc: "Vojtech Szocs" <vszocs(a)redhat.com>, "Tomas Jelinek"
<tjelinek(a)redhat.com>, "Alexander Wels" <awels(a)redhat.com>
Sent: Monday, July 25, 2016 8:54:39 PM
Subject: 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/