Hi Alex, remember that Jewel uses SASS to create the CSS. I already pushed a commit with ["warning"]. It's not the first time I warn about it ;) You must to change SASS file. The css is just generated (like other generations in compiler), and is committed since no body added SASS to ANT. Maven has a sass plugin to compile SASS.
I saw you response and commented there Thanks Carlos El jue., 20 feb. 2020 a las 19:55, Alex Harui (<[email protected]>) escribió: > I replied on this topic on your commit email. > > So I don't have to copy that into this thread, read what I said in that > email and reply on that thread and let's figure out the right thing to do. > I am having some weird problem with my Maven build where every time I try > to change Jewel's defaults.css something overwrites it. I'm trying to > figure out what is going on there. > > -Alex > > On 2/20/20, 10:47 AM, "Carlos Rovira" <[email protected]> wrote: > > Hi Alex, > > I found that TodoMVC examples was not working, so I fixed it removing > the > non existing properties (hoverable and selectable). > But I found Jewel ListItemRenderer has all baked, so I created a > SimpleListItemRenderer (in Jewel Simple in the normal prefix for a > "base", > "basic" or "simple" option) that hast the minimum required. > > So at least in Jewel if people wants hoverable and selectable > renderers use > the normal ListItemRenderer. > If don't want that indicators, use SimpleListItemRenderer. If you want > just > show hover, but not selected state, then extend Simple version and add > " > ClassSelectorListRuntimeSelectableItemRendererBead" and configure to > have > just "hoverable" to true ¿ok? > > Hope I understand ok how it works. Let me know if something is not as > expected. > > Thanks > > Carlos > > > > El jue., 20 feb. 2020 a las 18:06, Alex Harui > (<[email protected]>) > escribió: > > > I'm not sure I understand what you mean by "control". > > > > Before the "has" changes, every ItemRenderer contained or inherited > code > > that had hovered/selected APIs that drew visuals, and the > ItemRenderer also > > "had" a bead like ItemRendererMouseController that set the hovered > property > > on that item renderer, and the List's controller would set the > selected > > property. > > > > Now, every ItemRenderer "has" a bead that has the hovered/selected > > properties, and the ItemRendererMouseController and the Lists's > controllers > > get that bead instead of talking to the ItemRenderer directly. I > guess > > that's the new way of thinking for has/composition vs > is/inheritance: a > > component doesn't have to have all of its APIs glued to its API > surface. > > We mainly do that for convenience in MXML, but for more internal > stuff like > > this, loose-coupling via has/composition shared more code and > increases > > configurability, but does add some runtime overhead in its raw form. > > Hopefully we can optimize that away. > > > > HTH, > > -Alex > > > > On 2/20/20, 5:01 AM, "Piotr Zarzycki" <[email protected]> > wrote: > > > > Hi Alex, > > > > Could you provide an example how would I control > hovering/selecting in > > item > > renderer when I don't have build in hover property etc. ? How > should I > > compose such item renderer ? > > > > Thanks, > > Piotr > > > > czw., 20 lut 2020 o 03:20 Alex Harui <[email protected]> > > napisał(a): > > > > > I pushed the "has" changes. TourDeJewel seems to be working > > correctly for > > > me. > > > > > > The principle of "has" is similar to inheritance vs > composition. > > Just > > > like top-level components like List are composed of many > beads, the > > item > > > renderers are now composed of more beads as well. That > reduces the > > > requirement to add code to a class in order to "be/is" > something. > > > > > > There used to be copies of code that drew hover and selected > states > > on > > > the item renderers in each new kind of item renderer that > couldn't > > inherit > > > from an item renderer that could draw selected and hovered > states. > > Now, > > > the itemrenderers compose their selection visuals. A single > item > > renderer > > > like StringItemRenderer can be composed with no selection > drawing at > > all, > > > or with solid color selection drawing or with alternate color > > selection > > > drawing or something new. And that means that some new kind > of > > item > > > renderer, like a TextInput can become an item renderer more > easily, > > by > > > composing a selection visuals bead instead of having to add > all of > > that > > > code. > > > > > > Another place I started using "has" but didn't fully replace > the old > > code > > > was in handling itemRendererParent, which is now called > > > itemRendererOwnerView (to try to make it more clear that isn't > > always the > > > parent of the item renderer and is sometimes an internal > > > datagroup/container). Turns out a lot of our renderers didn't > need > > to know > > > the itemRendererParent, so in many cases we no longer figure > it out > > and > > > assign it. But in cases where it is needed, the property is > > currently left > > > baked into the renderer, but in some new cases, it is > composed. An > > > ItemRendererOwnerViewBead is added to the strand instead of > added to > > a > > > class and contains the reference to the ownerView. Maybe > someday > > we'll > > > fully remove the old pattern, not sure. > > > > > > Ideally we would do more "has" than "is". It could allow us to > > eliminate > > > much of the required code to be a top tag in an MXML document. > > > > > > Other changes in this branch were to add "Initializers" so the > > > RendererFactories didn't bake in code for specific item > renderers, > > and to > > > create a few base classes with overrides so there is less code > to > > maintain. > > > > > > There should be little if any impact to application code. It > should > > > mainly affect the internals of how item renderer-based things > are > > created. > > > > > > Thanks, > > > -Alex > > > > > > On 2/17/20, 4:33 PM, "Carlos Rovira" <[email protected]> > > wrote: > > > > > > Hi Alex, > > > > > > if will be of help if you point us to different links > where we > > can > > > learn > > > about this modifications, since I at least can just > imagine what > > is all > > > about, but will need to get deeper in the concepts to > understand > > the > > > changes and to apply this patterns. > > > > > > In Jewel each "list component has its own type of > renderer, so > > for > > > example > > > List uses ListItemRenderer and DataGrid has > > DataGridItemRenderer, since > > > usually at that component level the user needs similar > > infrastructure > > > like > > > hoverable, selectable...and some (not much) more, don't > know > > right now > > > how > > > all this will fit with the "has" new pattern....I'll try > it. > > > > > > Just one important thing. There's actual users and clients > using > > Jewel > > > and > > > other UI sets and are with very short times for their > > migrations, so > > > just > > > want to ask you to test as much as possible, since TDJ has > many > > > examples > > > now. Other thing you can test is new TodoMVC to see how it > > behaves, > > > since > > > it uses a List with IRs. So we can ensure (as much as we > can) > > the merge > > > left things working (as much as we can) > > > > > > Thanks for working on this, will try all of this tomorrow > > > > > > Carlos > > > > > > > > > > > > > > > El lun., 17 feb. 2020 a las 22:35, Alex Harui > > > (<[email protected]>) > > > escribió: > > > > > > > I've pushed the "has" branch that contains a refactoring > of > > the item > > > > renderers. Tour De Jewel and MDL Example seem to be > working > > as is > > > Basic > > > > List Example and MX AdvancedDataGrid. > > > > > > > > "has" is really just calls to getBeadByType. If we > start to > > see > > > > performance issues, then we'll look into optimizing. The > > motivation > > > to > > > > switch to "has" came from several bugs about using MX > > Label/CheckBox > > > as > > > > item renderers. In Royale, the ItemRenderers were in > control > > of the > > > > visuals of their rollover and selected state. That is a > more > > proper > > > > encapsulation than the way it was in Flex where the > lists drew > > the > > > rollover > > > > and selected states and it was hard to override the > visuals > > for a > > > custom > > > > item renderer. But in the develop branch Royale code, > it would > > > require > > > > that custom itemrenderers implement a lot of APIs > related to > > > rollover and > > > > selected visuals. Instead we can now reuse/share code > for > > visuals > > > between > > > > different renderers because a renderer now can "has" a > > > rollover/selection > > > > implementation instead of being one. > > > > > > > > There are more pieces involved, but there is more > sharing of > > code. > > > Along > > > > the way I found that there were some not-so-PAYG patterns > > being used > > > in MDL > > > > and Jewel renderers that might deserve further > modification. > > There > > > are > > > > "hoverable" and "selectable" APIs that appear to be used > to > > > permanently > > > > turn off selection and hover visuals. In general, I > think > > there is > > > better > > > > use of PAYG and composition when functionality is "built > up" > > and not > > > > "turned off", so with the "has" pattern the renderers > can be > > added > > > to a > > > > list without any selection visuals at all (for a > non-selectable > > > list) or > > > > re-composed with custom visuals that only support > hoverable, > > for > > > example. > > > > I left it "hoverable/selectable" in the API surface for > now, > > but > > > something > > > > to think about going forward. > > > > > > > > I’m going to run a few more tests before merging and > pushing to > > > develop. > > > > > > > > -Alex > > > > > > > > On 1/15/20, 10:44 PM, "Alex Harui" > <[email protected]> > > wrote: > > > > > > > > You are welcome to try and see how many cache hits it > > gets. I > > > think > > > > in renderers, we ask once per renderer. I'm not sure > there is > > a > > > faster way > > > > to do the first lookup of "is", but for "has" we could > change > > the > > > lookup > > > > and save time. > > > > > > > > On 1/15/20, 10:38 PM, "Greg Dove" < > [email protected]> > > wrote: > > > > > > > > For the 'something is ISomeInterface' > > > > I had wondered in the past if these types of > lookups > > could be > > > > incrementally > > > > cached on the 'is' target (after first lookup), > that > > might > > > make > > > > sense for > > > > interfaces, which are the deepest checks I think? > > > > caching result (could optionally create the Map) > > > > > ISomeInterface['implMap'].set(something.constructor, > > > isResult ) > > > > > > > > then earlier in the interface checks, it could do > > something > > > like: > > > > if (ISomeInterface['implMap'] && > > > > > ISomeInterface['implMap'].has(something.constructor) ) > > return > > > > > ISomeInterface['implMap'].get(something.constructor) > > > > > > > > I realize its extra code, but it should be quite > a bit > > > faster over > > > > time I > > > > think. > > > > > > > > On Thu, Jan 16, 2020 at 7:20 PM Alex Harui > > > > <[email protected]> wrote: > > > > > > > > > Hi, > > > > > > > > > > Several different threads have brought up > issues with > > > sharing > > > > code between > > > > > component sets. Other threads have offered > > different and > > > clever > > > > ways to > > > > > do various things like how MXML is applied to a > > component. > > > > Meanwhile, over > > > > > in MX emulation, I was starting to copy some > code > > from > > > Basic to > > > > MXRoyale to > > > > > get the various MX components to be valid item > > renderers. > > > > MXRoyale is > > > > > using Basic's item renderer architecture which > is > > better > > > > encapsulated: the > > > > > renderer draws its hovered and selected > state. In > > Flex, > > > the > > > > List draws > > > > > over the renderer, which makes it hard to > customize > > the > > > way the > > > > renderer > > > > > will look when hovered and selected. > > > > > > > > > > It finally occurred to me that one of the > reasons we > > end up > > > > copying code > > > > > is because we are still using too many "is" > checks > > instead > > > of > > > > "has" > > > > > checks. I'm not even sure we have any "has" > checks > > in the > > > Royale > > > > > framework. I was afraid of the overhead of a > "has" > > check, > > > but > > > > I'm starting > > > > > to change my mind because: > > > > > > > > > > 1) The "is" check actually runs a fair amount > of > > code, > > > > especially for > > > > > (comp is ISomeInterface) > > > > > 2) The length of bead arrays don't seem too > long. > > > > > > > > > > A "has" check calls > getBeadByType(ISomeInterface), > > so it > > > > actually will run > > > > > the (bead is ISomeInterface) on potentially the > > entire > > > strand > > > > array/vector, > > > > > although we could speed that up by annotating > beads > > or > > > keeping > > > > track of > > > > > what is on the strand. But the code > sharing/reuse > > > potential of > > > > this > > > > > pattern seems significant to me. > > > > > > > > > > For example, it could change how hard it is to > make a > > > component > > > > usable as > > > > > a top tag in MXML. Instead of the component > having > > to > > > implement > > > > certain > > > > > methods, the component could have a bead > installed > > and the > > > > > MXMLDataInterpreter could talk to that bead > instead > > of the > > > > component. > > > > > > > > > > In the case of the item renderers, instead of > > testing if > > > the > > > > renderer "is" > > > > > ISelectableLIstItemRenderer, it could ask if > the > > created > > > widget > > > > "has" an > > > > > ISelectableLIstItemRenderer bead and the logic > in > > that > > > bead can > > > > be reused > > > > > in both Basic and MXRoyale without being > copied. > > > > > > > > > > Some code, like Container overrides of > addElement > > probably > > > can't > > > > be > > > > > refactored into a "has". But I wonder how > many other > > > things > > > > could. I'm > > > > > not sure I would move everything that could be > moved > > into a > > > > shared bead. > > > > > We'd have to think about the overhead on small > > components > > > and > > > > apps. But > > > > > for MXML support and Item Renderer support, it > seems > > to > > > make > > > > sense. > > > > > > > > > > Anyway, I will look into refactoring the item > > renderer > > > code in > > > > a few days > > > > > unless feedback indicates otherwise. Bugs > like #676 > > and > > > #681 > > > > inspired this > > > > > post. > > > > > > > > > > Of course, I could be wrong... > > > > > -Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Carlos Rovira > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=%2Focc44UHHmgVpF2xL8oZ%2BVBLtX44GHKoFHtq%2F3Mp%2FKc%3D&reserved=0 > > > > > > > > > > > > > -- > > > > Piotr Zarzycki > > > > Patreon: * > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=mNSxkulMZtr1uwjGK3UI04yeUfj05eR9vm%2BzZtUH0fk%3D&reserved=0 > > < > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=mNSxkulMZtr1uwjGK3UI04yeUfj05eR9vm%2BzZtUH0fk%3D&reserved=0 > > >* > > > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce7e411735d6c42d1913108d7b635669d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178212785529057&sdata=%2Focc44UHHmgVpF2xL8oZ%2BVBLtX44GHKoFHtq%2F3Mp%2FKc%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
