I 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 ISelectableItemRenderer (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 can explain what the reasoning was for that?
________________________________
From: carlos.rov...@gmail.com <carlos.rov...@gmail.com> on behalf of Carlos
Rovira <carlosrov...@apache.org>
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 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 see a way to get
rid of it unless I create the same chain.
Being said that, this is not critical for me, I can live with those
properties buried in the code, but I want to put this here to signal a
point when I see PAYG is not begin followed.
For me people that wants to use colors in code should "aggregate it" in a
PAYG way, and people that wants css should do the same on its way.
In other words, people using Jewel will have code in their apps that will
be never used, and I think that's what we're trying to avoid
2018-04-15 8:54 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> 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...@gmail.com on behalf of Carlos Rovira"
> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>
> >Hi,
> >
> >this base class
> >
> >UIItemRendererBase
> >
> >has properties for all colors (hover, selected, and more) and a "useColor"
> >property, and updateRenderer() method is switching "useColor"
> >
> >as a low level class, I think this class should not have all this info,
> >since most people will never use.
> >
> >In Basic I think is possible, but in Jewel colors, shapes and effects
> >comer
> >from CSS.
> >
> >In this case I think 95% of users will never go that way of setting colors
> >when the can do simply this:
> >
> >.jewel.item {
> >cursor: pointer;
> >padding: 8px;
> >flex-shrink: 0;
> >flex-grow: 1;
> >}
> >.jewel.item:hover {
> >color: #FFFFFF;
> >background: #24a3ef;
> >}
> >.jewel.item:active, .jewel.item.selected {
> >color: #FFFFFF;
> >background: #0f88d1;
> >}
> >
> >without wiring a single line between logic and css.
> >
> >So I think useColors, and colors should be refactored to a bead or
> >something that will not compromise the high level UI sets that will never
> >use this kind of properties.
> >
> >Although I'm creating a ItemRenderer from scratch, my problem here's that
> >there's so much hierarchy here and many other classes in the tree that
> >depends.
> >
> >Creating a class extending "leaf" class nodes are easy, but when problems
> >arise in the middle of the hierarchy chain, we have a problem that is
> >difficult to solve
> >
> >thanks
> >
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C6594b31e04554af2d97808d5
> >a21d2617%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636593168509138978&s
> >data=q1GZeXydbyaKPui4RFXJG4%2FlUdCrTcioiycbxGE5FD4%3D&reserved=0
>
>
--
Carlos Rovira
http://about.me/carlosrovira
