IMO, there is too much redundancy in specifying tab tags when an array of tab
names is good enough. Yes, there is probably some super-fancy TabBar where you
should be allowed to specify each Tab's visuals individually, but I don't see
that as the common case, and adding a simple CSS className property to the data
model should let folks specify lots of different visuals in CSS.
You don't have to call the property "dataProvider". You can call it
"listOfTabNames" if you think that's better.
Compare:
<foo:TabBar>
<foo:Tab text=“Tab 1”/>
<foo:Tab text=“Tab 2”/>
<foo:Tab text=“Tab 3”/>
<foo:Tab text=“Tab 4”/>
</foo:TabBar>
vs.
<foo:TabBar tabNames="['Tab 1', 'Tab 2', 'Tab 3', 'Tab 4']" />
My 2 cent,s
-Alex
On 1/22/19, 1:26 PM, "Harbs" <[email protected]> wrote:
The design was supposed to be one or the other:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fspectrum-css%2Fpull%2F59%23issuecomment-455590132&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=YnWRyxf0sAbC0F8uORyjMakXGCa2zHVLI0PLMaq8gTo%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fspectrum-css%2Fpull%2F59%23issuecomment-455590132&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=YnWRyxf0sAbC0F8uORyjMakXGCa2zHVLI0PLMaq8gTo%3D&reserved=0>
I was thinking of doing it as a List and using a dataProvider, but I liked
the structure of the tab children better.
Tabs don’t feel to me like a list and the dropdown feels more like a
special case.
I think this is a case which could really go either way.
> On Jan 22, 2019, at 10:59 PM, Alex Harui <[email protected]> wrote:
>
> I'm not sure I understood what we were supposed to get from these links,
but to me, the links took me to web pages that would inspire me to write a
component that leverage the Royale/Flex item renderer approach. The component
would take a dataProvider of tab names and an optional renderer, and decide how
many tabs to display and put the rest in a dropdown.
>
> My 2 cents,
> -Alex
>
> On 1/22/19, 11:06 AM, "Harbs" <[email protected]> wrote:
>
> I’m implementing this:
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopensource.adobe.com%2Fspectrum-css%2F2.7.2%2Fdocs%2F%23tabs---too-many&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=EnWSQB82TNKepPS9GvlabxpfGuZTw2bif%2FfWK2ojgQs%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopensource.adobe.com%2Fspectrum-css%2F2.7.2%2Fdocs%2F%23tabs---too-many&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=EnWSQB82TNKepPS9GvlabxpfGuZTw2bif%2FfWK2ojgQs%3D&reserved=0>
>
> The current display is not the latest. In the current implementation,
the dropdown is structured like this:
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fspectrum-css%2Fblob%2Fmaster%2Fdocs%2Ftabs%2Ftabs-toomany.yml&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=5TOIgAM%2Bp8dQ2Jb1hLbUeawnrDAbn%2Fswi4BZh2paYgw%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fspectrum-css%2Fblob%2Fmaster%2Fdocs%2Ftabs%2Ftabs-toomany.yml&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=5TOIgAM%2Bp8dQ2Jb1hLbUeawnrDAbn%2Fswi4BZh2paYgw%3D&reserved=0>
>
> While the normal structure is like this:
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fspectrum-css%2Fblob%2Fmaster%2Fdocs%2Ftabs%2Ftabs.yml&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=%2FEGTuHaNPMSLLScWhS9%2F1u%2B9JleLkQBT4Zo9uF0YYtU%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fspectrum-css%2Fblob%2Fmaster%2Fdocs%2Ftabs%2Ftabs.yml&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=%2FEGTuHaNPMSLLScWhS9%2F1u%2B9JleLkQBT4Zo9uF0YYtU%3D&reserved=0>
>
> The spectrum css requires a specific structure, so I can’t use media
queries.
>
> FWIW, [DefaultProperty] does what we want.
>
> Thanks Alex,
> Harbs
>
>> On Jan 22, 2019, at 8:51 PM, Carlos Rovira <[email protected]>
wrote:
>>
>> Hi,
>>
>> So if I understand right: You want a tabbar navigation that when the user
>> goes to mobile or shrinks the browser changes the visual to a dropdown
>> right?
>>
>> For me the change should not happen at the level you are proposing. The
>> component declaration in MXML is the same for both views (the data and
>> structure), you only want to change representation.
>> And for me that's in the realm of CSS with responsiveness. So doing a
media
>> query in CSS to arrange things in a way or another depending on the width
>> of the browser window.
>>
>> That's the same we do in Jewel for Drawer, NumericStepper, ComboBox, and
>> more...
>>
>> HTH
>>
>> Carlos
>>
>>
>>
>> El mar., 22 ene. 2019 a las 17:43, Alex Harui
(<[email protected]>)
>> escribió:
>>
>>> The compiler supports a special property called mxmlContent that defers
>>> the creation of the MXML tags assigned to that property until a bit
later
>>> in the lifecycle in order to try to make sure other properties are set
up
>>> before the children in the mxmlContent are. All other mxml tags are
>>> created at constructor time. mxmlContent is the [DefaultProperty] of
>>> Royale containers so instead having everyone type "mxmlContent" tags
over
>>> and over again, you just skip having to type "mxmlContent".
>>>
>>> So, one option is to define other properties to hold other sets of
>>> children. They will be instantiated at constructor time, but you can
store
>>> them anywhere. IMO, it is bad practice to store UI widgets in the
model,
>>> but some components have both a data model and a presentation model that
>>> holds things that are about the view (DataGrid rowHeight for example)
and
>>> not about the data itself.
>>>
>>> Another option is to think of this component like a Navigator like
>>> ViewStack. Then you'd have two containers in the mxmlContent, one that
>>> holds the tabs or the tabbar itself and another that holds the "complex
one
>>> with a dropdown".
>>>
>>> Yet another option is to think of it sort of like Panel. Panel has
both a
>>> TitleBar and mxmlContent. You can specify a completely different
TitleBar
>>> for a Panel.
>>>
>>> HTH,
>>> -Alex
>>>
>>> On 1/22/19, 1:12 AM, "Harbs" <[email protected]> wrote:
>>>
>>> We are working on a component which has two (very different) views
>>> depending on available space.
>>>
>>> I’d like to have some markup which would look like this:
>>> <foo:TabBar>
>>> <foo:Tab text=“Tab 1”/>
>>> <foo:Tab text=“Tab 2”/>
>>> <foo:Tab text=“Tab 3”/>
>>> <foo:Tab text=“Tab 4”/>
>>> </foo:TabBar>
>>>
>>> The internal structure would change from a relatively simple one to a
>>> complex one with a dropdown when there’s little space.
>>>
>>> I’d like to have a TabModel which would have an array of the tabs
>>> specified. I’d have a separate view which is responsible for actually
>>> adding the elements. My question is how to have the MXML children added
to
>>> the model instead of the default behavior where they are added as
elements.
>>>
>>> Thanks,
>>> Harbs
>>>
>>>
>>
>> --
>> Carlos Rovira
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caaad20c2cb774ba83b7308d680b04982%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636837892000190201&sdata=P5vEcEXjcWFxYWF%2BLYDLDvdXPQeVhDFqaZRJaOSlcco%3D&reserved=0
>
>
>
