What I was wondering is, if you do that permission thing inside GWT's FieldWriter then isn't it annoying that you now must assume that all security relevant @UiFields may be null? So you must do quite a bit of null checks and deal with the fact that GWT developers normally think that a @UiField is never null and maybe tend to forget about that?
Sure that having null widgets might need more checks, but it's a good way to check that all is working as expected: it's somehow a runtime compiler In other terms: If you have a field that shouldn't display and you do processing on it thinking that it's there, you never get a chance to realize that you can't do that for a given profile. A null pointer warns you that the field is not available and that you have to consider that situation in your program. Sure a more evolved way would be to have a "ghost Widget" that has a flag to warn the developer (throw an exception, write to error log or do another action in a global setting). This would imply to create a mechanism to populate the @UiField with a non dom lightweight instance of his object. I think it's over engineering for, at the end, a very similar result: warn the developer with a more developer friendly message than the NPE. I think it's not worth it, but I could definitely change my mind if we discuss the subject more deeply and find other advantages to it -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
