Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [riena-dev] NPE from AbstractSWTWidgetRidget.saveData() 
Yep, I just looked at the code in Widget in more details. It's pretty clever:

- If you only invoke setData(object) then data will NOT be an array -
so our code has to deal with this case (as Stefan commented).
- We also have to deal with null
- If you have invoked at least setData(key, object) once, then it will
be an array

I agree with Christian, that I didn't see a way to do what we do
without reflection :(. But we should try opening a bugzilla against
SWT...

One minor gripe I still have: I believe we are not removing previous
keys from the widget before restoring the saved ones (only from the
ridget). Meaning that the widget ends up storing a superset of all
keys and propably keeping things around for longer than needed.
Correct?

Kind regards,
Elias.


On Wed, Sep 22, 2010 at 11:32 PM, Campo, Christian
<Christian.Campo@xxxxxxxxxxxx> wrote:
> Hi Stefan,
>
> thats exactly the reason why Heiko decided to use reflection. We talked about it briefly yesterday and there is no generic way in SWT to get all Data objects from an SWT Widget to save them in the ridget when you unbind for shared views. There is also no way to iterate over data objects (like a keyset or entryset). So using Reflection is ugly but currently the only way that we have found.....
>
> christian
>
> ________________________________________
> Von: riena-dev-bounces@xxxxxxxxxxx [riena-dev-bounces@xxxxxxxxxxx] im Auftrag von Liebig, Stefan [Stefan.Liebig@xxxxxxxxxxxx]
> Gesendet: Donnerstag, 23. September 2010 08:22
> An: Riena Developers list
> Betreff: Re: [riena-dev] NPE from AbstractSWTWidgetRidget.saveData()
>
> Hi Elias,
>
> I think that what in AbstractSWTWidgetRidget happens is to save and restore the content of the widgets data field. But this is not possible in a generic way with the existing API of the Widget class because you can´t "see" the state (KEYED_DATA) and you can´t get all keys or something like an EntrySet from the Widget.
> Have I overlooked something?
>
> Tschüß,
> Stefan
>
>> -----Ursprüngliche Nachricht-----
>> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-
>> bounces@xxxxxxxxxxx] Im Auftrag von Elias Volanakis
>> Gesendet: Donnerstag, 23. September 2010 08:03
>> An: Riena Developers list
>> Betreff: Re: [riena-dev] NPE from AbstractSWTWidgetRidget.saveData()
>>
>> Stefan,
>>
>> I agree. The more I look at the our method the more I think direct access to
>> widget.data is a bad idea. We should use the official API
>> instead: w.setData(key, Obj) / w.getData(key)
>>
>> Elias.
>>
>> On Wed, Sep 22, 2010 at 10:48 PM, Liebig, Stefan
>> <Stefan.Liebig@xxxxxxxxxxxx> wrote:
>> > Hi Elias,
>> >
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-
>> >> bounces@xxxxxxxxxxx] Im Auftrag von Elias Volanakis
>> >> Gesendet: Donnerstag, 23. September 2010 05:53
>> >> An: Riena Developers list
>> >> Betreff: [riena-dev] NPE from AbstractSWTWidgetRidget.saveData()
>> >>
>> >> I am seeing some NPEs from saveData() in the tests (for example in
>> >> CompositeTableRidgetTest).
>> >
>> > Yes, this needs to be fixed.
>> >
>> >>
>> >> From my POV there are two things that need to be changed there:
>> >>
>> >> 1. widget.data can be null (see contract of widget.getData()). The
>> >> saveData() method has to be able to deal with this 2. Why are we
>> >> using reflection instead of widget.getData() ?
>> >
>> > Yes, even I remembered the getData() and was wondering but getData()
>> does not always return the content of the data field.
>> > What it returns depends on its internal state field. I guess that this the
>> reason for using reflection.
>> >
>> > Another problem is assuming that the data field is always an object array in
>> the method saveData(), or?
>> >
>> >>
>> >> Greetings from Portland,
>> >> Elias.
>> >
>> > Tschüß,
>> > Stefan
>> >>
>> >> --
>> >> Elias Volanakis | Technical Lead | http://eclipsesource.com
>> >> elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | @evolanakis
>> >> _______________________________________________
>> >> riena-dev mailing list
>> >> riena-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/riena-dev
>> >
>> > -------------------------------------------------------------
>> > compeople AG
>> > Untermainanlage 8
>> > 60329 Frankfurt/Main
>> > fon: +49 (0) 69 / 27 22 18 0
>> > fax: +49 (0) 69 / 27 22 18 22
>> > web: http://www.compeople.de/
>> >
>> > Vorstand: Jürgen Wiesmaier
>> > Aufsichtsratsvorsitzender: Christian Glanz
>> >
>> > Sitz der Gesellschaft: Frankfurt/Main
>> > Handelsregister Frankfurt HRB 56759
>> > Ust-Ident.-Nr: DE207665352
>> > -------------------------------------------------------------
>> >
>> > _______________________________________________
>> > riena-dev mailing list
>> > riena-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/riena-dev
>> >
>>
>>
>>
>> --
>> Elias Volanakis | Technical Lead | http://eclipsesource.com
>> elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | @evolanakis
>> _______________________________________________
>> riena-dev mailing list
>> riena-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/riena-dev
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>



-- 
Elias Volanakis | Technical Lead | http://eclipsesource.com
elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | @evolanakis

Back to the top