Widgets Represent Relationships In The Model
Widgets Represent Relationships In The ModelWhen I started working in WebObjects thanks to its clean ModelViewController architecture I realized that WidgetsRepresentRelationshipsInTheModel:
I believe that it is precisely because frameworks don't help the developer realize that WidgetsRepresentRelationshipsInTheModel that we end up with frameworks like WindowsForm? (or Swing) that make it hard (you don't get any help from the IDE) to do ControllerUnitTesting? and to reuse control logic with different presentation technologies.
Widgets are UserInterface and are neither data nor process. They represent options - things that can be controlled by an operator, and may also represent some data about current selection (acting as gauges, e.g. if the widget-state automatically is updated to reflect the current model-state), but they sure as heck aren't representing relationships in the model, at least not in the generic sense. It'd be silly to represent with a widget data or relationships that cannot be controlled by an operator.
Well, then WidgetsRepresentRelationshipsInTheModel that can (only?) be controlled by an operator. But they still represent relationships... just only those relationships that should be interactively manipulated by operators (users), but if you don't have those relationships in your DomainModel... then there is no justification to have a widget that represents it for the user (and allows the user for manipulate it)...
In other words: Every widget in an applications represents a relationship in the DomainModel that can be manipulated interactively (or just viewed) by an operator (the user). Can you find an specific example against this? (All the systems I have built or heard of follow that rule)
Fundamentally, tweaking a widget can only ever send a signal to affect process or state. Signals are not relationships, but they may affect relationships. Whether you choose to represent with widgets those signals that will be processed as commands to manipulate singular relationships within the data or process models is a design decision. It might be a good design decision, but it certainly isn't something fundamental. For any domain model, there exist an infinite number of UI designs or widget-sets that would completely violate the principle you suggest, and if you think about it for a moment I'm sure you can find a few - as a casual example, consider those video-game puzzles where pulling a lever will raise or lower three different gates; the levers are certainly widgets, and they're affecting the model, but the levers certainly aren't representing relationships in the model (because neither the existing state of pulled/pushed nor the effect of raising/lowering certain gates if they aren't already raised/lowered can be tied to any particular model state or relationship).
Are you sure that neither the existing state of pulled/pushed nor the effect of raising/lowering certain gates if they aren't already raised/lowered can be tied to any particular model state or relationship? Let's see... a Lever can be Up or Down... but can not be both Up and Down... that means there is a ToOneRelationship? between Lever and LeverState?{Up,Down}... (Ah! So you found a relationship between the widget and the widget. Wonderful. Unfortunately, knowing whether the lever is up or down does NOT tell you about the DomainModel - the state of the gates. The initial state of the gates and the order in which the levers are moved is what determines the final state of the gates.) Since the number of possible items to select is small, a "Lever Widget" is not a BadIdea, a RadioButtonGroup? or a Single Check Box would also work fine... a ComboBox might be a little too much, but it doesn't go against the multiplicity... and a GridView (in single select mode) would certainly be overkill... but a Lever would be really really uncomfortable to use if instad of 2 states we had 1000 options to choose from... and a CheckBox Group certainly would be a bad idea since a lever can not be in 2 states at the same time (it is not a ToManyRelationship?)... Mmmm, all this seems pretty generic to me...
And the fact a moving the lever might also open or close any number of Gates has nothing to do with the fact that the Lever is representing a ToOneRelationship? between Lever and LeverState?, in other words, an event connected to the change in the relationship between the Lever & the LeverState? is also affecting the Gates, but only indirectly, the Lever is not directly representing the relationship between the Lever & the Gates, it is representing the relationship between the Lever & the LeverState?. (The lever carries its own state, I agree. But widgets are not, themselves, the domain model. Is it your intent to communicate that WidgetsRepresentRelationshipsWithTheirOwnState?)
Because the effect on relationships isn't something fundamental, the most you can reasonably argue is that Widgets Ought to Represent Relationships In The Model. And you ought to provide reasoning for your stance rather than just examples of potential relationships, certainly before going around to a half-dozen other pages to inject your views as though they are accepted fact. In particular, you have yet to provide reasoning for such widgets as slider-bars, yes/no dialogs, submit buttons, and all the various widgets that are difficult to stick into this little worldview of yours.
Well, certainly going around to a half-dozen other pages and injecting my views as if they are accepted fact has started this very interesting discussion, so I think it was a GoodIdea (how can I find out if an idea I have is a good candidate to become an accepted fact without provoking others to challenge it?). (Ah? Well... I can't argue with that. I used to troll Linux forums because it was the best means of getting help. "Windows ME is better than Linux because I can't do XYZ in Linux"... heh.) Certainly keeping the idea for myself is not a good idea to test if others think like me... So, when I find a page that I think is related to one of my ideas, I add a link and wait to see what happens... some times people think my idea is "an accepted fact" and write to agree with me... other times they disagree, and write to explain why... everybody wins in both cases because everybody can read an learn what other people think are "accepted facts"...
I model widgets as a vector and implicit language with which the operator-agent speaks to the process-agent. A check-box represents a set of possible yes/no options for a signal, while a radio-button represents a choice of possible signals. Views aren't true widgets (at least by the origin of the term - nameless knobs and switches, etc.) but they do operate as a vector by which a process-agent can feed information back to the operator... which is, again, signal-based. In distributed systems, process-agents represent nodes in the domain-model and the options you can tweak on them can at most affect their communications with other immediate agents (including the operator). As such, I'm quite disinclined to believe that widgets represent meaningful relationships in the model or that they ought to. Can you show I'm wrong?
So... you see no relationship between the signals you send and the undelying DomainModel? (There is no fundamental relationship between signals and the model. You could easily have a widget that does nothing at all, or that simply crashes your system. A good UI might send only signals that are meaningful to the model, but UIs are not necessarily good. There is also no requirement that signals meaningful to the model are in any manner representative of relationships -within- the model, which is what the title implies.) You don't think about multiplicity when you think about which widget would be a good candidate when designing your user interfaces? Mmmm... maybe I am not stating my idea properly.. I don't mean to say that "all" relationships in the domain model have to be represented as a widget, but the other way around... that "If you are using a widget in you UI, that widget is representing a relationship in you model"... maybe I should change the name of this page to: AWidgetMustHaveAFoundationInARelationshipInTheModel ? would that be more a more accurate sentence in your world view? Now.. if AWidgetMustHaveAFoundationInARelationshipInTheModel then it follows that AWidgetRepresentsARelationshipInTheModel... and therefore WidgetsRepresentRelationshipsInTheModel... can you show what is wrong with my reasoning? (Your wording fails to distinguish true necessity from good practice. As far as your reasoning: it's difficult to tell - you have yet to actually present a case that widgets even -ought- to represent relationships in the model. As indicated above, with widgets being vectors for operator signals, there certainly are other things widgets can represent.)
Widgets are also about the user of them, and represent choices to make, and the user's expectations of actions performed or states changed when choices or selections are made. -- DonaldNoyes
See also TheRadBottleneck
EditText of this page
(last edited December 14, 2014)
or FindPage with title or text search