You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2020/09/12 10:52:24 UTC
Jewel Presentation Model properties proxied in TLC classes
Hi,
While working on a fix for Presentation Models in Jewel I noticed that we
have many PM variables that are not used most of the time in component's
TLC. This happens in List, DataGrid, DataGridColumnList and TabBar
For example, we should do:
<j:TabBar>
<j:beads>
<j:TabBarPresentationModel rowHeight="60"/>
</j:beads>
</j:TabBar>
instead of
<j:TabBar rowHeight="60">
to keep with PAYG.
Also we have just some variables, but not all exposed
variables exposed in TLCs are:
- rowHeight
- variableRowHeight
This even makes it inconsistent since we probably want to add more PM
particularities in the future, and doesn't have sense to me to have just
some in TLC.
If there's no opposition I'll be removing those jewel vars in the next days.
Thanks
--
Carlos Rovira
http://about.me/carlosrovira
Re: Jewel Presentation Model properties proxied in TLC classes
Posted by Carlos Rovira <ca...@apache.org>.
Hi
just let you know that I removed from TLCs some methods that are really
APIs from the corresponding Prensentation Models.
Does not have sense to have those exposed in the main component API.
Components affected (most of the time due to inheritance:
- DataContainer
- List
- ButtonBar
- Navigator
- TabBar
- VirtualList
- DataGridColumnList (in DataGrid)
Then
- DataGrid
And
- ComboBox
- VirtualComboBox
PresentationModels are:
- ListPresentationModel
- DataGridColumnListPresentationModel
- DataGridPresentationModel
- ComboBoxPresentationModel
- TabBarPresentationModel
properties
- rowHeight
- variableRowHeight
- align
- rowCount
So now instead of :
<j:List rowHeight="60"/>
you should do:
<j:List>
<j:beads>
<j:ListPresentationModel rowHeight="60"/>
</j:beads>
</j:List>
Thanks
Carlos
El mar., 22 sept. 2020 a las 10:45, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi,
>
> since I think we're all in the same page I'll be removing this TLC methods
> today
> thanks
>
> El lun., 14 sept. 2020 a las 10:37, Carlos Rovira (<
> carlosrovira@apache.org>) escribió:
>
>> Hi Piotr,
>>
>> each property is in its Presentation Model, we are just duplicating a few
>> in TLC exposing as TLC's official API.
>>
>> About PMs: Right now each component used to have its own definition of PM
>> with some particularity, if not due to some new property, maybe about
>> initialization or default values.
>>
>> So the plan is just to remove the duplicated APIs from the TLC. That's
>> mostly "rowHeight" and "variableRowHeight" from List and DataGrid (maybe
>> could be something more since I'm talking from memory).
>>
>> You always can continue using them in a new instance of the bead like I
>> posted in the initial email of the thread, since PMs are working fine now.
>>
>>
>> El lun., 14 sept. 2020 a las 9:33, Piotr Zarzycki (<
>> piotrzarzycki21@gmail.com>) escribió:
>>
>>> Hi Carlos,
>>>
>>> Where would you move them ? I mean those properties would be in specific
>>> to
>>> the component presentation models ?
>>>
>>> sob., 12 wrz 2020 o 16:06 Hugo Ferreira <hf...@gmail.com>
>>> napisał(a):
>>>
>>> > Hi,
>>> >
>>> > I use row Height and yes, it's very strange not to be a bead.
>>> > For me go ahead. I will ajuste the code on my side after upgrade with
>>> the
>>> > new change.
>>> >
>>> > Carlos Rovira <ca...@apache.org> escreveu no dia sábado,
>>> 12/09/2020
>>> > à(s) 11:52:
>>> >
>>> > > Hi,
>>> > >
>>> > > While working on a fix for Presentation Models in Jewel I noticed
>>> that we
>>> > > have many PM variables that are not used most of the time in
>>> component's
>>> > > TLC. This happens in List, DataGrid, DataGridColumnList and TabBar
>>> > >
>>> > > For example, we should do:
>>> > >
>>> > > <j:TabBar>
>>> > > <j:beads>
>>> > > <j:TabBarPresentationModel rowHeight="60"/>
>>> > > </j:beads>
>>> > > </j:TabBar>
>>> > >
>>> > > instead of
>>> > >
>>> > > <j:TabBar rowHeight="60">
>>> > >
>>> > > to keep with PAYG.
>>> > >
>>> > > Also we have just some variables, but not all exposed
>>> > >
>>> > > variables exposed in TLCs are:
>>> > >
>>> > > - rowHeight
>>> > > - variableRowHeight
>>> > >
>>> > > This even makes it inconsistent since we probably want to add more PM
>>> > > particularities in the future, and doesn't have sense to me to have
>>> just
>>> > > some in TLC.
>>> > >
>>> > > If there's no opposition I'll be removing those jewel vars in the
>>> next
>>> > > days.
>>> > >
>>> > > Thanks
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Carlos Rovira
>>> > > http://about.me/carlosrovira
>>> > >
>>> >
>>>
>>>
>>> --
>>>
>>> Piotr Zarzycki
>>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Jewel Presentation Model properties proxied in TLC classes
Posted by Carlos Rovira <ca...@apache.org>.
Hi
just let you know that I removed from TLCs some methods that are really
APIs from the corresponding Prensentation Models.
Does not have sense to have those exposed in the main component API.
Components affected (most of the time due to inheritance:
- DataContainer
- List
- ButtonBar
- Navigator
- TabBar
- VirtualList
- DataGridColumnList (in DataGrid)
Then
- DataGrid
And
- ComboBox
- VirtualComboBox
PresentationModels are:
- ListPresentationModel
- DataGridColumnListPresentationModel
- DataGridPresentationModel
- ComboBoxPresentationModel
- TabBarPresentationModel
properties
- rowHeight
- variableRowHeight
- align
- rowCount
So now instead of :
<j:List rowHeight="60"/>
you should do:
<j:List>
<j:beads>
<j:ListPresentationModel rowHeight="60"/>
</j:beads>
</j:List>
Thanks
Carlos
El mar., 22 sept. 2020 a las 10:45, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi,
>
> since I think we're all in the same page I'll be removing this TLC methods
> today
> thanks
>
> El lun., 14 sept. 2020 a las 10:37, Carlos Rovira (<
> carlosrovira@apache.org>) escribió:
>
>> Hi Piotr,
>>
>> each property is in its Presentation Model, we are just duplicating a few
>> in TLC exposing as TLC's official API.
>>
>> About PMs: Right now each component used to have its own definition of PM
>> with some particularity, if not due to some new property, maybe about
>> initialization or default values.
>>
>> So the plan is just to remove the duplicated APIs from the TLC. That's
>> mostly "rowHeight" and "variableRowHeight" from List and DataGrid (maybe
>> could be something more since I'm talking from memory).
>>
>> You always can continue using them in a new instance of the bead like I
>> posted in the initial email of the thread, since PMs are working fine now.
>>
>>
>> El lun., 14 sept. 2020 a las 9:33, Piotr Zarzycki (<
>> piotrzarzycki21@gmail.com>) escribió:
>>
>>> Hi Carlos,
>>>
>>> Where would you move them ? I mean those properties would be in specific
>>> to
>>> the component presentation models ?
>>>
>>> sob., 12 wrz 2020 o 16:06 Hugo Ferreira <hf...@gmail.com>
>>> napisał(a):
>>>
>>> > Hi,
>>> >
>>> > I use row Height and yes, it's very strange not to be a bead.
>>> > For me go ahead. I will ajuste the code on my side after upgrade with
>>> the
>>> > new change.
>>> >
>>> > Carlos Rovira <ca...@apache.org> escreveu no dia sábado,
>>> 12/09/2020
>>> > à(s) 11:52:
>>> >
>>> > > Hi,
>>> > >
>>> > > While working on a fix for Presentation Models in Jewel I noticed
>>> that we
>>> > > have many PM variables that are not used most of the time in
>>> component's
>>> > > TLC. This happens in List, DataGrid, DataGridColumnList and TabBar
>>> > >
>>> > > For example, we should do:
>>> > >
>>> > > <j:TabBar>
>>> > > <j:beads>
>>> > > <j:TabBarPresentationModel rowHeight="60"/>
>>> > > </j:beads>
>>> > > </j:TabBar>
>>> > >
>>> > > instead of
>>> > >
>>> > > <j:TabBar rowHeight="60">
>>> > >
>>> > > to keep with PAYG.
>>> > >
>>> > > Also we have just some variables, but not all exposed
>>> > >
>>> > > variables exposed in TLCs are:
>>> > >
>>> > > - rowHeight
>>> > > - variableRowHeight
>>> > >
>>> > > This even makes it inconsistent since we probably want to add more PM
>>> > > particularities in the future, and doesn't have sense to me to have
>>> just
>>> > > some in TLC.
>>> > >
>>> > > If there's no opposition I'll be removing those jewel vars in the
>>> next
>>> > > days.
>>> > >
>>> > > Thanks
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Carlos Rovira
>>> > > http://about.me/carlosrovira
>>> > >
>>> >
>>>
>>>
>>> --
>>>
>>> Piotr Zarzycki
>>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Jewel Presentation Model properties proxied in TLC classes
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
since I think we're all in the same page I'll be removing this TLC methods
today
thanks
El lun., 14 sept. 2020 a las 10:37, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Piotr,
>
> each property is in its Presentation Model, we are just duplicating a few
> in TLC exposing as TLC's official API.
>
> About PMs: Right now each component used to have its own definition of PM
> with some particularity, if not due to some new property, maybe about
> initialization or default values.
>
> So the plan is just to remove the duplicated APIs from the TLC. That's
> mostly "rowHeight" and "variableRowHeight" from List and DataGrid (maybe
> could be something more since I'm talking from memory).
>
> You always can continue using them in a new instance of the bead like I
> posted in the initial email of the thread, since PMs are working fine now.
>
>
> El lun., 14 sept. 2020 a las 9:33, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> Hi Carlos,
>>
>> Where would you move them ? I mean those properties would be in specific
>> to
>> the component presentation models ?
>>
>> sob., 12 wrz 2020 o 16:06 Hugo Ferreira <hf...@gmail.com>
>> napisał(a):
>>
>> > Hi,
>> >
>> > I use row Height and yes, it's very strange not to be a bead.
>> > For me go ahead. I will ajuste the code on my side after upgrade with
>> the
>> > new change.
>> >
>> > Carlos Rovira <ca...@apache.org> escreveu no dia sábado,
>> 12/09/2020
>> > à(s) 11:52:
>> >
>> > > Hi,
>> > >
>> > > While working on a fix for Presentation Models in Jewel I noticed
>> that we
>> > > have many PM variables that are not used most of the time in
>> component's
>> > > TLC. This happens in List, DataGrid, DataGridColumnList and TabBar
>> > >
>> > > For example, we should do:
>> > >
>> > > <j:TabBar>
>> > > <j:beads>
>> > > <j:TabBarPresentationModel rowHeight="60"/>
>> > > </j:beads>
>> > > </j:TabBar>
>> > >
>> > > instead of
>> > >
>> > > <j:TabBar rowHeight="60">
>> > >
>> > > to keep with PAYG.
>> > >
>> > > Also we have just some variables, but not all exposed
>> > >
>> > > variables exposed in TLCs are:
>> > >
>> > > - rowHeight
>> > > - variableRowHeight
>> > >
>> > > This even makes it inconsistent since we probably want to add more PM
>> > > particularities in the future, and doesn't have sense to me to have
>> just
>> > > some in TLC.
>> > >
>> > > If there's no opposition I'll be removing those jewel vars in the next
>> > > days.
>> > >
>> > > Thanks
>> > >
>> > >
>> > >
>> > > --
>> > > Carlos Rovira
>> > > http://about.me/carlosrovira
>> > >
>> >
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Jewel Presentation Model properties proxied in TLC classes
Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,
each property is in its Presentation Model, we are just duplicating a few
in TLC exposing as TLC's official API.
About PMs: Right now each component used to have its own definition of PM
with some particularity, if not due to some new property, maybe about
initialization or default values.
So the plan is just to remove the duplicated APIs from the TLC. That's
mostly "rowHeight" and "variableRowHeight" from List and DataGrid (maybe
could be something more since I'm talking from memory).
You always can continue using them in a new instance of the bead like I
posted in the initial email of the thread, since PMs are working fine now.
El lun., 14 sept. 2020 a las 9:33, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> Hi Carlos,
>
> Where would you move them ? I mean those properties would be in specific to
> the component presentation models ?
>
> sob., 12 wrz 2020 o 16:06 Hugo Ferreira <hf...@gmail.com>
> napisał(a):
>
> > Hi,
> >
> > I use row Height and yes, it's very strange not to be a bead.
> > For me go ahead. I will ajuste the code on my side after upgrade with the
> > new change.
> >
> > Carlos Rovira <ca...@apache.org> escreveu no dia sábado,
> 12/09/2020
> > à(s) 11:52:
> >
> > > Hi,
> > >
> > > While working on a fix for Presentation Models in Jewel I noticed that
> we
> > > have many PM variables that are not used most of the time in
> component's
> > > TLC. This happens in List, DataGrid, DataGridColumnList and TabBar
> > >
> > > For example, we should do:
> > >
> > > <j:TabBar>
> > > <j:beads>
> > > <j:TabBarPresentationModel rowHeight="60"/>
> > > </j:beads>
> > > </j:TabBar>
> > >
> > > instead of
> > >
> > > <j:TabBar rowHeight="60">
> > >
> > > to keep with PAYG.
> > >
> > > Also we have just some variables, but not all exposed
> > >
> > > variables exposed in TLCs are:
> > >
> > > - rowHeight
> > > - variableRowHeight
> > >
> > > This even makes it inconsistent since we probably want to add more PM
> > > particularities in the future, and doesn't have sense to me to have
> just
> > > some in TLC.
> > >
> > > If there's no opposition I'll be removing those jewel vars in the next
> > > days.
> > >
> > > Thanks
> > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
>
> Piotr Zarzycki
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Jewel Presentation Model properties proxied in TLC classes
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Carlos,
Where would you move them ? I mean those properties would be in specific to
the component presentation models ?
sob., 12 wrz 2020 o 16:06 Hugo Ferreira <hf...@gmail.com> napisał(a):
> Hi,
>
> I use row Height and yes, it's very strange not to be a bead.
> For me go ahead. I will ajuste the code on my side after upgrade with the
> new change.
>
> Carlos Rovira <ca...@apache.org> escreveu no dia sábado, 12/09/2020
> à(s) 11:52:
>
> > Hi,
> >
> > While working on a fix for Presentation Models in Jewel I noticed that we
> > have many PM variables that are not used most of the time in component's
> > TLC. This happens in List, DataGrid, DataGridColumnList and TabBar
> >
> > For example, we should do:
> >
> > <j:TabBar>
> > <j:beads>
> > <j:TabBarPresentationModel rowHeight="60"/>
> > </j:beads>
> > </j:TabBar>
> >
> > instead of
> >
> > <j:TabBar rowHeight="60">
> >
> > to keep with PAYG.
> >
> > Also we have just some variables, but not all exposed
> >
> > variables exposed in TLCs are:
> >
> > - rowHeight
> > - variableRowHeight
> >
> > This even makes it inconsistent since we probably want to add more PM
> > particularities in the future, and doesn't have sense to me to have just
> > some in TLC.
> >
> > If there's no opposition I'll be removing those jewel vars in the next
> > days.
> >
> > Thanks
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Piotr Zarzycki
Re: Jewel Presentation Model properties proxied in TLC classes
Posted by Hugo Ferreira <hf...@gmail.com>.
Hi,
I use row Height and yes, it's very strange not to be a bead.
For me go ahead. I will ajuste the code on my side after upgrade with the
new change.
Carlos Rovira <ca...@apache.org> escreveu no dia sábado, 12/09/2020
à(s) 11:52:
> Hi,
>
> While working on a fix for Presentation Models in Jewel I noticed that we
> have many PM variables that are not used most of the time in component's
> TLC. This happens in List, DataGrid, DataGridColumnList and TabBar
>
> For example, we should do:
>
> <j:TabBar>
> <j:beads>
> <j:TabBarPresentationModel rowHeight="60"/>
> </j:beads>
> </j:TabBar>
>
> instead of
>
> <j:TabBar rowHeight="60">
>
> to keep with PAYG.
>
> Also we have just some variables, but not all exposed
>
> variables exposed in TLCs are:
>
> - rowHeight
> - variableRowHeight
>
> This even makes it inconsistent since we probably want to add more PM
> particularities in the future, and doesn't have sense to me to have just
> some in TLC.
>
> If there's no opposition I'll be removing those jewel vars in the next
> days.
>
> Thanks
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>