Closed GoogleCodeExporter closed 9 years ago
I am currently investigating how to implement this.
Original comment by vega113
on 25 Dec 2010 at 6:32
I see the following approaches to implement this:
1) By re-using and adapting the undercurrent architecture/logic for the Wave
panel and Toolbar
advantages:
-some reuse of existing code for rendering elements
-very flexible and efficient rendering and event capturing
-pluggable toolbar
-may support styling (i.e. annotations also for the waves feed (list)
disadvantages:
-it may be overkill, i.e. to much for simple goal of rendering mostly static or text content.
-requires much effort
2)Implementing using GWT widgets
advantages:
-simple to implement and understand
disadvantages:
-rendering need to be implemented from scratch
-much simpler support for pluggable controls on the toolbar
-simple text waves feed
3)Some kind of hybrid, where some rendering done by adapting and reusing
undercurrent UiBuilders for the frame and EditorToolbar, but say events are
handled in more simple way, and the waves feed is not changed - i.e. just text
snippets as it is now.
I would like to get any input/ideas on the issue, especially taking in account
that my knowledge/understanding of the Undercurrent architecture is very
limited.
Original comment by vega113
on 27 Dec 2010 at 6:35
I believe re-using the "doodad" registration and event mechanism has been the
winning suggestion when I've discussed this with people experienced in the
client, so mostly your option 1).
Note that search results will likely have some liveness. For example, when
someone is typing in a wave the digest should update to reflect their
additions. When viewing or editing a wave the message and unread counts should
change to reflect that. It's not super-complex, agreed, but it's not all
static. Also there's lots of room to make the entries better looking than the
plain text they are currently.
Original comment by ano...@google.com
on 29 Dec 2010 at 2:40
After trying both ways I am leaning toward pure widget approach. The "doodad"
approach is unnecessary complex to implement and maintain. It also requires
complex event handling mechanism which imho is unjustified for the left panel
where basically there are only 3 types of events - search query request, click
on toolbar and wave selection. And since there will be no stages mechanism the
complexity of doodads use here is not justified by performance improvement.
Original comment by vega113
on 30 Dec 2010 at 7:26
I also planning to replace the Waves snippet list with CellList widget. It has
built in support for paging and works nicely with huge lists.
Original comment by vega113
on 30 Dec 2010 at 10:33
If you're willing to implement it then that sounds good to me. Other client
developers may weigh in too.
Do attempt to send us incremental changes for review so we get an early
opportunity for feedback.
Original comment by ano...@google.com
on 4 Jan 2011 at 12:18
First patch version is available at:
http://codereview.waveprotocol.org/490001
It includes:
1) Addition of bread crumb, panel and toolbar to the wave list panel (so it
looks similar to the wave panel)
2) Waves snippet list is implemented as Cell list - that enables paging support.
3) Added range label - to display the current range and current wave list size.
Original comment by vega113
on 11 Jan 2011 at 10:36
Original comment by vega113
on 12 Jan 2011 at 11:08
fixed by rev 17eb65ad40
Original comment by vega113
on 21 Jan 2011 at 7:28
Original issue reported on code.google.com by
vega113
on 25 Dec 2010 at 6:30