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/
