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
<v...@ourproject.org> 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]
>
>
>
>
>
>
>
