Hmm, Chrome/Gmail formatting fail. Let's try that again.
Sorry to chime in late to this discussion. It seems like it comes up every now and again. My opinions:* I welcome any effort to rewrite the top level WIAB client component (the bit that glues together the search panel, wave panel, websocket etc).* I don't see how Gin will add any value. Dependency injection yes, but you don't need Gin for that. I'd weigh up the advantages of Gin over plain dependency injection before deciding to use it.* The wave panel (Undercurrent) is architecturally forbidden from using any part of GWT other than its Java -> JS compilation ability. No widgets, no UIBinder, etc, which I suspect means no Gin there either. And now, the longer explanation of why I have those opinions: * The top-level WIAB client code definitely needs a lot of love. The top-level code was never been designed. It started from a proof-of-concept demo app and just evolved incrementally by necessity. I'm in favour of any effort to refactor it, or rewrite it completely, to make it more modular and use best-practice techniques (like dependency injection, testing etc). * Once code is already written with dependency injection, I don't see how Gin adds any value on top. I'm not opposed to it if it does no harm (download size, latency, debuggability, control and flexibility, runAsync boundaries, etc). * The wave panel (Undercurrent), already uses dependency injection, and each stage has a component provider that does the same thing as a Guice injector, but is static rather than dynamic so you can see what's going on, and have complete control over how things get put together. Those providers are also designed for extensibility, so other environments can replace individual components with minimal effort, which I do not believe is possible with Guice/Gin. * The architecture of Undercurrent is designed for low-latency startup and to scale well with large numbers of UI components. It is designed for how browser and JS event handling works. This architecture is incompatible with how GWT's widget system, which does not scale to large numbers of UI components. * Undercurrent had some particular design goals which are impossible to achieve as a regular GWT component. (0(1) startup overhead, view state entirely in HTML, convergent client/server rendering, etc). The main reason, and perhaps the only reason, that Undercurrent uses GWT is to share rendering and OT code between client and server. i.e., GWT is used solely as a Java -> JS compiler. It is not a typical GWT app in that sense,and can never be one. That doesn't mean it can't be used in other GWT apps, but it won't be as trivial as if it were a simple GWT component. I'd be hesitant to try and make Undercurrent look like something that it isn't (and can never be). * If those design goals are not a priority for the wave panel in WIAB, and at the current time I'm not sure that they are, then a completely new wave UI stack could be written with a simpler and more conventional GWT UI approach, and so would perhaps be easier to add into other conventional GWT apps with minimal fuss. It could be Ginned, UiBound, Activitied, and EventBussed, and hooked up with whatever new gizmos GWT comes up with next. Unfortunately, no such component exists, so it would have to be written from scratch. @Vicente: I think most or all of your requirements can be met with Undercurrent as-is. I'm happy to help out with more information later, but the general approach would be to look at the DefaultProviders of StageTwo and StageThree to see how the rendering and editing components are hooked up. From there, pick a component or a configuration you want to change. If it is not exposed in a configurable way, you can refactor the stage to do so. Then, subclass that DefaultProvider, and replace the component you want with your version. In your own app, use your own version of Stages that uses your custom subclass of a stage's provider, rather than the default one.e.g., to add custom buttons to the toolbar, you could:* In StageThree.DefaultProvider.createEditActions(), replace EditToolbar.install() with getEditToolbar().install(), where getEditToolbar()/createEditToolbar() now exposes the EditToolbar as a configurable component, so your subclass can override createEditToolbar() and provide your own one with its own buttons.* Or, replace EditToolbar.install() with configureEditToolbar(EditToolbar.create()), moving EditToolbar's implicit set of buttons out into something configurable, and override configureEditToolbar() with your own configuration.* Or whatever else works - it should be just a simple matter of programming. HTH, -Dave On Mon, Nov 21, 2011 at 11:26 AM, David Hearnden <[email protected]> wrote: > Sorry to chime in late to this discussion. It seems like it comes up > every now and again. My opinions:* I welcome any effort to rewrite > the top level WIAB client component (the bit that glues together the > search panel, wave panel, websocket etc).* I don't see how Gin will > add any value. Dependency injection yes, but you don't need Gin for > that. I'd weigh up the advantages of Gin over plain dependency > injection before deciding to use it.* The wave panel (Undercurrent) is > architecturally forbidden from using any part of GWT other than its > Java -> JS compilation ability. No widgets, no UIBinder, etc, which I > suspect means no Gin there either. > And now, the longer explanation of why I have those opinions: > * The top-level WIAB client code definitely needs a lot of love. The > top-level code was never been designed. It started from a > proof-of-concept demo app and just evolved incrementally by necessity. > I'm in favour of any effort to refactor it, or rewrite it completely, > to make it more modular and use best-practice techniques (like > dependency injection, testing etc). > * Once code is already written with dependency injection, I don't see > how Gin adds any value on top. I'm not opposed to it if it does no > harm (download size, latency, debuggability, control and flexibility, > runAsync boundaries, etc). > * The wave panel (Undercurrent), already uses dependency injection, > and each stage has a component provider that does the same thing as a > Guice injector, but is static rather than dynamic so you can see > what's going on, and have complete control over how things get put > together. Those providers are also designed for extensibility, so > other environments can replace individual components with minimal > effort, which I do not believe is possible with Guice/Gin. > * The architecture of Undercurrent is designed for low-latency startup > and to scale well with large numbers of UI components. It is designed > for how browser and JS event handling works. This architecture is > incompatible with how GWT's widget system, which does not scale to > large numbers of UI components. > * Undercurrent had some particular design goals which are impossible > to achieve as a regular GWT component. (0(1) startup overhead, view > state entirely in HTML, convergent client/server rendering, etc). The > main reason, and perhaps the only reason, that Undercurrent uses GWT > is to share rendering and OT code between client and server. i.e., > GWT is used solely as a Java -> JS compiler. It is not a typical GWT > app in that sense,and can never be one. That doesn't mean it can't be > used in other GWT apps, but it won't be as trivial as if it were a > simple GWT component. I'd be hesitant to try and make Undercurrent > look like something that it isn't (and can never be). > * If those design goals are not a priority for the wave panel in WIAB, > and at the current time I'm not sure that they are, then a completely > new wave UI stack could be written with a simpler and more > conventional GWT UI approach, and so would perhaps be easier to add > into other conventional GWT apps with minimal fuss. It could be > Ginned, UiBound, Activitied, and EventBussed, and hooked up with > whatever new gizmos GWT comes up with next. Unfortunately, no such > component exists, so it would have to be written from scratch. > @Vicente: I think most or all of your requirements can be met with > Undercurrent as-is. I'm happy to help out with more information later, > but the general approach would be to look at the DefaultProviders of > StageTwo and StageThree to see how the rendering and editing > components are hooked up. From there, pick a component or a > configuration you want to change. If it is not exposed in a > configurable way, you can refactor the stage to do so. Then, subclass > that DefaultProvider, and replace the component you want with your > version. In your own app, use your own version of Stages that uses > your custom subclass of a stage's provider, rather than the default > one.e.g., to add custom buttons to the toolbar, you could:* In > StageThree.DefaultProvider.createEditActions(), replace > EditToolbar.install() with getEditToolbar().install(), where > getEditToolbar()/createEditToolbar() now exposes the EditToolbar as a > configurable component, so your subclass can override > createEditToolbar() and provide your own one with its own buttons.* > Or, replace EditToolbar.install() with > configureEditToolbar(EditToolbar.create()), moving EditToolbar's > implicit set of buttons out into something configurable, and override > configureEditToolbar() with your own configuration.* Or whatever else > works - it should be just a simple matter of programming. > HTH, > -Dave > On Mon, Nov 21, 2011 at 10:16 AM, Vicente J. Ruiz Jurado > <[email protected]> wrote: >> El 20/11/11 10:22, Thomas Broyer escribió: >>> Vicente has a *need* to improve the web client. He might not have a >>> need of a "standardised client/server protocol". He's willing to help >>> and propose patches for that; but maybe wouldn't commit time for an >>> improved protocol (assuming he doesn't care that much about it). That >>> you don't have the same priorities doesn't mean his patches should be >>> dismissed. >>> >>> My own priorities are much more in line with Vicente's one that with >>> yours, so go ahead Vicente, I'd happily help reviewing those patches. >> >> Great Thomas (I didn't read your answer this morning). >> >> Bests, >> -- >> Vicente J. Ruiz Jurado >> >> http://comunes.org >> http://ourproject.org >> http://homes.ourproject.org/~vjrj/blog (@vjrj) >> >> "Poetry can only be made out of other poems; novels out of other >> novels," [Northrop Frye] >> >> >> >> >> >> >> >
