Re: [ovirt-devel] Type Safety on the Frontend (refactoring of all async queries)

From: "Martin Betak" <mbetak(a)redhat.com&gt; To: "devel" <devel(a)ovirt.org&gt; Cc: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, "Tomas Jelinek" <tjelinek(a)redhat.com&gt;, "Alexander Wels" <awels(a)redhat.com&gt; 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/