You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2018/04/14 15:33:36 UTC

ItemRenderer is not PAYG

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
http://about.me/carlosrovira

Re: ItemRenderer is not PAYG

Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yes, sure we had to support SWF, but that could still have been done in a
view or something.

The thing about "hover" pseudo is that you can use CSS for that one state,
but it isn't clear that you can make up your own pseudo for the other
states that Flex supports, so the temptation is to use properties for all
of the states.

Feel free to raise a ticket and even start the refactoring.

-Alex

On 4/16/18, 1: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 <ah...@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" <yi...@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 <ca...@gmail.com> on behalf of
>> >Carlos Rovira <ca...@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 <ah...@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%7Caharui%40adobe.com%7Cba5f2e8a29c44f2d4d2f08d5
>a3723df5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636594633458450044&s
>data=u1WYozTeJSrXUIxG2Zm%2BkfQQSkZQXg4uZ8mryPCCYKg%3D&reserved=0

Re: ItemRenderer is not PAYG

Posted by Carlos Rovira <ca...@apache.org>.
Peter,

That's right, input range is what MDL and other uses and has good support
in browsers so it's the best option for HTML. In the other hand I steel
have to implement vertical version that seems to be done with a
transformation of the component (or at least is what is most people do).

Thanks

2018-04-18 16:32 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:

> In my spare time I've been playing around with components that just build
> HTML without SWF and it does make it easier. I saw the range input and
> that's a great way IMO to handle the browser side.
>
> —peter
>
> On 4/16/18, 12:38 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi Peter,
> >
> >that's mainly the problem. As Alex said in some moment, I'll be happy if
> >we
> >approach the SWF in two phase,
> >one that at least show minimal bounding boxes, interaction and events
> >working ok. Then go the "skinning" phase.
> >
> >We should have to look at some particularities. For example Slider in
> >Jewel
> >is done like in MDL with an input range,
> >that makes lots for you, but in Flash there's no such control, so the
> >current basic implementation is ok (two buttons, one
> >for track and one for thumb), but again our ISliderView interface is not
> >right anymore since in JS we don't need "track"
> >and "thumb" since input range does not has that parts, although in CSS
> >there's something similar
> >
> >Thanks, for looking the virtual list bug! :)
> >
> >
> >
> >2018-04-16 17:40 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
> >
> >> Sure, I'll be happy to look at the bug.
> >>
> >> I was asking about SWF because I was toying with the idea of a SWF-free
> >> framework and how much time is spent to get the SWF side working when
> >>the
> >> browser just does so much for you. Not everything of course, but
> >>sometimes
> >> simple things for the browser is a good chunk of work for SWF.
> >>
> >> —peter
> >>
> >> On 4/16/18, 11:36 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> >>
> >> >Hi Peter,
> >> >
> >> >thanks! I really didn't look too much at SWF. I really would like to do
> >> >but
> >> >it's a huge amount of work to deal with HTML only.
> >> >But I don't want to left SWF version undone, and I try to think on it
> >>in
> >> >order to give a revision at some time and see what's failing and what
> >>not.
> >> >Another thing in the same boat are for example transitions and effects
> >>(at
> >> >least CSS for JS). I think we need all components working and good
> >> >looking,
> >> >then we can start looking to see more things in terms of effects and
> >> >transitions. At least this is my plan so I can deal with all of it.
> >> >
> >> >Peter, one thing I need from you is if you can take a look at this bug
> >> >[1],
> >> >I'm now dealing with lists, and virtual list are very important.
> >> >
> >> >thanks!
> >> >
> >> >[1] Virtual List handles final items incorrectly
> >> ><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fgithub.c
> >>
> >>>om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent%
> 40adobe.com
> >> %7
> >> >C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7
> >> >C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW%
> >> 2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ
> >> >frY%3D&reserved=0>
> >> >
> >> ><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fgithub.c
> >>
> >>>om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent%
> 40adobe.com
> >> %7
> >> >C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7
> >> >C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW%
> >> 2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ
> >> >frY%3D&reserved=0>
> >> >
> >> >
> >> >
> >> >2018-04-16 15:52 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
> >> >
> >> >> 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 <ah...@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" <yi...@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 <ca...@gmail.com> on
> behalf
> >> of
> >> >> >> >Carlos Rovira <ca...@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 <ah...@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
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%
> >> 7C67df4df73179488905ab08d5a3
> >> >afd574%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636594897951239437&sda
> >> >ta=yHn%2BfuKivMYAoiaqxrWxEyhY8ykpi1Gqoq8wIr3mgzo%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%
> 7C42790cf9f852488c70bd08d5a3
> >b8889e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636594935315481671&sda
> >ta=GQBkm9%2BteqUn4xPPq26P08rXczAPUI0%2BYKCtIaT2swI%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: ItemRenderer is not PAYG

