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, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> 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 <[email protected]>: > >> 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, "[email protected] on behalf of Carlos >>Rovira" >> <[email protected] on behalf of [email protected]> 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 <[email protected]>: >> > >> >> 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 >> >> >> >> >> > >> > >> >-- >> >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
