StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
8326999
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-11-30T13:52:52.563
FavoriteCount
0
LastActivityDate
2011-11-30T13:52:52.563
LastEditDate
LastEditorUserId
0
OwnerUserId
212013
ParentId
8326455
PostTypeId
2
Score
5
ViewCount
0
LastEditorDisplayName
text
Body
You have probably seen this Google I/O presentation: <a href="http://www.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html" rel="noreferrer">Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App</a>. It covers neat techniques to make working with a large GWT projects more managable, like using the Command Pattern for RPC calls, the MVP pattern, Dependency Injection, and decoupling components using the EventBus pattern. Now there are several GWT frameworks that implement these patterns, (gwt-dispatch for Command pattern, gwt-presenter and gwt-platform for MVP, GIN & Guice for DI) but the thing I like about the EventBus concept is that it's part of the core GWT framework (<code>HandlerManager</code>), so I don't have to add extra dependencies to smaller GWT projects. I think the EventBus concept is related to the Observer design pattern in the sense that you are decoupling the View components responsible for getting user input from the Presenter components that need to be notified about those actions. The point is that your ListBox thingy doesn't have to know about all the components that are interested in its state change, it just fires an event to the EventBus, and the interested components will receive that event and act however they want. I don't think you always have to do things through the HandlerManager instance though. Suppose you have a custom <code>DateRangePicker</code> widget, that lets users pick custom date ranges. Whenever a date range is picked, the widget can do something like this in its <code>onSomethingChanged()</code> method : <pre><code>NativeEvent event = Document.get().createChangeEvent(); DomEvent.fireNativeEvent(event, this); </code></pre> Then the components interested in the date range selection change could just register hander callbacks to the DateRangePicker widget instances. <pre><code>dateRangePicker.addDomHandler(new ChangeHandler(){ @Override public void onChange(ChangeEvent event) { refresh(); } }, ChangeEvent.getType()); </code></pre> I think this is a nice loosely coupled design and it doesn't use a <code>HandlerManager</code> instance. A bad design would be to call all the interested component's <code>refresh()</code> methods in the DateRangePicker's onSomethingChange() method instead of firing an event. (Or even worse: calling all the refresh()-es in, the DateRangePicker object's subcomponent's onSomethingChange() methods.)
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POEventBus role in GWT
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USandras
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.