> You can very well subclass JSOs [...] What you cannot do is virtual > dispatching (i.e. overring methods: > methods must be final, but not necessarily classes).
Of course you are right -- I wasn't precise (and thus wrong :) What I meant (and "hate" :) is that you're not allowed to override methods and that there is a "one interface to one JSO" constraint (since GWT 2.0). I like to have my domain models implement something like EntityModel (a custom interface declaring Integer getId() and String getrLabel() for example). That way, I can really simple build/populate things like ListBoxes etc. GWT 2.1's ProvidesKey et al. gives us another (and more flexible) solution for these problems though. > That's why I created JsCollections a while ago with a set of > JsArrays.toArray() methods that copies the JsArray into an array in > DevMode but just "casts" it in prod mode (i.e. no single overhead once > compiled to JS). I used to do something similar. For dates and date-times as well (as these types are Strings in the JSON requests -- this works best for me at least). But I must admit, I'm lazy and I just (would) prefer to not think about these conversions and "just use" Lists, Dates etc. as I do on the server side. Did you do any comparison in size and performance for the JSO vs. native beans approach? Sebastian -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
