Sounds like we are mostly in agreement. I've clipped everything we've agreed to out of the reply below.
On 3/14/18, 9:41 AM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote: > > >> C) In MDL and Jewel, computeFInalClassNames is overridden to also >>combine >> any special properties like "fab" and "primary" >> >If we can I prefer not to need overrides Overrides are PAYG as the subclass that needs it implements the extra code. > >> D) Setters for special properties like "fab" check for (parent != null) >> and if parented, can call element.classList.toggle >> >here to adhere to what you propose, we should have : >1) or a composed class that hides implementation (className or classList) >2) use className if you want but give APIs to add/remove/... IMO, className in UIBase (and Royale in general) should look to the app dev like HTML className. A simple set of space-delimited strings. What we do in UIBase under the covers is the infrastructure we need (adding typeNames, maybe other strings for "fab"). I believe many apps can be built with simple use of className, so all add/remove support should be external and not baked in. > >> >> For PAYG, documentation, cross-platform, >> and MXML reasons, I would prefer that we do not make classList a >>property >> on UIBase. > >If we use a pluggable implementation, this is possible, if not, don't know >how to do it in the same UIBase class Besides "pluggable" which implies beads, the utility functions don't plug in anywhere but are PAYG. UIBase.element is public, so utility functions can directly access UIBase.element.classList. So instead of add/remove in UIBase, I think the add would just look like: Package org.apache.royale.utils.className { Public function addClassName(name:String, component:IUIBase):void { COMPILE::JS component.element.classList.add(name); } } Thoughts? -Alex
