We can certainly create a really sophisticated bead system and ensure the
topology of every component is consistent, but I think that will defeat
the goal of having really small and fast components. IMO, it is more
important that the resulting apps are small and fast than sophisticated,
generalized, and consistent.
Consider that we want to make it easy to swap in different default values
for beads. Right now, requiring that every component has a single
IBeadModel makes it easy to find and replace in CSS, and allows us to put
that code into the lifecycle in the base classes. A more flexible thing
is probably going to not be as small, fast and simple, and I don't think
the vast majority of components need it. PAYG is usually an opponent of
generalization.
IIRC, we already have places where there are two models. DataGrid has a
selection model and a presentation model. The DataGridView and other
DataGrid beads just know to expect the presentation model.
A top-level component is bound to its model because its job is to
propagate the model to the component's API surface. Again, going back to
look at "exploded" components, a Button is fundamentally:
<UIBase>
<beads>
<ButtonModel />
<ButtonView />
<ButtonMouseController />
<beads>
</UIBase>
And a TextButton is:
<UIBase>
<beads>
<TextButtonModel />
<TextButtonView />
<ButtonMouseController />
<beads>
</UIBase>
Without a top-level TextButton component, the user would have to set the
label as follows:
<UIBase>
<beads>
<TextButtonModel label="myLabel" />
<TextButtonView />
<ButtonMouseController />
<beads>
</UIBase>
A TextButton could choose not to propagate model properties to the API
surface and just represent the composition of the default beads, but then
the user would still have to write:
<TextButton>
<beads>
<TextButtonModel label="myLabel" />
<beads>
</TextButton>
We assume that is too painful too, so that's why we add label to the
TextButton and have it pass it back and forth from the model. Then the
user can just do:
<TextButton label="myLabel" />
I claim that will be smaller and faster than having both a ButtonModel and
a TextModel on the strand and having the TextButtonView find both models.
So lots of the places where we aren't consistent, especially on the JS
side, is to optimize a bit. IMO, ImageButton is an optimization. If all
you want is a clickable <img> tag in your HTML, I'm not clear it is worth
it to create the 3 MVC beads to do it.
But yeah, that means ImageButton isn't extendable into being a
ToggleImageButton. IMO, that's ok. If ToggleImageButton needs to specify
more images, great, create a SelectedStateImageButtonModel with two images
for selected and not selected, and add more models with more states if you
need to support rollover, down, already-seen-in-history, etc. IOW,
ToggleImageButton requires enough flexibility that its JS implementation
should be MVC.
So, IMO, create ToggleImageButton the MVC way and leave ImageButton as is.
My 2 cents,
-Alex
On 12/7/17, 7:21 AM, "Harbs" <[email protected]> wrote:
>I generated patch files for all the commits and ran a find/replace on the
>patches. After I did that, the patches applied pretty much as-is. Pretty
>amazing…
>
>I just pushed a new branch with these changes. I’ll see if I can finish
>this up and see if I can get to the second phase of what I want to do
>with strands and beads…
>
>> On Dec 7, 2017, at 4:32 PM, Harbs <[email protected]> wrote:
>>
>> I might pick up where I left off on that, although it’s going to be
>>difficult to pull my changes after the Great Rename… ;-)
>
