Yes, I am hopeful we can move forward from here (probably with some bug fixes).
Thanks, -Alex On 4/17/18, 1:21 AM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote: >Hi Alex, >if it works for this components I think it should be ok. Anyway if I find >some problems we can comment at that moments. Don't think so. > >So, I can assume that you end this work and I can try to work from that? > >thanks > > > >2018-04-17 10:01 GMT+02:00 Alex Harui <[email protected]>: > >> I integrated the same pattern in Jewel's Button, CheckBox, RadioButton >>and >> Slider. This indicates that it can be implemented in a common base >>class >> for these components. The example looks ok to me. >> >> The code assumes positioner. For Button, if there is no hierarchy, then >> positioner and element should be the same so it should work. If it >>turns >> out there are still going to be exceptions that don't work, then we >>might >> need to introduce a "styleTarget" property in the Jewel base class that >> createElement can assign and ClassSelectorList will use instead of >> positioner. >> >> HTH, >> -Alex >> >> On 4/16/18, 9:46 AM, "[email protected] on behalf of Carlos >>Rovira" >> <[email protected] on behalf of [email protected]> wrote: >> >> >Hi Alex, >> > >> >for me is ok to have it in JewelUIBase, >> >in the other hand to look at what I tried to say with "positioner" vs >> >"element" to apply class selectors, take a look at Jewel CheckBox (that >> >will be refactored to extend JewelUIBase instead of current Basic >> >CheckBox, >> >like the rest of components). In create element the element in an input >> >and >> >the positioner is a label so setClassName is overriden to apply styles >>to >> >positioner >> > >> >COMPILE::JS >> > override protected function setClassName(value:String):void >> > { >> > addStyles(positioner, value); >> > } >> > >> >in contrast Button will be using element instead since there's no >>wrapper. >> >Button is its own wrapper >> > >> >thanks >> > >> > >> >2018-04-16 18:27 GMT+02:00 Alex Harui <[email protected]>: >> > >> >> Hi Carlos, >> >> >> >> Again, let's be specific and not over-state the scenarios. I do not >> >> believe that absolutely all JS development is focused on class >> >>selectors, >> >> otherwise there would be more articles about that practice. And, >>while >> >>I >> >> don't doubt that the "setting properties that affect visuals" might >>need >> >> to access elements instead of just the positioner, I would expect the >> >> component to be an abstraction to the developer so when they choose >>"a >> >>set >> >> of groups of styles" it would always apply to the positioner. They >> >>should >> >> not have to know the internal "sub-DOM" of the component. >> >> >> >> After thinking about it more, I agree with Piotr that >>ClassListSelector >> >> should not be baked into UIBase. Your recommendation that it should >>be >> >> implies that you are still thinking in the Flex mindset. In Royale, >> >>PAYG >> >> is an important principle, and your arguments below basically >>describe >> >> "just-in-case" which is not PAYG. It might be that a JewelUIBase >>would >> >> integrate ClassListSelector. I will try to code that up today so we >>can >> >> see how that feels. >> >> >> >> Royale does want to make things easy, but, IMO, PAYG is more >>important >> >> than easy. Flex put easy as more important than PAYG, and while that >> >> might have helped Flex gain popularity more quickly, in the end, Flex >> >> began having size and performance problems. I do not want to repeat >> >>that >> >> mistake with Royale. It doesn't matter how easy it is to get >>started if >> >> you can't finish. There has to be the right balance. >> >> >> >> My 2 cents, >> >> -Alex >> >> >> >> On 4/16/18, 4:33 AM, "[email protected] on behalf of Carlos >> >>Rovira" >> >> <[email protected] on behalf of [email protected]> wrote: >> >> >> >> >Hi, >> >> > >> >> >ClassListSelector could be ok, but think that depending on the >> >>components >> >> >in both MDL and JEWEL the class selector names added/removed/toggled >> >>could >> >> >go to positioner or to element. There's various examples of this in >> >>each >> >> >library. We should not lost that capability since is key. >> >> > >> >> >In order to bake in UIBase, my opinion is that devs will use this a >> >>lot in >> >> >their apps, so for me I'm ok to have it. >> >> >If it was an API partially used, I'd think about it, but actual JS >> >> >development is so much focused in add/remove class selectors. >> >> > >> >> >I'll be waiting for the final touches >> >> > >> >> >thanks Alex for working on this, and sorry if I'm a bit focused but >>I >> >> >think >> >> >this point is important since in Royale we try to make easy things >>and >> >> >encapsulate best practices and code, and this seems to me something >> >>that >> >> >people will use in library APIs and in final Apps >> >> > >> >> >thanks >> >> > >> >> > >> >> > >> >> >2018-04-16 10:18 GMT+02:00 Piotr Zarzycki >><[email protected]>: >> >> > >> >> >> If I could decide - that class should be used as an util outside >> >>UIBase. >> >> >> UIBase should be as much technology agnostic as we can. However >>how >> >>to >> >> >>use >> >> >> that class outside ? >> >> >> >> >> >> Thanks, >> >> >> Piotr >> >> >> >> >> >> 2018-04-16 10:08 GMT+02:00 Alex Harui <[email protected]>: >> >> >> >> >> >> > Hi Carlos, >> >> >> > >> >> >> > I'm running out of ways to try to explain this one concept. >> >>Here's my >> >> >> > next attempt: I think you are too focused on the underlying >> >>browser >> >> >> > implementation. Conceptually, the application developer is >> >>"setting >> >> >> > properties to affect visuals" or "choosing sets of groups of >> >>styles at >> >> >> > runtime". That is the abstraction/APIs Royale needs to present. >> >>It >> >> >>has >> >> >> > nothing to do with className/classList. If we ever target some >> >>other >> >> >> > runtime, for example, native C code, or even in the SWF >> >> >>implementations, >> >> >> > there may not be any className/classList in the runtime and the >> >> >>runtime >> >> >> > implementation should only have to implement the APIs we >>present, >> >>and >> >> >>not >> >> >> > emulate the browser's className/classList. >> >> >> > >> >> >> > Thus, the APIs we present should be things like "primary", >> >> >>"secondary", >> >> >> > "emphasized" as "properties that affect visuals", and addStyles, >> >> >> > removeStyles, toggleStyles for "choosing sets of groups of >>styles". >> >> >>But >> >> >> > addStyles, removeStyles, and toggleStyles should not take an >> >> >>HTMLElement >> >> >> > as a parameter, but rather, an IUIBase. The key question here >>is >> >> >>whether >> >> >> > the JS implementation can always assume that the styles get >> >>applied to >> >> >> the >> >> >> > positioner which may not be the same as the element. I think >>the >> >> >>answer >> >> >> > is yes. >> >> >> > >> >> >> > Then we have another option, which is to say that there is "an >> >>initial >> >> >> set >> >> >> > of styles". That's our MXML className property. We are not >> >> >>obligated to >> >> >> > allow it to be changed at runtime since we have the other APIs >>nor >> >> >>are we >> >> >> > obligated to keep it in sync with the properties we use in the >>JS >> >> >> > implementation. Note that Royale className and HTMLElement >> >>className >> >> >>has >> >> >> > never been kept in sync even in Basic because we add typeNames. >> >> >> > >> >> >> > I think with that set of 3 categories, there isn't really a need >> >>for >> >> >> folks >> >> >> > to have to "totally reset the initial set of styles", which >>implies >> >> >> > setting MXML className at runtime, or if there is a small >>amount of >> >> >>code >> >> >> > to do it but it is computationally expensive, that may be >> >>acceptable. >> >> >> I >> >> >> > think "totally resetting" is a rare occurrence and the "choosing >> >> >>sets" is >> >> >> > a sufficient API. >> >> >> > >> >> >> > I spent this evening trying a different implementation, but >>found >> >>out >> >> >> that >> >> >> > classList isn't backed by the kind of data structure I thought >>it >> >> >>had. I >> >> >> > was hoping that toggle disabled entries instead of removing >>them. >> >> >>I've >> >> >> > pushed a first cut at another way of managing the list of >>classes >> >>by >> >> >> > trying to track the indexes in the classList set by the >>classname. >> >> >>See >> >> >> > ClassSelectorList.as. I haven't wired it up yet to Jewel. I'm >> >> >>pondering >> >> >> > whether it could go in UIBase. >> >> >> > >> >> >> > Thoughts? >> >> >> > -Alex >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > On 4/15/18, 4:01 AM, "[email protected] on behalf of >>Carlos >> >> >> Rovira" >> >> >> > <[email protected] on behalf of [email protected]> >> >>wrote: >> >> >> > >> >> >> > >Hi Alex, >> >> >> > > >> >> >> > >app devs will create logic that will use our encapsulated code >> >>(i.e: >> >> >> > >setting primary to true or false). Jewel as MDL has properties >> >>that >> >> >>uses >> >> >> > >to >> >> >> > >deal with true/false values to make it easy for the user to >> >>change a >> >> >> > >style. >> >> >> > >Under the hood, that is changing the "element.class" or >> >> >> > >"positioner.class". >> >> >> > >I think component's royale className property should be updated >> >>and >> >> >>not >> >> >> > >remain dirty since that would create lots of confusion for our >> >> >>users. If >> >> >> > >we >> >> >> > >do that folks should never operate again with "className", >>maybe >> >>it >> >> >> could >> >> >> > >not be a problem, although left className in a non valid state >> >>sound >> >> >> > >strange to me. If you think it can work, we can try it and see >> >>what >> >> >> > >happen... but seems to me that maybe we're making thing very >> >>complex >> >> >> when >> >> >> > >all could be more straight lined. Anyway, I'll wait for your >> >>changes. >> >> >> > >Thanks! >> >> >> > > >> >> >> > >Carlos >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > >2018-04-15 8:49 GMT+02:00 Alex Harui >><[email protected]>: >> >> >> > > >> >> >> > >> IMO, Carlos still isn't understanding my point. My point is >> >>that >> >> >>the >> >> >> > >>app >> >> >> > >> devs will not need to be setting className. They will be >> >>setting >> >> >> > >> properties like "emphasized", "secondary" and "primary" that >> >>can do >> >> >> > >> whatever it wants under the covers, and if we assume that >>folks >> >> >>will >> >> >> not >> >> >> > >> set (or are not supposed to set) className after init time, >> >>there >> >> >>are >> >> >> > >>much >> >> >> > >> simpler ways to handle this situation. >> >> >> > >> >> >> >> > >> That said, I have another idea about how to allow >>"emphasized", >> >> >> > >> "secondary" and "primary" to use classList that might be >>simpler >> >> >>that >> >> >> > >>what >> >> >> > >> I have committed so far. I will try to code it up tomorrow >>for >> >> >>others >> >> >> > >>to >> >> >> > >> look at. >> >> >> > >> >> >> >> > >> Thanks, >> >> >> > >> -Alex >> >> >> > >> >> >> >> > >> On 4/14/18, 9:24 AM, "Piotr Zarzycki" >> >><[email protected]> >> >> >> > wrote: >> >> >> > >> >> >> >> > >> >Are you saying that it will work with your implementation >>and >> >>not >> >> >> with >> >> >> > >> >Alex's? >> >> >> > >> > >> >> >> > >> >Actually as a app developer above situation is very rare. >> >> >> > >> > >> >> >> > >> >Thanks, >> >> >> > >> >Piotr >> >> >> > >> > >> >> >> > >> >On Sat, Apr 14, 2018, 5:24 PM Carlos Rovira >> >> >><[email protected] >> >> >> > >> >> >> > >> >wrote: >> >> >> > >> > >> >> >> > >> >> That's what Alex want. To make className only used at init >> >>time >> >> >> then >> >> >> > >>we >> >> >> > >> >> should use classList methods. >> >> >> > >> >> I think that the premises are not right, since Alex thinks >> >>devs >> >> >> will >> >> >> > >>not >> >> >> > >> >> make heavy use of switching class selectors at runtime (at >> >>init >> >> >> time >> >> >> > >>and >> >> >> > >> >> later while using the app). MDL and Jewel are constantly >> >>setting >> >> >> and >> >> >> > >> >> removing class selectors from elements and positioners, so >> >> >> className >> >> >> > >> >>(set >> >> >> > >> >> only once at init time) is not right for use, but for >>people >> >> >>using >> >> >> > >> >>Basic. >> >> >> > >> >> Hence, Basic should remain with className, and MDL/Jewel >> >>should >> >> >>go >> >> >> > >> >> classList *always* (shadowing it so will have a royale >>API to >> >> >>work >> >> >> > >>with >> >> >> > >> >>SWF >> >> >> > >> >> and JS and in JS compilation use classList >> >> >> > >> >> >> >> >> > >> >> 2018-04-14 14:24 GMT+02:00 Piotr Zarzycki >> >> >> > >><[email protected]>: >> >> >> > >> >> >> >> >> > >> >> > Carlos, >> >> >> > >> >> > >> >> >> > >> >> > Are you saying here having your idea: >> >> >> > >> >> > >> >> >> > >> >> > " >> >> >> > >> >> > 1) I think people have the APIs (className and >>classList) >> >>and >> >> >> > >> >>can/will do >> >> >> > >> >> > what they want, although we say "use className only at >>init >> >> >> time". >> >> >> > >> >> > " >> >> >> > >> >> > >> >> >> > >> >> > If I do following things: >> >> >> > >> >> > >> >> >> > >> >> > <Component id="comp" className="myClass"/> >> >> >> > >> >> > >> >> >> > >> >> > And later in the code I do: >> >> >> > >> >> > >> >> >> > >> >> > comp.className = "myOtherClass"; >> >> >> > >> >> > >> >> >> > >> >> > It won't work? >> >> >> > >> >> > >> >> >> > >> >> > Piotr >> >> >> > >> >> > >> >> >> > >> >> > >> >> >> > >> >> > On Sat, Apr 14, 2018, 11:48 AM Carlos Rovira >> >> >> > >><[email protected] >> >> >> > >> > >> >> >> > >> >> > wrote: >> >> >> > >> >> > >> >> >> > >> >> > > Alex >> >> >> > >> >> > > >> >> >> > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui >> >> >><[email protected] >> >> >> >: >> >> >> > >> >> > > >> >> >> > >> >> > > > Carlos, >> >> >> > >> >> > > > >> >> >> > >> >> > > > It seems like either you have missed some of the >> >> >>discussion >> >> >> or >> >> >> > >> >>maybe >> >> >> > >> >> we >> >> >> > >> >> > > > weren't clear enough. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > I think most of what you say was considered but let's >>go >> >>for >> >> >> > >>parts: >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > Simply put: >> >> >> > >> >> > > > -The Basic components do not need to handle >>classList >> >> >>APIs. >> >> >> > >> >>There is >> >> >> > >> >> > no >> >> >> > >> >> > > > expectation that classes will be frequently added >>and >> >> >> removed. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > That's ok. Basic no, Jewel yes. That's huge diference, >> >>so I >> >> >> > >>think as >> >> >> > >> >> you >> >> >> > >> >> > > UIBase should go to Core and be as is now (or make the >> >> >>changes >> >> >> > >>you >> >> >> > >> >> > > estimate) >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > -The goal of most component sets in Royale is to >> >>abstract >> >> >> away >> >> >> > >>the >> >> >> > >> >> > > > underlying platform APIs. That's why I'm not in >>favor >> >>of >> >> >> > >>having a >> >> >> > >> >> > > > classList API on UIBase. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > Right, classList is JS only so maybe an API in >> >>JewelUIBase >> >> >> > >>should be >> >> >> > >> >> > > general and use the JS code with COMPILE::JS >> >> >> > >> >> > > then implement others. >> >> >> > >> >> > > >> >> >> > >> >> > > -MXML is better with space delimited string lists >> >>instead of >> >> >> > >>arrays. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > I think in you version and my version is a string, >>but in >> >> >>mine >> >> >> > >>then >> >> >> > >> >>is >> >> >> > >> >> > > converted to feed classList >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > -It doesn't make sense to split strings into an >>array >> >>in >> >> >>JS >> >> >> > >>when >> >> >> > >> >>the >> >> >> > >> >> > > > browser clearly can do it. >> >> >> > >> >> > > > -This perf test shows className is faster [1] >> >> >> > >> >> > > > -So does this one [2] >> >> >> > >> >> > > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > We are starting from a list of strings. MDL is not. >> >>And >> >> >> that >> >> >> > >> >>makes >> >> >> > >> >> a >> >> >> > >> >> > > > difference, IMO. >> >> >> > >> >> > > > >> >> >> > >> >> > > > >> >> >> > >> >> > > ok in Jewel we could do in that way, the main >>difference >> >> >>with >> >> >> > >>Basic >> >> >> > >> >>is >> >> >> > >> >> > that >> >> >> > >> >> > > the main task of this kind of set is >> >> >> > >> >> > > heavily deal with class selectors so for Jewel (not >>for >> >> >>Basic) >> >> >> we >> >> >> > >> >> should >> >> >> > >> >> > > focus on it what means to me be fundamental part of >> >> >>JewelUIBase >> >> >> > >>to >> >> >> > >> >>have >> >> >> > >> >> > an >> >> >> > >> >> > > API to deal with styles in all platforms and that all >> >> >> components >> >> >> > >> >> > extending >> >> >> > >> >> > > it can use. >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > I forgot to mention earlier that I was not happy >>that >> >> >> addStyles >> >> >> > >> >>and >> >> >> > >> >> > > > friends were JS-only. It would have been better if >>it >> >>did >> >> >> not >> >> >> > >> >>take >> >> >> > >> >> an >> >> >> > >> >> > > > element since that is a JS platform implementation. >> >>That >> >> >>way >> >> >> > >> >> > application >> >> >> > >> >> > > > developers could use addStyles and friends to >> >>manipulate >> >> >>the >> >> >> > >>set >> >> >> > >> >>of >> >> >> > >> >> > class >> >> >> > >> >> > > > selectors at runtime. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > ok, that's a fail on my implementation that should be >> >>fixed >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > More comments in-line.. >> >> >> > >> >> > > > >> >> >> > >> >> > > > [1] >> >> >> > >> >> > > > >> >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> > >> https%3A%2F%2Fmeasuret >> >> >> > >> >>hat.net%2FBenchmarks%2FShow%2F54%2F0%2F&data=02%7C01% >> 7Caharui% >> >> >> > >> 40adobe.com >> >> >> > >> >> >> >>>>>>%7C18aef785013e484cfcf108d5a22445a7%7Cfa7b1b5a7b34438794aed2c178de >> >> >> > >> cee1%7C >> >> >> > >> >>0%7C0%7C636593199085882368&sdata=ya1hbY9%2FHxLCMbEh% >> >> >> > >> 2BVqXP0OdWrV03zEPRAtu >> >> >> > >> >>ybj223w%3D&reserved=0 >> >> >> > >> >> > > > classname-vs-setattribute-vs-c >> >> >> > >> >> > > > lasslist >> >> >> > >> >> > > > [2] >> >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> > >> https%3A%2F%2Fjsperf.c >> >> >> > >> >> >>>>om%2Fclassname-vs-classlist-showdown%2F5&data=02%7C01%7Caharui% >> >> >> > >> 40adobe.co >> >> >> > >> >> >> >>>>>>m%7C18aef785013e484cfcf108d5a22445a7%7Cfa7b1b5a7b34438794aed2c178de >> >> >> > >> cee1%7 >> >> >> > >> >>C0%7C0%7C636593199085882368&sdata= >> ygYm8sTMDTniu1NFzxds3fEaa0e% >> >> >> > >> 2FxnNaYxHeO >> >> >> > >> >>6G3F0g%3D&reserved=0 >> >> >> > >> >> > > > >> >> >> > >> >> > > > On 4/13/18, 7:18 PM, "[email protected] on >> behalf >> >> of >> >> >> > >>Carlos >> >> >> > >> >> > > Rovira" >> >> >> > >> >> > > > <[email protected] on behalf of >> >> >> [email protected]> >> >> >> > >> >> wrote: >> >> >> > >> >> > > > >> >> >> > >> >> > > > >Hi, >> >> >> > >> >> > > > > >> >> >> > >> >> > > > >I think the discussion now should center in >>numbers. >> >> >> > >> >> > > > > >> >> >> > >> >> > > > >I added "performance.now()" to typedefs (how could >>we >> >> >>live >> >> >> > >> >>without >> >> >> > >> >> > this >> >> >> > >> >> > > > >until now? :)) >> >> >> > >> >> > > > >> >> >> > >> >> > > > Snip... >> >> >> > >> >> > > > > >> >> >> > >> >> > > > > >> >> >> > >> >> > > > >I think numbers are near identical right? >> >> >> > >> >> > > > > >> >> >> > >> >> > > > > >> >> >> > >> >> > > > >So given very close numbers should make us choose >>the >> >> >>more >> >> >> > >> >>simplest >> >> >> > >> >> > code >> >> >> > >> >> > > > > >> >> >> > >> >> > > > > >> >> >> > >> >> > > > >right? >> >> >> > >> >> > > > > >> >> >> > >> >> > > > No. Small samples are often not useful. These >>kinds >> >>of >> >> >> > >>arguments >> >> >> > >> >> are >> >> >> > >> >> > > the >> >> >> > >> >> > > > ones that led to UIComponent being 13,000 lines in >> >>Flex. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > I think here we are talking about performance, not >>about >> >>to >> >> >> > >>increase >> >> >> > >> >> > number >> >> >> > >> >> > > of lines of code >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > > >> >> >> > >> >> > > > > >> >> >> > >> >> > > > >2018-04-14 2:58 GMT+02:00 Carlos Rovira >> >> >> > >> >><[email protected]>: >> >> >> > >> >> > > > > >> >> >> > >> >> > > > >> Hi Alex, >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> just studied you changes and want to ask you a >>few >> >> >>things: >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> 1) Why className and classLists methods must >>remain >> >> >> > >>unsynced? I >> >> >> > >> >> > think >> >> >> > >> >> > > > >>this >> >> >> > >> >> > > > >> is not necessary and seems to me a bit unnatural >> >>since >> >> >> when >> >> >> > >>I >> >> >> > >> >>add >> >> >> > >> >> > > styles >> >> >> > >> >> > > > >> though classList in a element this makes the >> >>internal >> >> >>list >> >> >> > >> >> changed, >> >> >> > >> >> > > and >> >> >> > >> >> > > > >>if >> >> >> > >> >> > > > >> I then do "trace(element.className)" it will >>report >> >>the >> >> >> > >>updated >> >> >> > >> >> > > > >>list...so I >> >> >> > >> >> > > > >> think both are synced by default >> >> >> > >> >> > > > >> >> >> > >> >> > > > I proposed a way to have components that want to use >> >> >> classList >> >> >> > >>pay >> >> >> > >> >> for >> >> >> > >> >> > > it. >> >> >> > >> >> > > > If you want to further penalize those components in >> >> >>order to >> >> >> > >> >> maintain >> >> >> > >> >> > > > synchronization of classList and className go ahead >>as >> >> >>long >> >> >> as >> >> >> > >>it >> >> >> > >> >> > doesn't >> >> >> > >> >> > > > impact org.apache.flex.core.UIBase. Yes, the >>browser >> >> >>keeps >> >> >> > >> >>className >> >> >> > >> >> > and >> >> >> > >> >> > > > classList in sync, but you are missing that the >> >> >>emphasized, >> >> >> > >> >>primary >> >> >> > >> >> and >> >> >> > >> >> > > > secondary selectors are not in the className list >> >> >>maintained >> >> >> by >> >> >> > >> >> UIBase >> >> >> > >> >> > > and >> >> >> > >> >> > > > there is additional cost to doing so. >> >> >> > >> >> > > > >> >> >> > >> >> > > > >> >> >> > >> >> > > That's because when I refactored the code when you >>ask me >> >> >>to do >> >> >> > >>so I >> >> >> > >> >> > tried >> >> >> > >> >> > > to make it >> >> >> > >> >> > > className dependent. I think the solution is in >> >>JewelUIBase >> >> >> wire >> >> >> > >>all >> >> >> > >> >> > > through classList. >> >> >> > >> >> > > we'll have a tiny performance hit, that's right, but I >> >> >>think a >> >> >> > >>uiset >> >> >> > >> >> with >> >> >> > >> >> > > the purpose of Jewel >> >> >> > >> >> > > (theming - styling - goof looking) is the price that >> >>have to >> >> >> > >>pay. a >> >> >> > >> >> > little >> >> >> > >> >> > > less performance than Basic >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> 2) Now Button has two new methods that must make >> >> >>various >> >> >> > >> >> operations >> >> >> > >> >> > > with >> >> >> > >> >> > > > >> arrays (join, push, splice...), this means in >>almost >> >> >>all >> >> >> > >>jewel >> >> >> > >> >> > > > >>components >> >> >> > >> >> > > > >> override at least computeFinalClassNames and >>insert >> >>new >> >> >> > >>custom >> >> >> > >> >> > methods >> >> >> > >> >> > > > >>for >> >> >> > >> >> > > > >> add/toggle/remove and each one will make various >> >> >> > >>operations: in >> >> >> > >> >> the >> >> >> > >> >> > > > >>case of >> >> >> > >> >> > > > >> toggle will do a push or splice and then the >>normal >> >> >> > >>classList >> >> >> > >> >> toggle >> >> >> > >> >> > > > >> operation. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > It is probably possible to package up the code I >>added >> >>to >> >> >> Jewel >> >> >> > >> >> Button >> >> >> > >> >> > > and >> >> >> > >> >> > > > make it re-usable without inserting a base class for >> >>all >> >> >>of >> >> >> > >>Jewel. >> >> >> > >> >> Or >> >> >> > >> >> > is >> >> >> > >> >> > > > absolutely every Jewel component going to need that >> >>code? >> >> >> If >> >> >> > >>so, >> >> >> > >> >> then >> >> >> > >> >> > > > maybe a common base class for all of Jewel makes >>sense. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > Yes, all components in Jewel is doing/will do heavy >>use >> >>of >> >> >> style >> >> >> > >> >>API, >> >> >> > >> >> so >> >> >> > >> >> > is >> >> >> > >> >> > > a must >> >> >> > >> >> > > in this set to have that api (while it's not in UIBase >> >>and >> >> >> Basic) >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > Also, the code I added to Jewel Button is can be >> >>greatly >> >> >> > >> >>simplified >> >> >> > >> >> if >> >> >> > >> >> > > you >> >> >> > >> >> > > > assume folks will not directly set className after >> >>adding >> >> >>to >> >> >> > >> >>parent. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > No, as MDL, this kind of components are based on >>heavily >> >>add >> >> >> and >> >> >> > >> >> removal >> >> >> > >> >> > of >> >> >> > >> >> > > class selectors >> >> >> > >> >> > > users will pushing buttons, clicking checkboxes, and >> >>more, >> >> >>and >> >> >> > >>part >> >> >> > >> >>of >> >> >> > >> >> > that >> >> >> > >> >> > > actions will be to add/remove/toggle >> >> >> > >> >> > > class selectors in one or more components. >> >> >> > >> >> > > >> >> >> > >> >> > > That's what MDL does, that what Jewel does, and that's >> >>what >> >> >>any >> >> >> > >> >>actual >> >> >> > >> >> UI >> >> >> > >> >> > > set with focus on visuals will do >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > >> 3) we are introducing a new array property per >> >> >>component >> >> >> to >> >> >> > >> >>store >> >> >> > >> >> > what >> >> >> > >> >> > > > >> classList already do >> >> >> > >> >> > > > >> >> >> > >> >> > > > No, the array does not have to have as many >>elements as >> >> >>the >> >> >> > >> >> classList. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> So for me we are introducing lots of complexity, >> >>with >> >> >>more >> >> >> > >>code >> >> >> > >> >> > > splitter >> >> >> > >> >> > > > >> in every class, each one with more operations of >> >>array >> >> >> > >> >>operations >> >> >> > >> >> > that >> >> >> > >> >> > > > >> finaly makes the same call I did. And generating >> >> >> complexity >> >> >> > >> >>since >> >> >> > >> >> > > > >>className >> >> >> > >> >> > > > >> should be used by users only at init time and >>then >> >>use >> >> >>the >> >> >> > >> >>rest of >> >> >> > >> >> > > > >> classList apis... >> >> >> > >> >> > > > >> >> >> > >> >> > > > That's PAYG. The classes that need it get the >> >>additional >> >> >> > >> >>complexity. >> >> >> > >> >> > > And >> >> >> > >> >> > > > again, if we want to restrict setting classname >>after >> >> >>init in >> >> >> > >> >>Jewel, >> >> >> > >> >> > > > that's totally fine with me and will simplify the >>code. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > The classes that need get the additional complexity, >>but >> >>at >> >> >> > >>least we >> >> >> > >> >> need >> >> >> > >> >> > > to >> >> >> > >> >> > > proxy all that in JewelUIBase since *all* Jewel >> >>components >> >> >>will >> >> >> > >>use >> >> >> > >> >>the >> >> >> > >> >> > > same code >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> The only difference for me is that you want to >>avoid >> >> >>the >> >> >> > >> >>classList >> >> >> > >> >> > > > >>initial >> >> >> > >> >> > > > >> add method that in most of the cases will add >>from 1 >> >> >>or 2 >> >> >> > >> >>classes >> >> >> > >> >> > and >> >> >> > >> >> > > > >>up to >> >> >> > >> >> > > > >> 3-4-5. I think normal components would have 3 on >> >> >> average... >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> This related to lots of sites saying "use >>classList >> >> >> instead >> >> >> > >>of >> >> >> > >> >> > > > >>className" >> >> >> > >> >> > > > >> and frameworks like MDL that are based only on >> >> >>classList , >> >> >> > >>and >> >> >> > >> >>all >> >> >> > >> >> > > > >>jsperfs >> >> >> > >> >> > > > >> (that although are not reflecting our concrete >>use >> >>case >> >> >> and >> >> >> > >> >>use of >> >> >> > >> >> > > > >> classList, I think are completely valid on >>essence) >> >> >>makes >> >> >> me >> >> >> > >> >>think >> >> >> > >> >> > > about >> >> >> > >> >> > > > >> how we have such different visions. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> So I must to say that as much as I want to see >>the >> >> >> > >>advantages >> >> >> > >> >>the >> >> >> > >> >> > > > >> approaches do not convince me... >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> for me is more simple that all of that. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> 1) I think people have the APIs (className and >> >> >>classList) >> >> >> > >>and >> >> >> > >> >> > can/will >> >> >> > >> >> > > > >>do >> >> >> > >> >> > > > >> what they want, although we say "use className >>only >> >>at >> >> >> init >> >> >> > >> >>time". >> >> >> > >> >> > > > >> >> >> > >> >> > > > Again, we are abstracting the underlying >> >>implementation of >> >> >> how >> >> >> > >>to >> >> >> > >> >>set >> >> >> > >> >> > > > class selectors in most Royale component sets. That >> >>way, >> >> >>if >> >> >> we >> >> >> > >> >>want >> >> >> > >> >> to >> >> >> > >> >> > > > target other output we have fewer APIs to reproduce. >> >>We >> >> >>only >> >> >> > >> >>need to >> >> >> > >> >> > > > reproduce the conceptual APIs. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> 2) I think we should have the most easy way to >> >>modify >> >> >> since >> >> >> > >> >> browsers >> >> >> > >> >> > > are >> >> >> > >> >> > > > >> takin care of internal apis performance (or at >>least >> >> >>I'm >> >> >> > >> >>confident >> >> >> > >> >> > > with >> >> >> > >> >> > > > >> that, like I was confident on flash player >> >>performance) >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> 3) I don't like to introduce lots of code when >>maybe >> >> >>the >> >> >> > >>basic >> >> >> > >> >> usage >> >> >> > >> >> > > of >> >> >> > >> >> > > > >> classList can be even more efficient. I give >>various >> >> >> jsperf >> >> >> > >> >> studies >> >> >> > >> >> > > out >> >> >> > >> >> > > > >> there but both Harbs and you didn't show me >>anyone >> >>that >> >> >> > >>shows >> >> >> > >> >> > > className >> >> >> > >> >> > > > >>as >> >> >> > >> >> > > > >> a better option. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> 4) If we are introducing such complexity, >>wouldn't >> >>be >> >> >> > >>better to >> >> >> > >> >> > remove >> >> >> > >> >> > > > >> completely classList and end that code with the >>new >> >> >>array >> >> >> > >> >>property >> >> >> > >> >> > and >> >> >> > >> >> > > > >> array operations? I think it will be more >>performant >> >> >>and >> >> >> > >>will >> >> >> > >> >> remove >> >> >> > >> >> > > > >> complexity. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> 5) If I use that solution for jewel, I should >> >>introduce >> >> >> some >> >> >> > >> >> > > > >>intermediate >> >> >> > >> >> > > > >> class between UIBase and a Jewel Component where >>I >> >>can >> >> >> proxy >> >> >> > >> >>all >> >> >> > >> >> > that >> >> >> > >> >> > > > >> methods that are now in button to avoid >>replicate in >> >> >>all >> >> >> > >>jewel >> >> >> > >> >> > > > >>components. >> >> >> > >> >> > > > >> And by doing that, as I said before, I'll prefer >>to >> >> >>remove >> >> >> > >>that >> >> >> > >> >> > > > >>complexity >> >> >> > >> >> > > > >> and go for simple classList manipulation since is >> >>the >> >> >>same >> >> >> > >>that >> >> >> > >> >> MDL >> >> >> > >> >> > > (to >> >> >> > >> >> > > > >> name a concrete and successful project that >>renders >> >>and >> >> >> > >> >>performs >> >> >> > >> >> > > > >> magnificent) does [1] (I put button example just >>as >> >>an >> >> >> > >>example >> >> >> > >> >> since >> >> >> > >> >> > > > >> there's lots more) >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> Sincerily, I'm not convinced with the results >> >>exposed >> >> >> here, >> >> >> > >> >>and I >> >> >> > >> >> > was >> >> >> > >> >> > > > >> always thinking that I was not seeing something >> >> >>evident, >> >> >> but >> >> >> > >> >>now >> >> >> > >> >> I'm >> >> >> > >> >> > > > >>even >> >> >> > >> >> > > > >> more convinced that we should use classList >>without >> >>any >> >> >> > >> >>rejection. >> >> >> > >> >> > > Even >> >> >> > >> >> > > > >>for >> >> >> > >> >> > > > >> the use of className in MXML, is ok since I >>proved >> >>you >> >> >>can >> >> >> > >> >> transform >> >> >> > >> >> > > it >> >> >> > >> >> > > > >> without problem getting the string, splitting and >> >> >> > >>introducing >> >> >> > >> >>in >> >> >> > >> >> the >> >> >> > >> >> > > > >> classList, and then opertating with is when >>needed >> >> >>without >> >> >> > >>any >> >> >> > >> >> > > > >>performance >> >> >> > >> >> > > > >> significant problem. For me is more problematic >>all >> >>the >> >> >> > >>code we >> >> >> > >> >> want >> >> >> > >> >> > > to >> >> >> > >> >> > > > >> introduce to avoid possible performance problems >> >>that I >> >> >> and >> >> >> > >> >>many >> >> >> > >> >> > > others >> >> >> > >> >> > > > >> don't see and that main web projects actually >>don't >> >>see >> >> >> and >> >> >> > >>are >> >> >> > >> >> used >> >> >> > >> >> > > all >> >> >> > >> >> > > > >> over the web. We should not be different in >> >>something >> >> >>that >> >> >> > >> >>other >> >> >> > >> >> has >> >> >> > >> >> > > > >> already adopted, and if people is using it, is >> >>because >> >> >>the >> >> >> > >> >> browsers, >> >> >> > >> >> > > the >> >> >> > >> >> > > > >> standards and all the web wants all people using >>it, >> >> >>and >> >> >> for >> >> >> > >> >>me is >> >> >> > >> >> > > what >> >> >> > >> >> > > > >> happen with classList. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> in resume. I still don't want to make this >> >>discussion >> >> >> > >>longer. I >> >> >> > >> >> > think >> >> >> > >> >> > > we >> >> >> > >> >> > > > >> have different opinions on this particular >>subject >> >>and >> >> >>the >> >> >> > >> >> greatness >> >> >> > >> >> > > of >> >> >> > >> >> > > > >> royale is that it doesn't mind since if you and >> >>Harbs >> >> >>are >> >> >> > >> >>betting >> >> >> > >> >> > for >> >> >> > >> >> > > > >> className, we can remain Basic with the initial >>use >> >>(or >> >> >> the >> >> >> > >> >> current >> >> >> > >> >> > > > >>one). >> >> >> > >> >> > > > >> For Jewel, I can bet for the same method MDL uses >> >>with >> >> >> > >> >>classList >> >> >> > >> >> and >> >> >> > >> >> > > as >> >> >> > >> >> > > > >>I >> >> >> > >> >> > > > >> must to refactor half of the Jewel components to >> >>extend >> >> >> from >> >> >> > >> >> UIBase >> >> >> > >> >> > > > >> directly instead of Basic components >>counterparts, I >> >> >>can >> >> >> > >>put a >> >> >> > >> >> > > > >>JewelUIBase >> >> >> > >> >> > > > >> piece between that uses classList in the way >>Jewel >> >> >>need. >> >> >> In >> >> >> > >> >>fact >> >> >> > >> >> > > Jewel, >> >> >> > >> >> > > > >>and >> >> >> > >> >> > > > >> any of the modern UI sets (Semantic, MDL, >>Bootstrap, >> >> >>...) >> >> >> > >> >>depends >> >> >> > >> >> > > > >>heavily >> >> >> > >> >> > > > >> in class selector assignation, hence the use of >> >> >>classList >> >> >> > >>as a >> >> >> > >> >> > general >> >> >> > >> >> > > > >> rule. So I think is natural to have this marked >> >> >> > >> >>differentiation, >> >> >> > >> >> > while >> >> >> > >> >> > > > >>in >> >> >> > >> >> > > > >> Basic we should not expect people wants to deal >>with >> >> >>class >> >> >> > >> >> selectors >> >> >> > >> >> > > in >> >> >> > >> >> > > > >>a >> >> >> > >> >> > > > >> heavy use. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> Maybe I can wrong, but sincerely, if so I can't >>see >> >> >>where, >> >> >> > >>but >> >> >> > >> >>I >> >> >> > >> >> > > firmly >> >> >> > >> >> > > > >> believe in that, and for me is a clear >>definition of >> >> >>Jewel >> >> >> > >> >>needs. >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> Thoughts? >> >> >> > >> >> > > > >> >> >> > >> >> > > > My proposal lets our MDL and Jewel components use >> >> >>classList >> >> >> > >> >>heavily >> >> >> > >> >> in >> >> >> > >> >> > a >> >> >> > >> >> > > > PAYG way. It can be simplified if we are going to >> >> >>restrict >> >> >> > >> >>setting >> >> >> > >> >> of >> >> >> > >> >> > > > className after adding to the DOM. If you want to >>see >> >> >>what >> >> >> the >> >> >> > >> >>code >> >> >> > >> >> > > looks >> >> >> > >> >> > > > like with that assumption try making the changes or >>I >> >> >>will do >> >> >> > >>it. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > Alex, I prefer you do this. My only requirements are: >> >> >> > >> >> > > >> >> >> > >> >> > > * Have a JewelUIBase instead of the same code in all >> >> >> components. >> >> >> > >> >> > > * As I said, className will not be untouched after >> >> >>addToParent. >> >> >> > >> >>That's >> >> >> > >> >> a >> >> >> > >> >> > > huge part in MDL and Jewel >> >> >> > >> >> > > both sets add/remove/toggle styles at runtime. So make >> >>the >> >> >> > >>changes >> >> >> > >> >> > > modifying that rule in your mind. >> >> >> > >> >> > > * Is critical for me that components extending doesn't >> >>have >> >> >>to >> >> >> > >>add >> >> >> > >> >>new >> >> >> > >> >> > > methods that should be abstracted >> >> >> > >> >> > > in JewelUIBase and we can use basic API calls since we >> >>are >> >> >> > >>talking >> >> >> > >> >> about >> >> >> > >> >> > > heavy use (or principal use) in >> >> >> > >> >> > > this kind of components set. >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > I think we have proof that className is faster for >> >>when we >> >> >> > >>want to >> >> >> > >> >> use >> >> >> > >> >> > it >> >> >> > >> >> > > > at init time. I would like to see if we can create >> >>APIs >> >> >>for >> >> >> > >> >> > manipulation >> >> >> > >> >> > > > the classList at runtime that isn't JS-only and >> >>asssumes >> >> >> there >> >> >> > >>is >> >> >> > >> >>an >> >> >> > >> >> > > > element so folks can use those APIs at runtime >>instead >> >> >>being >> >> >> > >> >>tempted >> >> >> > >> >> to >> >> >> > >> >> > > > change className. >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > I think that's the clue. While Basic makes all the >>duty >> >> >>before >> >> >> > >>add >> >> >> > >> >>to >> >> >> > >> >> > > parent, MDL and Jewel are constantly >> >> >> > >> >> > > adding, toggling and removing class selectors, that >>why >> >>we >> >> >>must >> >> >> > >>put >> >> >> > >> >>a >> >> >> > >> >> > clear >> >> >> > >> >> > > line between how UIBase works >> >> >> > >> >> > > (mainly like it's now) and how Jewel works (using >>heavy >> >>use >> >> >>of >> >> >> > >> >> classList >> >> >> > >> >> > > since is its nature, and 'll get rid completely of >> >>className >> >> >> use >> >> >> > >> >> > internaly) >> >> >> > >> >> > > >> >> >> > >> >> > > I hope we are reaching to something here. Could you >> >>change >> >> >>the >> >> >> > >> >> > > implementation taking into account the differences >> >>discussed >> >> >> > >>here? >> >> >> > >> >> > > >> >> >> > >> >> > > thanks >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > > >> >> >> > >> >> > > > My 2 cents, >> >> >> > >> >> > > > -Alex >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > >> >> >> >> > >> >> > > > > >> >> >> > >> >> > > > > >> >> >> > >> >> > > > >-- >> >> >> > >> >> > > > >Carlos Rovira >> >> >> > >> >> > > > >https://na01.safelinks.protection.outlook.com/?url= >> >> >> > >> >> > > > http%3A%2F%2Fabout.me%2 >> >> >> > >> >> > > > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> > >> >> > > > 7C9fbf7c0d5e994a9acb6008d5 >> >> >> > >> >> > > > >>>a1ae2520%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> > >> >> > > > 7C636592691687691520&s >> >> >> > >> >> > > > >data=TR5G34hZMVutbPgcwAzTtNlFR0mQb8 >> >> >> > quhoBewhsOnSc%3D&reserved=0 >> >> >> > >> >> > > > >> >> >> > >> >> > > > >> >> >> > >> >> > > >> >> >> > >> >> > > >> >> >> > >> >> > > -- >> >> >> > >> >> > > Carlos Rovira >> >> >> > >> >> > > >> >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> > >> http%3A%2F%2Fabout.me% >> >> >> > >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> > >> 7C18aef785013e484cfcf108 >> >> >> > >> >>d5a22445a7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> > >> 7C63659319908588236 >> >> >> > >> >>8&sdata=P5v3BoebWGUeMXAsP5j7rd0y4rcjYP >> >> gYGKsAptIcLSQ%3D&reserved=0 >> >> >> > >> >> > > >> >> >> > >> >> > >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> -- >> >> >> > >> >> Carlos Rovira >> >> >> > >> >> >> >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> > >> http%3A%2F%2Fabout.me% >> >> >> > >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> > >> 7C18aef785013e484cfcf108 >> >> >> > >> >>d5a22445a7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> > >> 7C63659319908588236 >> >> >> > >> >>8&sdata=P5v3BoebWGUeMXAsP5j7rd0y4rcjYP >> >> gYGKsAptIcLSQ%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% >> >> >> > 7Cf4e0ef1e27e8407606cd08d5 >> >> >> > >a2c057b6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> > 7C636593869391543673&s >> >> >> > >data=6DkfBSCL%2BBi9EhqUKaAcEbY%2FVLCy2My8bBKS67oohNQ%3D& >> reserved=0 >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Piotr Zarzycki >> >> >> >> >> >> Patreon: >> >> >>*https://na01.safelinks.protection.outlook.com/?url= >> >> https%3A%2F%2Fwww.pat >> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >> >> %7C93bcdf89489c >> >> >>42d6ee0d08d5a38df0c7%7Cfa7b1b5a7b34438794aed2c178de >> >> cee1%7C0%7C0%7C6365947 >> >> >>52523975728&sdata=4k1dL%2B5BAj4r3ibPhjdqKjt% >> >> 2BxrDIn6EComwUUIv1d1M%3D&rese >> >> >>rved=0 >> >> >> >> >> >><https://na01.safelinks.protection.outlook.com/?url= >> >> https%3A%2F%2Fwww.pat >> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >> >> %7C93bcdf89489c >> >> >>42d6ee0d08d5a38df0c7%7Cfa7b1b5a7b34438794aed2c178de >> >> cee1%7C0%7C0%7C6365947 >> >> >>52523975728&sdata=4k1dL%2B5BAj4r3ibPhjdqKjt% >> >> 2BxrDIn6EComwUUIv1d1M%3D&rese >> >> >>rved=0>* >> >> >> >> >> > >> >> > >> >> > >> >> >-- >> >> >Carlos Rovira >> >> >https://na01.safelinks.protection.outlook.com/?url= >> >> http%3A%2F%2Fabout.me%2 >> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> 7C93bcdf89489c42d6ee0d08d5 >> >> >a38df0c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> 7C636594752523975728&s >> >> >data=3PcAzDxMYbYeiZus1byoKtVDc%2FkCPjq1X6hj%2BJm62Y4%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% >> 7C5a6cdf9a44824bf9426608d5 >> >a3b9aed9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> 7C636594940261497954&s >> >data=%2BTahOv1SHSBPV%2B0DZDw1b7u3gbApLDhLA8VyB%2BKkog0%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%7C5c9756d31105451f78fe08d5 >a43c502d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636595501366297874&s >data=RWdRNOiiobLaD934oJaOJszUj5LTYnfZBUnAxCvK90A%3D&reserved=0