Posted by Peter Ent <pe...@adobe.com.INVALID>.
In my spare time I've been playing around with components that just build
HTML without SWF and it does make it easier. I saw the range input and
that's a great way IMO to handle the browser side.

—peter

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

>Hi Peter,
>
>that's mainly the problem. As Alex said in some moment, I'll be happy if
>we
>approach the SWF in two phase,
>one that at least show minimal bounding boxes, interaction and events
>working ok. Then go the "skinning" phase.
>
>We should have to look at some particularities. For example Slider in
>Jewel
>is done like in MDL with an input range,
>that makes lots for you, but in Flash there's no such control, so the
>current basic implementation is ok (two buttons, one
>for track and one for thumb), but again our ISliderView interface is not
>right anymore since in JS we don't need "track"
>and "thumb" since input range does not has that parts, although in CSS
>there's something similar
>
>Thanks, for looking the virtual list bug! :)
>
>
>
>2018-04-16 17:40 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
>
>> Sure, I'll be happy to look at the bug.
>>
>> I was asking about SWF because I was toying with the idea of a SWF-free
>> framework and how much time is spent to get the SWF side working when
>>the
>> browser just does so much for you. Not everything of course, but
>>sometimes
>> simple things for the browser is a good chunk of work for SWF.
>>
>> —peter
>>
>> On 4/16/18, 11:36 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Hi Peter,
>> >
>> >thanks! I really didn't look too much at SWF. I really would like to do
>> >but
>> >it's a huge amount of work to deal with HTML only.
>> >But I don't want to left SWF version undone, and I try to think on it
>>in
>> >order to give a revision at some time and see what's failing and what
>>not.
>> >Another thing in the same boat are for example transitions and effects
>>(at
>> >least CSS for JS). I think we need all components working and good
>> >looking,
>> >then we can start looking to see more things in terms of effects and
>> >transitions. At least this is my plan so I can deal with all of it.
>> >
>> >Peter, one thing I need from you is if you can take a look at this bug
>> >[1],
>> >I'm now dealing with lists, and virtual list are very important.
>> >
>> >thanks!
>> >
>> >[1] Virtual List handles final items incorrectly
>> ><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fgithub.c
>> 
>>>om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent%40adobe.com
>> %7
>> >C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7
>> >C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW%
>> 2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ
>> >frY%3D&reserved=0>
>> >
>> ><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fgithub.c
>> 
>>>om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent%40adobe.com
>> %7
>> >C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7
>> >C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW%
>> 2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ
>> >frY%3D&reserved=0>
>> >
>> >
>> >
>> >2018-04-16 15:52 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
>> >
>> >> 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 <ah...@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" <yi...@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 <ca...@gmail.com> on behalf
>> of
>> >> >> >Carlos Rovira <ca...@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 <ah...@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
>> >>
>> >>
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%
>> 7C67df4df73179488905ab08d5a3
>> >afd574%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636594897951239437&sda
>> >ta=yHn%2BfuKivMYAoiaqxrWxEyhY8ykpi1Gqoq8wIr3mgzo%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%7C42790cf9f852488c70bd08d5a3
>b8889e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636594935315481671&sda
>ta=GQBkm9%2BteqUn4xPPq26P08rXczAPUI0%2BYKCtIaT2swI%3D&reserved=0

Re: ItemRenderer is not PAYG

