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, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> 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 <[email protected]>: > >> 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" <[email protected]> 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: [email protected] <[email protected]> on behalf of >> >Carlos Rovira <[email protected]> >> >Sent: Sunday, April 15, 2018 2:29:20 PM >> >To: [email protected] >> >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 <[email protected]>: >> > >> >> 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, "[email protected] on behalf of Carlos >> >>Rovira" >> >> <[email protected] on behalf of [email protected]> 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
