gt; >> >> way, AS-based ItemRenderers will be a bit lighter and faster.
> >> >> >> I think that the reason there are selectedColor, highlightColor,
> >>and
> >> >> >> downColor properties is for backward compatibility with Flex item
>
olor properties is for backward compatibility with Flex item
>> >> >> renderers and maybe because there is no "down" or "selected"
>> >> >>pseudo-states
>> >> >> in CSS, but I agree those can be moved off of UIItemRendererB
d the implementation of those color properties could
> >>just
> >> >> set styles or class selectors.
> >> >>
> >> >> I think assignable layout is not required in item renderers. Simple
> >> >>ones
> >> >> can just set x,
gt; >>
>> >> Thoughts?
>> >> -Alex
>> >>
>> >> On 4/15/18, 9:36 AM, "Yishay Weiss" wrote:
>> >>
>> >> >I think we need to accept that there are some assumptions made in
>>base
>> >> >
ectableItemRenderer (or IItemRenderer).
>> >
>> >
>> >
>> >What I find confusing is that MXMLItemRenderer does not explicitly
>> >implement IMXMLDocument, and that most of the mxml related code is
>> >actually in UIItemRendererBase. Alex, maybe you ca
think we need to accept that there are some assumptions made in base
> >> >classes that will not apply to every case. This is the tension between
> >> >PAYG and reusability which has been discussed before. As Alex suggested
> >> >you can always create a different implementation for
> >> >ISelectab
on between
>> >PAYG and reusability which has been discussed before. As Alex suggested
>> >you can always create a different implementation for
>> >ISelectableItemRenderer (or IItemRenderer).
>> >
>> >
>> >
>> >What I find confusing is th
ment IMXMLDocument, and that most of the mxml related code is
> >actually in UIItemRendererBase. Alex, maybe you can explain what the
> >reasoning was for that?
> >
> >
> >
> >
> >From: carlos.rov...@gmail.com on behalf of
;
>
>
>From: carlos.rov...@gmail.com on behalf of
>Carlos Rovira
>Sent: Sunday, April 15, 2018 2:29:20 PM
>To: dev@royale.apache.org
>Subject: Re: ItemRenderer is not PAYG
>
>Hi,
>
>the hierarchy chain is "UIItemRendererBase >
: carlos.rov...@gmail.com on behalf of Carlos
Rovira
Sent: Sunday, April 15, 2018 2:29:20 PM
To: dev@royale.apache.org
Subject: Re: ItemRenderer is not PAYG
Hi,
the hierarchy chain is "UIItemRendererBase > DataItemRenderer >
MXMLItemRenderer"
ListItemRenderer extend from MXMLItemRendere
Hi,
the hierarchy chain is "UIItemRendererBase > DataItemRenderer >
MXMLItemRenderer"
ListItemRenderer extend from MXMLItemRenderer (if that's not the right
class let me know), since users will want to create mainly MXML item
renderers.
So UIItemRendererBase is buried in the chain and I don't se
There is no obligation to use UIItemRendererBase for Jewel ItemRenderers.
If you run into places where we assume UIItemRendererBase and not
IItemRenderer, that's either a bug or requires a different controller or
view.
Let us know what you run into.
-Alex
On 4/14/18, 8:33 AM, "carlos.rov...@gmai
Carlos,
It is your way of approach where everything what you are doing is in CSS,
but I don't agree that the way where you are setting some styles in the
code is bad one. It's just different approach which is really good in some
cases.
Thanks,
Piotr
2018-04-14 23:02 GMT+02:00 Carlos Rovira :
>
Hi Piotr,
I have already checked Jewel List and ListItemRenderer before sending this
email.
Jewel is working, I only say that is carrying some overhead of properties,
getters and setters and methods that Jewel users will never user at 100%,
so that's why we want to avoid with PAYG and why we separ
Hi Carlos,
That's why you are creating your own Item renderer and override that method.
Although if you can propose other solution. Of course on different branch
with checking if you not break anything.
Especially MDL Table.
Thanks,
Piotr
On Sat, Apr 14, 2018, 5:34 PM Carlos Rovira wrote:
>
15 matches
Mail list logo