Posted by Carlos Rovira <ca...@apache.org>.
Hi Peter,

that's mainly the problem. As Alex said in some moment, I'll be happy if we
approach the SWF in two phase,
one that at least show minimal bounding boxes, interaction and events
working ok. Then go the "skinning" phase.

We should have to look at some particularities. For example Slider in Jewel
is done like in MDL with an input range,
that makes lots for you, but in Flash there's no such control, so the
current basic implementation is ok (two buttons, one
for track and one for thumb), but again our ISliderView interface is not
right anymore since in JS we don't need "track"
and "thumb" since input range does not has that parts, although in CSS
there's something similar

Thanks, for looking the virtual list bug! :)



2018-04-16 17:40 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:

> Sure, I'll be happy to look at the bug.
>
> I was asking about SWF because I was toying with the idea of a SWF-free
> framework and how much time is spent to get the SWF side working when the
> browser just does so much for you. Not everything of course, but sometimes
> simple things for the browser is a good chunk of work for SWF.
>
> —peter
>
> On 4/16/18, 11:36 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi Peter,
> >
> >thanks! I really didn't look too much at SWF. I really would like to do
> >but
> >it's a huge amount of work to deal with HTML only.
> >But I don't want to left SWF version undone, and I try to think on it in
> >order to give a revision at some time and see what's failing and what not.
> >Another thing in the same boat are for example transitions and effects (at
> >least CSS for JS). I think we need all components working and good
> >looking,
> >then we can start looking to see more things in terms of effects and
> >transitions. At least this is my plan so I can deal with all of it.
> >
> >Peter, one thing I need from you is if you can take a look at this bug
> >[1],
> >I'm now dealing with lists, and virtual list are very important.
> >
> >thanks!
> >
> >[1] Virtual List handles final items incorrectly
> ><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.c
> >om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent%40adobe.com
> %7
> >C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7
> >C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW%
> 2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ
> >frY%3D&reserved=0>
> >
> ><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.c
> >om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent%40adobe.com
> %7
> >C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7
> >C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW%
> 2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ
> >frY%3D&reserved=0>
> >
> >
> >
> >2018-04-16 15:52 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
> >
> >> 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 <ah...@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" <yi...@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 <ca...@gmail.com> on behalf
> of
> >> >> >Carlos Rovira <ca...@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 <ah...@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
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%
> 7C67df4df73179488905ab08d5a3
> >afd574%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636594897951239437&sda
> >ta=yHn%2BfuKivMYAoiaqxrWxEyhY8ykpi1Gqoq8wIr3mgzo%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: ItemRenderer is not PAYG

Posted by Peter Ent <pe...@adobe.com.INVALID>.
Sure, I'll be happy to look at the bug.

I was asking about SWF because I was toying with the idea of a SWF-free
framework and how much time is spent to get the SWF side working when the
browser just does so much for you. Not everything of course, but sometimes
simple things for the browser is a good chunk of work for SWF.

—peter

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

>Hi Peter,
>
>thanks! I really didn't look too much at SWF. I really would like to do
>but
>it's a huge amount of work to deal with HTML only.
>But I don't want to left SWF version undone, and I try to think on it in
>order to give a revision at some time and see what's failing and what not.
>Another thing in the same boat are for example transitions and effects (at
>least CSS for JS). I think we need all components working and good
>looking,
>then we can start looking to see more things in terms of effects and
>transitions. At least this is my plan so I can deal with all of it.
>
>Peter, one thing I need from you is if you can take a look at this bug
>[1],
>I'm now dealing with lists, and virtual list are very important.
>
>thanks!
>
>[1] Virtual List handles final items incorrectly
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent%40adobe.com%7
>C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7
>C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW%2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ
>frY%3D&reserved=0>
>
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent%40adobe.com%7
>C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7
>C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW%2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ
>frY%3D&reserved=0>
>
>
>
>2018-04-16 15:52 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
>
>> 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 <ah...@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" <yi...@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 <ca...@gmail.com> on behalf of
>> >> >Carlos Rovira <ca...@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 <ah...@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
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%7C67df4df73179488905ab08d5a3
>afd574%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636594897951239437&sda
>ta=yHn%2BfuKivMYAoiaqxrWxEyhY8ykpi1Gqoq8wIr3mgzo%3D&reserved=0

