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

Martin Betak mbetak at redhat.com
Mon Jul 25 18:54:39 UTC 2016


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/



More information about the Devel mailing list