Hi David You mentioned above the server side HTML rendering. I wonder why it would take to hook this in? Undercurrent has four stages with each being responsible for a certain task. If I understand it correctly they are: Stage Zero : Loading critical code, like exception handling. Stage One: Installing Wave panel. Stage Two: Wave rendering + installing liveleness. Stage Three: Installing Edit actions. Now, I have two questions: 1)Why Stage Two doesn't render blips with DocRefRenderer (it uses DocRefRenderer.EMPTY implementation), but instead relies on PagingHandlerProxy? If understand it right, it means the wave is not rendered until the liveleness is established. Why not render the wave fully and display right away and only then establish liveleness? 2) I investigated the FullDomWaveRendererImpl and it seems to me entirely possible to fully render the HTML on the server side. Can you maybe outline steps how to actually hook up the server side rendered HTML into Undercurrent?
Thanks Yuri 2011/4/26 David Hearnden <[email protected]> > 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 >
