".e., to have a build setup that has user-agent specific builds, with compile-time minimization, and also an all-agent build? It might take some GWT-fu to set that up."
GWT makes specific optimized builds for 6 or so user agents as its normal compilation - no effort needed. You can override compilation includes if needbe, but I have only had to do it once myself (when one version of gwt broke the history support in Opera, I could tell it to use the older method for that browsers code Generally speaking, gwt apps start a bit bigger, but dont grow in size much unless you add a awful lot more code. The minimization works well. The other option - if its really needed - is you can split the code itself up so it doesn't all need to load at once. ~~~~~~ Reviews of anything, by anyone; www.rateoholic.co.uk Please try out my new site and give feedback :) On 6 February 2012 02:02, David Hearnden <hearn...@google.com> wrote: > 1) Yes please! Cutting the Blip -> Document dependency would make the code > cleaner. > > Client side, I don't think that Blip::getDocument() is used. Undercurrent > has its own DocumentRegistry to look up the document object for a > particular blip, rather than getting it from the blip directly, in order to > have client-side specialization of document behaviour like diff > highlighting. I can't speak for the WIAB server though. > > Alternatively, the "proper" Java solution would be to make the conversation > model generic in the document type. Conversation<D>, ConversationBlip<D>, > ConversationThread<D> etc. That would mean that Blogger could use > Converation<HtmlBlob>, WIAB client could use > Conversation<ClientDocumentImpl>, and WIAB server could use > Conversation<Document> or whatever it needs. I don't know if that solution > would just add more convolution than it saves though. Generics can add a > significant amount of unnecessary verbiage and wrangling, and plenty of > engineers who should know better are afraid of them. > > 2) That does sound good, especially for development. > > But I don't think it can be called a good thing or a bad thing without > knowing the impact on code size. It might be possible to have both, > however. i.e., to have a build setup that has user-agent specific builds, > with compile-time minimization, and also an all-agent build? It might take > some GWT-fu to set that up. > > Regarding Walkaround, my guess is that if WIAB keeps working, Walkaround > will keep working too. I don't think its use of Undercurrent has any extra > needs beyond what WIAB does. Dan can correct me if I'm wrong. > > -Dave > > On Thu, Jan 19, 2012 at 2:50 AM, Yuri Z <vega...@gmail.com> wrote: > >> Hi Patrick. >> First of all - congrats on the Blogger improvement - it's really great to >> see how GWave advancements slowly make it into mainstream. >> Regarding your suggestion - can you maybe describe what the the possible >> of the proposed change? Generally - removing dependencies - sounds great. >> Also, if it's useful to your project, it can be also useful for others. >> The only concern it about Walkaround project - which also uses >> Undercurrent. >> @David, can you please share your opinion? >> >> >> On Tue, Jan 17, 2012 at 8:18 AM, Patrick Coleman >> <patcole...@google.com>wrote: >> >>> Fellow wave-dev'ers; >>> >>> For those who missed the recent announcement, my current project (Blogger) >>> just launched threaded commenting: >>> http://buzz.blogger.com/2012/01/engage-with-your-readers-through.html >>> >>> The reason I'm emailing here though is that all the comment rendering code >>> uses the Undercurrent wave-panel GWT library. >>> (e.g. check out the DOM produced in the comments section of that post, it >>> may look familiar). >>> >>> I'm aware that this alternate usage may add some constraints moving >>> forwards with the codebase, so I was wondering if there was a generally >>> recommended way of sharing code like this - e.g. are there any large >>> changes planned to Undercurrent that mean I should fork my own copy first? >>> Alternatively, if there are changes I hope to make, are they likely to >>> help >>> being submitted into the apache codebase? >>> >>> If it helps, the main two changes I'd hope to work on for our usage are: >>> 1) Removing the dependency from Blip to Document >>> - Comments are just static html, so I have a custom CommentDocument for >>> this, but due to the interfaces it needs to >>> pull in ContentDocument, MutableDocument and DocInitialization which >>> bloats >>> the library size >>> 2) Adding an alternative to UserAgentStaticProperties that is actually >>> dynamic - i.e. removes the requirement to have a different script per user >>> agent. >>> >>> fwiw, thanks to all of those active in this community that've kept this >>> code open and nicely usable for such a different feature such as this. >>> >>> - Pat Coleman >>> >> >>
