royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com.INVALID>
Subject Re: ItemRenderer is not PAYG
Date Mon, 16 Apr 2018 13:52:53 GMT
There's been a huge amount of email surrounding Jewel - which is terrific.
I haven't been able to digest all of it, but one question I have is, how
much did you need to write to support SWF vs HTML/JS? Is that is in the
framework (eg, Core, Basic) sufficient to support Jewel?

‹peter

On 4/16/18, 4:15 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>Hi,
>
>maybe the decision was as well to support SWF? didn't look still to how
>SWF
>does its duty but
>as JS has already ":hover", JS side doesn't need to deal with that since
>CSS make that directly for you.
>
>Anyway.I'm in favor to move that part of the code off from
>UIItemRendererBase, so people could "plug-in" what they want
>
>About Layout I still need to look at how layouts are done in that part
>
>I could raise a "refactoring ticket" so we could look at it at some point
>if it's ok for all
>
>thanks
>
>
>2018-04-16 4:16 GMT+02:00 Alex Harui <aharui@adobe.com.invalid>:
>
>> I didn't do most of this code.  Although even if I did, it might be time
>> for some refactoring.  Thinking about it briefly:
>>
>> Adding the ability to subclass in MXML is introduced at several points
>>in
>> the SDK.  We should be choosing not to weigh down the lowest-level
>>classes
>> with MXML capability (at least for now).
>>
>> I think UIItemRendererBase doesn't need to have the MXML capability.
>>That
>> 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
>> renderers and maybe because there is no "down" or "selected"
>>pseudo-states
>> in CSS, but I agree those can be moved off of UIItemRendererBase to some
>> other class. And 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,y,width,height.   So maybe MXMLItemRenderer should add
>>the
>> code that calls MXMLDataInterpreter and MXMLItemRendererWithLayout would
>> add the assignable layout support.
>>
>> Thoughts?
>> -Alex
>>
>> On 4/15/18, 9:36 AM, "Yishay Weiss" <yishayjobs@hotmail.com> wrote:
>>
>> >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.rovira@gmail.com <carlos.rovira@gmail.com> on behalf of
>> >Carlos Rovira <carlosrovira@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 <aharui@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.rovira@gmail.com on behalf of Carlos
>> >>Rovira"
>> >> <carlos.rovira@gmail.com on behalf of carlosrovira@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
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7Cecb978ca4324470249b508d5
>> >a2ef021a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636594069925131582&s
>> >data=j8lkf7TFiiHpBsMnwJCjhLzCdZ8IOr4amxJuuhWrpRk%3D&reserved=0
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%7C9a4a4dfff1ae47fb5fd108d5a3
>723be6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636594633390366154&sda
>ta=%2FnR1xBBCZ0Z9nHhSgYvlwzHXTq2c4GYlLAyw6CL%2FikA%3D&reserved=0


Mime
View raw message