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