Re: ItemRenderer is not PAYG

Posted by Carlos Rovira <ca...@apache.org>.
Hi Peter,

thanks! I really didn't look too much at SWF. I really would like to do but
it's a huge amount of work to deal with HTML only.
But I don't want to left SWF version undone, and I try to think on it in
order to give a revision at some time and see what's failing and what not.
Another thing in the same boat are for example transitions and effects (at
least CSS for JS). I think we need all components working and good looking,
then we can start looking to see more things in terms of effects and
transitions. At least this is my plan so I can deal with all of it.

Peter, one thing I need from you is if you can take a look at this bug [1],
I'm now dealing with lists, and virtual list are very important.

thanks!

[1] Virtual List handles final items incorrectly
<https://github.com/apache/royale-asjs/issues/177>

<https://github.com/apache/royale-asjs/issues/177>



2018-04-16 15:52 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:

> 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 <ah...@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" <yi...@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 <ca...@gmail.com> on behalf of
> >> >Carlos Rovira <ca...@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 <ah...@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
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: ItemRenderer is not PAYG

Posted by Peter Ent <pe...@adobe.com.INVALID>.
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 <ah...@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" <yi...@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 <ca...@gmail.com> on behalf of
>> >Carlos Rovira <ca...@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 <ah...@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

Re: ItemRenderer is not PAYG

Posted by Carlos Rovira <ca...@apache.org>.
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 <ah...@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" <yi...@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 <ca...@gmail.com> on behalf of
> >Carlos Rovira <ca...@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 <ah...@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
http://about.me/carlosrovira

Re: ItemRenderer is not PAYG

Posted by Alex Harui <ah...@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" <yi...@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 <ca...@gmail.com> on behalf of
>Carlos Rovira <ca...@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 <ah...@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

RE: ItemRenderer is not PAYG

Posted by Yishay Weiss <yi...@hotmail.com>.
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 <ca...@gmail.com> on behalf of Carlos Rovira <ca...@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 <ah...@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
http://about.me/carlosrovira

Re: ItemRenderer is not PAYG

Posted by Carlos Rovira <ca...@apache.org>.
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 <ah...@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
http://about.me/carlosrovira

Re: ItemRenderer is not PAYG

Posted by Alex Harui <ah...@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

Re: ItemRenderer is not PAYG

Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ca...@apache.org>:

> 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 separated more used
> functionality like "disabled" or "passwordinput" for text input, to name
> few examples. In this concrete case, Jewel. will never use that kind of
> methods since all visual estates in the item renderer are defined in CSS.
>
> updateRenderer is ok since I'm overriding it. What's not ok is to have all
> color properties and switch of colors bake into a base item renderer class
> that is buried 3-4 leves down the hierarchy. If it was final level I can
> extend from the parent since normaly it would not be affected by the rest
> of classes and components related.
>
>
>
> 2018-04-14 18:27 GMT+02:00 Piotr Zarzycki <pi...@gmail.com>:
>
> > 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 <ca...@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
> > > http://about.me/carlosrovira
> > >
> >
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: ItemRenderer is not PAYG

Posted by Carlos Rovira <ca...@apache.org>.
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 separated more used
functionality like "disabled" or "passwordinput" for text input, to name
few examples. In this concrete case, Jewel. will never use that kind of
methods since all visual estates in the item renderer are defined in CSS.

updateRenderer is ok since I'm overriding it. What's not ok is to have all
color properties and switch of colors bake into a base item renderer class
that is buried 3-4 leves down the hierarchy. If it was final level I can
extend from the parent since normaly it would not be affected by the rest
of classes and components related.



2018-04-14 18:27 GMT+02:00 Piotr Zarzycki <pi...@gmail.com>:

> 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 <ca...@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
> > http://about.me/carlosrovira
> >
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: ItemRenderer is not PAYG

Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ca...@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
> http://about.me/carlosrovira
>