Hi Alex, 2018-03-14 18:42 GMT+01:00 Alex Harui <[email protected]>:
> 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. > Right, what I want to express is that this method is like some kind of "commitProperties" or "updateDisplayList" or in Royale "createElement". It's great that we have here all the logic a component should do to manage the styles in the component, but I don't want to be obligated to override this method I only need to toggle a style (i.e : fab or primary cases). In those cases I only want to do "toggleStyle(<someclass>)" or in other case "addStyle" or "removeStyle". if we have the proper API in UIBase > > > >> 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. > ok, that would be great, but I don't know how to do this in a simple way. If we don't introduce some new methods in UIBase, we need to extend it, and we end with a class that is not between UIBase and the rest of components. The other way is compose a simple functionality for basic apps and advanced functionality, but again we need to proxy with UIBase methods like addStyle/removeStyle/toggleStyle, that calls the method in a Impl or another depending on what the user has configured > > > >> > >> 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); > } > } > For me that's ok, is like the "addStyle" I named before (I choose addStyle over addClassName since it seems more near to what the user does, add a css rule style, while classnames always seems to me that introduces some confusion with OOP languages like AS3, since seems to refer to classes as the definition of an object Anyway, that would be great, and is what I wanted and think that our users need: An API in UIBase to deal with styles since is maybe one of the main things people will do. Or at least is 90% of what I do when subclassing a Basic component since the rest of the "logic" is already done and working. So change HTML structure and add styling is the main point of extension, hence is natural to have that methods aggregated in UIBase If you want I can try it in my extension this concept and upload to my branch so you can take a look Thanks > > Thoughts? > -Alex > > -- Carlos Rovira http://about.me/carlosrovira
