I already tried to introduce Gin into client side, but gave up cause it requires to replace the hand made injection with Gin based one and this is too much effort over large number of classes. Also, everything related to Undercurrent is super hard to understand - cause there are 4-6 levels of abstraction that heavily use hand made injection. I think it would be easier to create some hand made module for using with translations and pass it everywhere. Still a lot of work. Regarding the server side - in theory it should be easy as GXP supports localization, but there's no documentation at all for this.
On Mon, Nov 21, 2011 at 3:20 PM, Vicente J. Ruiz Jurado <v...@ourproject.org > wrote: > El 21/11/11 01:28, David Hearnden escribió: > > Hmm, Chrome/Gmail formatting fail. Let's try that again. > > > > Sorry to chime in late to this discussion. > > It's not late ... > > > 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). > > Yes, WebClient.java is usually the "Entry Point" (in all the senses) to > WIAB code, and the rest of the WIAB code merits a better entry point for > newcomers that try to use and adapt WIAB. > > > * 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. > > Well Gin comes to my mind because it's something that I use everyday, as > guice. > > For me the decision is between automatic (via annotations, etc) or > manual injection. Personally, in general, I prefer automatic injection > because, well, I don't have the sufficient energy/time to use manual > injection. > > For instance, with WIAB, I find my self maintaining/patching too much > classes (we have a custom StageProvider) for only minimal/superfluous > style modifications here and there (because of static methods, or > similar things). I would prefer to have a custom gin module, with our > custom classes, and let gin (or other similar library) do the job for me > and minimize the differences with the WIAB and the code to maintain to > the minimal. > > > * 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. > > Yes, when I see the "inverted-uibinder stuff", I can imagine that. In > fact, when I wrote "starting" I was thinking only in WebClient.java and > related classes (not in the wave panel, OT code, etc). > > > 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). > > I totally agree. From my experience, it's far for been clear, which > objects there can be reused, redefined or should be singletons, 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 > > Dave I really appreciate you answer. If you have any recommendation > about i18n, also welcome. > > So, related to dep.injection, I propose two initial lines of work > previous to other decisions (gin, etc): > - to start to document how WIAB can be customized/integrated (with info > similar to that one described in your email), so newcomers can arrive > and use the WIAB code with no so much pain. Also this can avoid to > repeat explanations by email. > Maybe a page in: > https://cwiki.apache.org/confluence/display/WAVE/Index > or directly in: > https://svn.apache.org/repos/asf/incubator/wave/site/trunk/ > or even create a public Wave. > - redefine WebClient.java with the same goal and trying to integrate > also the above info with comments. > > I can help in both tasks, but I'm not (obviously) a WIAB expert so your > help (and from others Wave commiters) will be fundamental... > > Also I'll propose little changes in the current client code that will > permit us to a better customization (similar to the server side changes > we did). > > Bests, > > Vicente > > > >
