Goktug Gokdogan has posted comments on this change.
Change subject: Introduces generic Composite widgets.
......................................................................
Patch Set 4:
In the end, I tend to think that composites shouldn't expose low-level
events from their wrapped widgets, and shouldn't be containers.
For events, either you only use high-level events such as SelectionEvent
for SuggestBox, ValueChangeEvent for ValueListBox or ValuePicker, or
OpenEvent and CloseEvent for DisclosurePanel.
This is mostly true, composite will usually only need to expose logical
events but I don't think it is always practical. Why an interface /
functionality for ValueListBox should be any different than ListBox? If
somebody needs focus events for ListBox and then it means they also need it
for ValueListBox, this is true for any composite that does single
encapsulation.
For panels, you'd rather extend Panel, or not make a Composite and
instead simply implement IsWidget and HasWidgets.ForIsWidget.
Note that we have precedents of composites that are panel and violate the
principle of least surprise for getParent(): DisclosurePanel, TabBar and
TabPanel are such widgets. Our existing widgets that delegate events
however are either broken or have deprecated/removed the delegation.
Yes exactly. We are already broken in many places and there is a huge mess.
As our own code is broken that means everybody else's code is also broken.
We cannot get rid of the mass by ignoring it - and not taking an action is
exactly that.
There are parts that are fixable (event source) and also there are other
parts that is not much practical to fix with current design (getParent
symmetry). Parent symmetry also probably broken for any other widget system
that uses composition for reuse. But use case is unavoidable as can be seen
from our very own SDK (and based on my previos experience with Swing). If
we don't provide the right tools then people are causing even more mess
like extending a panel instead of composite and only forward one or two
methods and missing the rest (like removals or other 'add' methods).
What I'm trying to do here is to provide a way for both our own code and
user code to do this in less messy way and I think even in it current state
it is already an improvement.
--
To view, visit https://gwt-review.googlesource.com/2582
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I41e5c07e978d442db7d8402c57605cec1b3ea09e
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Goktug Gokdogan <gok...@google.com>
Gerrit-Reviewer: Brian Slesinsky <skybr...@google.com>
Gerrit-Reviewer: Goktug Gokdogan <gok...@google.com>
Gerrit-Reviewer: Jens Nehlmeier <jens.nehlme...@gmail.com>
Gerrit-Reviewer: Leeroy Jenkins <jenk...@gwtproject.org>
Gerrit-Reviewer: Matthew Dempsky <mdemp...@gwtproject.org>
Gerrit-Reviewer: Thomas Broyer <t.bro...@gmail.com>
Gerrit-HasComments: No
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
