Thomas - It's awesome to see that the editor is coming in useful in other applications! It was certainly designed for this sort of usage, so I hope it comes in useful.
In terms of the history you were talking about; there will likely be a few things of GWT that it doesn't use the suggested version of (like SafeHTML), a number of the GWT tools weren't around when the editor code was first written but should use a similar API to what's out there currently so in theory it could be migrated to the proper libraries (from memory, @Dan - can you think of anything missing in the GWT SafeHTML that the editor needs?) In terms of Opera support; the tricky part is that to have a good editing experience for even the current browser set we needed workarounds for things like selection logic and event processing, stuff that can't be covered by capability checking client-side (e.g. see QuirksConstants). We do have some level of defaults that was intended to be what an ideal standards/w3c-compliant browser would behave, so it could be possible to turn on Opera and give them the default editor (or maybe replace it with the webkit/gecko/trident editor) but my guess is doing that would result in some behavioural quirks that could get annoying while editing and would require QuirksConstants workarounds. Good luck with the integration! :) - Pat Coleman, former wave editor engineer On 22 April 2011 06:01, Yuri Z <[email protected]> wrote: > Sounds good to me. Looking forward for your patch. > > 2011/4/20 Thomas Broyer <[email protected]> > > > Hi everyone, > > > > First, let me introduce myself: I'm a french software engineer working > > in a small IT consulting company. I'm working with GWT for 3 years now > > and contributing patches on a regular basis (BTW, I'm the only > > non-googler listed as a project member on the code.google.com site). > > > > 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. > > > > 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 > > > > 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. > > > > 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. > > > > If everyone's OK with these changes, I'm ready to work on a patch in > > the upcoming days. > > > > -- > > Thomas Broyer > > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> < > http://xn--nna.ma.xn--bwa-xxb.je/> > > >
