yes, Jewel has the "structure" and is organized in SASS files, then JewelTheme has the "styling" part and is as well SASS. so Jewel should not need to change, and people should only need to change JewelTheme or create a new theme one using it as a template.
I'll add examples to ant tomorrow thanks El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aha...@adobe.com.invalid>) escribió: > > > On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > forgot to say. Can you add missing examples to ANT? don't know where > to do > that > and checking Jewel don't see the use of > SelectableItemRendererClassFactory. > all times ItemRendererClassFactory is used > > I could fix the Ant side, but I don't have time. It think all you need to > do is add it to the examples/build.xml > > I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't > sure if the selection was supposed to be changeable at runtime. I think > you've confirmed that it isn't so we can change to use > SelectableItemRendererClassFactory > > I knew the themes were generated by SASS, but I didn't realize the Jewel > one was as well. > > -Alex > > El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (< > carlosrov...@apache.org>) > escribió: > > > 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 > (<aha...@adobe.com.invalid>) > > 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" <carlosrov...@apache.org> > 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 > >> (<aha...@adobe.com.invalid>) > >> 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" < > piotrzarzyck...@gmail.com> > >> 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 > <aha...@adobe.com.invalid> > >> > 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" < > carlosrov...@apache.org > >> > > >> > 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 > >> > > (<aha...@adobe.com.invalid>) > >> > > 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" > >> <aha...@adobe.com.INVALID> > >> > 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" < > >> greg.d...@gmail.com> > >> > 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 > >> > > > <aha...@adobe.com.invalid> 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%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%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%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=GiQ6hMBA27oNI4zjcqNpgMTTIKCuiitizY8QwIQ48JI%3D&reserved=0 > >> > < > >> > > >> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=GiQ6hMBA27oNI4zjcqNpgMTTIKCuiitizY8QwIQ48JI%3D&reserved=0 > >> > >* > >> > > >> > > >> > > >> > >> -- > >> Carlos Rovira > >> > >> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0 > >> > >> > >> > > > > -- > > Carlos Rovira > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0 > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2d4cafb117044980e18d08d7b637bd39%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178222827577893&sdata=Ceo34WkrObnJO0jOyvF7y8SLeJMDQ36AosbwDOlosb4%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
