>Since there has >not been extensive testing and discovery for the event quirks and behaviours >of Opera, it is completely unknown how well wave will work - it may work >perfectly, it might crash on startup, not because of bugs, just because of >differences in incredibly fine-grained behaviour. Building an extra >permutation does no harm, but it depends on what level of support you want >to claim for Opera
Just my 2 cents as a Opera user, we are generaly happy for lack of testing...thats fair enough given the relatively tiny (desktop) market share. But we like to have a "proceed at our own risk" option. Also, In the past, as long as its not blocked completely popular sites can often got little client-side patchs or scripts to get them working. ~~~~~~ Reviews of anything, by anyone; www.rateoholic.co.uk Please try out my new site and give feedback :) On 26 April 2011 12:17, Thomas Broyer <[email protected]> wrote: > Hi David, > > On Tue, Apr 26, 2011 at 8:48 AM, David Hearnden <[email protected]> wrote: >> Hi Thomas, >> >> On Wed, Apr 20, 2011 at 11:47 PM, Thomas Broyer <[email protected]> wrote: >> >> On our current project (whose UI is made with GWT), we're in need of a >>> rich-text editor with "semantic markup" (marking up "people", >>> "locations", etc. and possibly linking them to other items in our data >>> repository) and constrained content (sometimes we don't want >>> titles/subsections or tables, and sometimes even limit editing to a >>> single paragraph with "semantic markup" only). We only target Firefox >>> 4 (or whichever stable version will be current by the time we ship, >>> lucky us!). In search of the "perfect editor" for the task (or rather, >>> the challenge!) it became obvious to me that Wave's editor would be >>> the perfect fit: model-based, entirely "emulated" (no >>> contentEditable=true, meaning we have full control on which user >>> actions produce which content), built with GWT, etc. >>> >> >> Note that the wave editor does use content-editable for basic typing events >> in some browsers (IE and Webkit, but not Firefox I believe? Pat or Dan can >> correct me). The infrastructure is designed so that for any extensions you >> write ("doodads") you can control how much happens programmatically and how >> much happens through native browser content-editable, so if you want to >> avoid content-editable you certainly can. > > My goal is not to rule contentEditable out. I simply want something > that "just works" ;-) > ...and contentEditable generally complicates things (when used > "alone"): browser-specific generated markup, not much control on what > can get in ("hey, let's paste this 80 page MSWord doc, with tables, > images, floating frames, etc."). > >> So, I'm in the process of integrating the Editor component in our app >>> (prototyping in a test-bed app for the time being) and I'm facing a >>> "major issue" (well, not that much given our specific environment, see >>> below) and seeing a few possible enhancements; both of them being >>> related to how Wave uses GWT and "integrates" with it. >>> >>> First, Wave overrides the "user.agent" deferred-binding property (and >>> property provider) to add new "iphone" and "android" values and remove >>> Opera support. While this is not a showstopper for us (given that we >>> only support Firefox 4 –and Chrome, as we're almost all using Chrome >>> in the dev team–) it might cause issues to others (e.g. someone having >>> to support Opera, even if it means disabling the Editor for them). >>> Proposal: GWT has had "conditional properties" for this exact use case >>> for a few releases. >>> http://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties >>> >>> >> I've got no objection to adding opera back in to the list of user-agents for >> which we build permutations. However, as Pat mentioned, rich-text editing >> in browsers is horrible, and in order to overcome this as much as possible, >> the editor code hooks in very tightly with each browser. Since there has >> not been extensive testing and discovery for the event quirks and behaviours >> of Opera, it is completely unknown how well wave will work - it may work >> perfectly, it might crash on startup, not because of bugs, just because of >> differences in incredibly fine-grained behaviour. Building an extra >> permutation does no harm, but it depends on what level of support you want >> to claim for Opera (wave claims none, purely because nobody's done the >> work), and how much that support is worth to your project (e.g., waiting for >> the extra build time). > > As I said, we're only interested in "latest Firefox" (Firefox 4) > support, so (in retrospect) it's actually not an issue at all *for > us*. But I don't like it when a library overwrites things that way, > and if I can help make the editor a library on its own, I'll gladly > contribute (my next patch probably will be adding an ant target to > build a JAR of the editor code and its dependencies, as I'd rather not > "fork" Wave just for a few things like that). > >> As for the conditional properties change, that looks great. >> >> Wave also inspired new features of GWT, and the codebase hasn't been >>> migrated to the "gwt-user" APIs once they were integrated, which >>> results in almost-duplicated code once you start integrating Wave code >>> within another application. The most notable (and maybe only) such >>> feature is SafeHtml. >>> >> >> The core client libraries of wave try and make minimal use of GWT, for >> performance and portability. Testability (outside GWTTestCase) and >> server-side rendering capabilities were two top-priority goals for the parts >> of the client that use the package you mention (e.g., the custom SafeHtml >> package), so minimal use of GWT libraries follows from that naturally. > > Increasing parts of GWT can be used in both client and server side (or > more accurately "compiled to JS" and "run in a plain JVM": event, > regexp, safehtml, autobean, requestfactory, and soon i18n). > Some project(s) inside Google use RequestFactory without GWT (I guess > it's on Android), so they extract a JAR containing only the needed > parts (see > http://code.google.com/p/google-web-toolkit/source/browse/trunk/requestfactory/build.xml > and > http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/web/bindery/requestfactory/server/RequestFactoryJarExtractor.java > ). The same could be done for SafeHtml in due course. > >> There are of course many other possible enhancements, some of them >>> already listed as TODOs in the code, but I'm first interested in those >>> that will have a direct impact on the size of the compiled JS output. >>> >> >> Anything that reduces the code size is very welcome! > > As I clarified in the code-review: the SafeHtml patch aims at reducing > duplicated code between GWT and Wave. It shouldn't have much impact on > WiaB, but should reduce code size when integrating parts of Wave (e.g. > the editor) into other GWT apps that already make extensive use of > SafeHtml (though Cell widgets). > >> I'm sorry I didn't chime in sooner! I've commented in your SafeHtml patch. >> Regarding other changes you may have in mind, anything that makes wave >> components smaller and/or faster and/or more widely accessible is very >> welcome. But since much of the code makes minimal use of GWT, for various >> reasons, adding in GWT dependencies is unlikely to achieve those goals. >> However, there are core parts of GWT that we could perhaps leverage >> more, e.g., working on the runAsync boundaries (figuring out which parts are >> going where, finding more optimal split points, etc.), adding in i18n >> support, etc. > > For the time being, I'm only interested in the editor as a standalone > component (sorry), so my contributions will likely limit to this part > only, and most probably will be about decoupling it from Wave (we > already have 2.5Mb of compiled JS code –yes, for a single permutation– > without the editor, so code size improvements will be more about > cutting things out than optimizing them I'm afraid). The next > milestone of our project, with the rich text editor, is due mid-June > and I have everything to do (storing our docs, sending them to/from > the client, etc. and all that almost alone, as other devs are busy on > other features) so I won't have much time to dedicate improving the > code. > > That being said, I liked Google Wave for discussing around design docs > (even though most features are now integrated into Google Docs, but we > haven't "gone Google" at work so there's a small chance we'll use WiaB > at some point) so I'll probably contribute in the future (at a minimum > as a think to your awesome work, pushing browsers in a corner, and > move the Web forward), but as many of us I'm already short in terms of > spare time. > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ >
