Now that Emily has cut the legs out from under my main (contrived) argument, let me indulge my true nature. I think defensive api design is a lot more valuable in systems programming than in UI programming. The more we baby-proof our widgets, the more we frustrate people who want to work around whatever short comings we've inadvertently left in place. I think this is why Java has its reputation for leading to crappy UI. More popular UI kits are in languages that simply cannot be this locked down--let's learn from that.
I have no problem with providing protected accessors to the sub-widgets of the composites in question. We know that hyper-lockdown on this stuff frustrates people. Let's see what happens if we loosen things up. rjrjr On Mon, Nov 3, 2008 at 11:22 AM, Isaac Truett <[EMAIL PROTECTED]> wrote: > > For a little context, here's where this started: > > http://code.google.com/p/google-web-toolkit-incubator/issues/detail?id=174 > > And the sister thread that Daniel opened: > > > http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/7c568f6c57ab8d73 > > > > On Mon, Nov 3, 2008 at 2:08 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, Nov 3, 2008 at 10:52 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > >> > >> Thought this conversation should be made public... > >> > >> Emily mentioned in her review comment for r1180 that the > >> DateBox.getTextBox() JavaDoc > >> needs a warning about calling setText() directly on the TextBox. Aren't > >> there going > >> to be many other potentially dangerous things one could do with that > >> TextBox > >> reference? Adding to another container or calling removeFromParent() > seem > >> ripe for > >> abuse. Also, getTextBox().getParent() effectively exposes the entire DOM > >> innards of > >> the Composite, doesn't it? Composite.getWidget() is protected for a > >> reason, I would > >> think. > >> > >> > >> I think the getTextBox() change was buried in an event-based thread. > The > >> question was to add methods like > >> addTextBoxClickHandler/addTextBoxChangeHandler/addTextBoxFocusHandler > or > >> to have a public getTextBox() method that the user could then add > handlers > >> to. > >> > >> The current decision was that since a user could already pass a text box > >> into a suggest box, there were enough benefits to using the simpler > coding > >> model. However, it is inherently less safe as it allows users to do > stupid > >> things. It also, as we see here, establishes a precedent that may or may > not > >> be the one we want to establish. > >> > >> > >> So, for SuggestBox, and, by implication, DateBox and any other *Box > >> widget we create, do we want to delegate to all the text box methods we > >> support or do we want a getTextBox method? > > > > Adding getTextBox() only changes things by giving them access to the one > > that we create if they don't provide their own, right? And it means that > we > > have no option to change the implementation in to one that doesn't use a > > text box--right now we're "allowed to" if they use the default > constructor. > > > > I suppose I just said that I vote against the accessor. What problem is > > being solved by adding it? > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> "There are only 10 types of people in the world: Those who understand > >> binary, and those who don't" > >> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
