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

2016-07-26 Thread Vojtech Szocs
Great work, Martin!

Always happy to see improvements in UI code :)

Vojtech


- Original Message -
> From: "Martin Betak" 
> To: "devel" 
> Cc: "Vojtech Szocs" , "Tomas Jelinek" 
> , "Alexander Wels" 
> 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/
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


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

2016-07-25 Thread Martin Betak
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/
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel