On 27 oct, 10:24, Sebastian Beigel <sebast...@beigel.de> wrote: > > 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).
Then implement it on a "root" JSO that all your other JSOs will extend. If you were coding in JavaScript, no doubt you'd give the same names to the properties in the JS objects (or JSON objects if we think in terms of "what goes on the wire"), it shouldn't be any different here, so your getId and getLabel could be final methods (you'd always do "return this.id" and "return this.label", so why not writing it once only in a final method?) You can face an issue if your "label" for instance is not really a "property" of the object but rather built from other properties depending on the actual object; but then you should have a getLabel() method at the JavaScript level, so again you can write your method as final (return this.getLabel()). This approach wouldn't work if you objects come from parsed JSON, but then it wouldn't work in "pure JS" either, so it's not an issue with the tooling and its design, but with your use of it: JSOs are a bridge between the GWT-Java and the JavaScript worlds, they're not intended as an "optimization tool". My rule of thumb is that even though your eyes see Java code, you have to keep in mind that you're developing in JavaScript in the end. Either that, or you add an abstraction level, and lose some optimizations (in this case, you do not use JSOs, and lose their "lightweightness") > > 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. See my remark above about abstractions vs. optimizations. > Did you do any comparison in size and performance for the JSO vs. > native beans approach? Not formally no. But JSOs do not generate "class" code (initializing the prototype, etc.), and in most cases your methods will be inlined (as they'd do with non-JSOs too, by the way). Lists et al. on the other hand generate a lot of code re. IndexOutOfBoundsException, etc. and a enhanced for loop will instantiate an iterator (yet another class). Note that I'm not saying you should use/have used JSOs, on the contrary; I'm just enlightening the fact that JSOs are for a specific "task", there's no one-size-fits-all: JSOs might fit your needs, but if they don't, don't fight them, it just means you should use/have used something else. When mapping JS libs for use in GWT (such as OpenLayers or the Google Maps API), JSOs are wonderful! They work quite well when receiving JSON from your server too, but that's all: accessing "parsed from JSON" properties from the Java world with a clean syntax, which is very different from getting "data model beans" (with some "logic" in them) from JSON! (for that, you'd either wrap a JSO in a GWT-Java class, or use external "helpers" such as GWT 2.1 ProvidesKey) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
