On 11/24/17, 1:54 AM, "Olaf Krueger" <m...@olafkrueger.net> wrote:
>
>> A DataGrid, IMO, is not a Table.
>
>I agree, but for simple things, I think a table is good enough.
Yes, a Table is good enough, but a Royale version of a Table optimized for
columnar display of data should always be more efficient. If you know your
columns are "name, address, phone", it should be less typing and less
error prone to do:
<js:NoSelectionDataGrid columns="['name', 'address', 'phone']"
Than:
<Table>
<th>
<td>name</td>
<td>address</td>
<td>phone</td>
<th>
There is less markup to mistype. Royale framework developers are looking
for these unnecessary replications of work like having to type "<td></td>"
and packaging that up into a component to save you from having to do that
and fix typos doing that.
And then, when you later decide to add selection, you can add it by
replacing the tag name with:
<js:DataGrid columns="['name', 'address', 'phone']"
Instead of throwing out your Table and starting over.
>
>>In the future, if we add more metadata, we might even be
>>able to tell you if a bead is compatible or not.
>
>This would be a huge help!
>BTW: I have no idea how to detect if a bead is compatible or not by
>exploring the source code.
>How can I detect if a bead is compatible with a component (or vice versa)
>or
>other beads by exploring the source code?
In the general case, you can't know for sure. For example, the
TextPromptBead can be plugged into many components that let you type into
it like TextInput and ComboBox, but if you make an extension of TextInput
and bake a custom TextPromptBead into it, I don't think we can tell from
the source code that you did that.
But we can tell in some cases. If a bead implements an interface, you can
look for components and views that fetch those interfaces. That should
give you a list of selection models and data provider implementations for
Lists, for example.
I don't know what the right approach is for sure, but my first guess is to
have beads have some metadata about "Known Strands". The developer of the
bead has to manually list which components the bead is known to work with.
I don't think we want to keep patching components with beads that have
been tested with those components. I think that could result in tons of
patches to components. But then the tooling needs to backwards-compute
the list of beads for a component. IMO, we need similar logic in the
tooling for implementing "Known Subclasses" for the ASDoc.
My 2 cents,
-Alex
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-development.20373.n8.nabble.com%2F&data=02%7C01%7C%7C543920ad4cfb42543
>b1c08d533216374%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364711408594
>45839&sdata=uMLqn99Pb6oK9Jc1p%2ByHL7%2Bv%2FROIIbyQBDtWw7t2Sfo%3D&reserved=
>0
