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