Revision: 9770
Author: [email protected]
Date: Thu Feb 24 14:21:05 2011
Log: Edited wiki page CellBackedWIdgets through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=9770
Modified:
/wiki/CellBackedWIdgets.wiki
=======================================
--- /wiki/CellBackedWIdgets.wiki Thu Feb 24 14:00:08 2011
+++ /wiki/CellBackedWIdgets.wiki Thu Feb 24 14:21:05 2011
@@ -156,6 +156,14 @@
Finally, note that Appearance is an abstract class. This allows us to add
more state logic in the future without breaking existing Appearances. For
example, we could add new methods "setRightFlush()" and "setLeftFlush()"
which would make the right and left edges of the button flat, such that
they could be lined up next to each other. Existing appearances may not
support the new feature, but they would still work.
+== Okay, _Some_ Assumptions ==
+
+In some cases, the implementation of an Appearance will have a significant
effect on the Cell logic. For example, {{{SelectionCell.Appearance}}}
could use the native {{{select}}} element to render a list, or the
Appearance could render a custom list using divs. In the first case, we
can rely on a native change event, but in the latter case, we would need
custom logic to handle selection and keyboard movement. Pushing this logic
down to the Appearance would defeat the purpose of the pattern and wouldn't
make the Cell very reusable.
+
+In these cases, we would provide two Cells, such as SelectionCell and
ListBoxCell. SelectionCell would require that the Appearance contain a
native select element and would respond to native change events.
ListBoxCell would respond provide logic for keyboard and mouse events,
which can be mapped into the Appearance (glossy I know. More details when
we actually implement it).
+
+This edge case appears to be limited to elements that can change state
natively (things that fire onchange events), such as {{{select}}} elements
and checkboxes. For checkboxes, we would want to support using images
instead of a native input element.
+
= Cell Backed Widgets =
@@ -195,6 +203,16 @@
+== Packages and Naming Conventions ==
+
+Cells will continue to go in the {{{com.google.gwt.cell}}} package. In
fact, existing Cells do not expose any ClientBundles or styles, so we can
retrofit them using the Appearance pattern.
+
+The new widget library will be a fairly significant departure from the old
library, and so it probably deserves a new package to separate it. I
suggest {{{com.google.gwt.user.widget.client}}}.
+
+Since we now provide both Cell and Widget versions, I suggest that new
widgets use the postfix "Widget", such as "ButtonWidget". That
compliments "ButtonCell" nicely. It also avoids naming conflicts with
existing widgets, such as "Button".
+
+
+
= Conclusion =
The new pattern described above will allow us to update widgets by
providing new Appearances to replace old Appearances. We will start with
the basic form widgets (buttons, text boxes, etc.) and move on to more
complex widgets over time.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
