Hi Thomas,
On Wed, Apr 20, 2011 at 11:47 PM, Thomas Broyer <[email protected]> wrote:
> 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).
>
Nice to see you here!
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.
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 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.
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! The core wave client
libraries adopt a staged loading approach, leveraging GWT's runAsync. There
are some things that are currently subverting that design, but in general,
the best strategy for minimizing user latency is to have server-rendered
content delivered as plain HTML, so that the user sees content before any JS
runs at all. This flow is contrary to GWT's architecture, and makes the
latency of large JS downloads less severe than a regular GWT app. But
still, the WIAB client is over 1M of JS, and is unlikely to have
server-rendered content for a while, so reducing the JS size will certainly
have medium-term wins. Off the top of my head, I don't have any good ideas
on where to start to trim it down. It depends on whether you're focusing on
just the rich text editor package, the core wave code + UI, or the
surrounding WIAB client.
If everyone's OK with these changes, I'm ready to work on a patch in
> the upcoming days.
>
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.
-Dave
