You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2018/04/09 18:49:34 UTC
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Hi,
this branch has the UIBase modifications that I made in Jewel. I think is
time to complete the change so:
@Alex: Can you take a look at the diff and see if you are ok with it? I
think I do this with the considerations we discussed some weeks ago, but I
think you never saw if that was finaly what you suggested.
@Piotr: I think MDL is the project that needs to see how this changes
affect it. Since you're the one who are maintaining it, can you check it
and make the modifications in this branch needed? As we have no more
MDLExamples it would be a problem for me to bring that code and see it.
I see some other examples (like the other day fixing databinding flat) and
seems to work ok since the rest are mainly royale components,
I'd like to make this for 0.9.3 if possible to make Jewel as stable as
possible
Thanks
Carlos
2018-04-09 20:41 GMT+02:00 <ca...@apache.org>:
> This is an automated email from the ASF dual-hosted git repository.
>
> carlosrovira pushed a commit to branch feature/uibase-classname
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
> commit cf06ede63e3e794198fd68e8647e9c6eceae383d
> Author: Carlos Rovira <ca...@apache.org>
> AuthorDate: Mon Apr 9 20:41:48 2018 +0200
>
> UIBase className changes to support new cssclassList class methods
> like addStyles
> ---
> .../main/royale/org/apache/royale/core/UIBase.as | 18 +-
> .../main/royale/org/apache/royale/core/UIBase.as | 1628
> --------------------
> 2 files changed, 9 insertions(+), 1637 deletions(-)
>
> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/core/UIBase.as
> b/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/core/UIBase.as
> index b5f4dd1..f59d7f0 100644
> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/core/UIBase.as
> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/core/UIBase.as
> @@ -37,6 +37,7 @@ package org.apache.royale.core
> {
> import org.apache.royale.html.util.addElementToWrapper;
> import org.apache.royale.utils.CSSUtils;
> + import org.apache.royale.utils.cssclasslist.addStyles;
> }
>
> /**
> @@ -1085,11 +1086,13 @@ package org.apache.royale.core
> {
> if (_className !== value)
> {
> + _className = value;
> +
> COMPILE::JS
> {
> - setClassName(typeNames ? StringUtil.trim(value + ' '
> + typeNames) : value);
> + setClassName(computeFinalClassNames());
> }
> - _className = value;
> +
> dispatchEvent(new Event("classNameChanged"));
> }
> }
> @@ -1097,13 +1100,13 @@ package org.apache.royale.core
> COMPILE::JS
> protected function computeFinalClassNames():String
> {
> - return (_className ? _className + " " : "") + (typeNames ?
> typeNames : "");
> + return StringUtil.trim((_className ? _className : "") + " "
> + (typeNames ? typeNames : ""));
> }
>
> COMPILE::JS
> protected function setClassName(value:String):void
> {
> - element.className = value;
> + addStyles(element, value);
> }
>
> /**
> @@ -1394,11 +1397,8 @@ package org.apache.royale.core
>
> COMPILE::JS
> {
> - if (typeNames)
> - {
> - setClassName(computeFinalClassNames());
> - }
> -
> + setClassName(computeFinalClassNames());
> +
> if (style)
> ValuesManager.valuesImpl.applyStyles(this, style);
> }
> diff --git a/frameworks/projects/Jewel/src/main/royale/org/apache/royale/core/UIBase.as
> b/frameworks/projects/Jewel/src/main/royale/org/apache/
> royale/core/UIBase.as
> deleted file mode 100644
> index f59d7f0..0000000
> --- a/frameworks/projects/Jewel/src/main/royale/org/apache/
> royale/core/UIBase.as
> +++ /dev/null
> @@ -1,1628 +0,0 @@
> -///////////////////////////////////////////////////////////
> /////////////////////
> -//
> -// Licensed to the Apache Software Foundation (ASF) under one or more
> -// contributor license agreements. See the NOTICE file distributed with
> -// this work for additional information regarding copyright ownership.
> -// The ASF licenses this file to You under the Apache License, Version
> 2.0
> -// (the "License"); you may not use this file except in compliance with
> -// the License. You may obtain a copy of the License at
> -//
> -// http://www.apache.org/licenses/LICENSE-2.0
> -//
> -// Unless required by applicable law or agreed to in writing, software
> -// distributed under the License is distributed on an "AS IS" BASIS,
> -// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> -// See the License for the specific language governing permissions and
> -// limitations under the License.
> -//
> -///////////////////////////////////////////////////////////
> /////////////////////
> -package org.apache.royale.core
> -{
> - COMPILE::SWF
> - {
> - import flash.display.DisplayObject;
> - import flash.display.Sprite;
> - import flash.display.Stage;
> - import org.apache.royale.events.utils.MouseEventConverter;
> - }
> -
> - import org.apache.royale.events.Event;
> - import org.apache.royale.events.IEventDispatcher;
> - import org.apache.royale.events.MouseEvent;
> - import org.apache.royale.events.ValueChangeEvent;
> - import org.apache.royale.utils.loadBeadFromValuesManager;
> - import org.apache.royale.utils.StringUtil;
> -
> - COMPILE::JS
> - {
> - import org.apache.royale.html.util.addElementToWrapper;
> - import org.apache.royale.utils.CSSUtils;
> - import org.apache.royale.utils.cssclasslist.addStyles;
> - }
> -
> - /**
> - * Set a different class for click events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="click", type="org.apache.royale.events.MouseEvent")]
> -
> - /**
> - * Set a different class for rollOver events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="rollOver", type="org.apache.royale.events.MouseEvent")]
> -
> - /**
> - * Set a different class for rollOut events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="rollOut", type="org.apache.royale.events.MouseEvent")]
> -
> - /**
> - * Set a different class for mouseDown events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="mouseDown", type="org.apache.royale.events.MouseEvent")]
> -
> - /**
> - * Set a different class for mouseUp events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="mouseUp", type="org.apache.royale.events.MouseEvent")]
> -
> - /**
> - * Set a different class for mouseMove events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="mouseMove", type="org.apache.royale.events.MouseEvent")]
> -
> - /**
> - * Set a different class for mouseOut events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="mouseOut", type="org.apache.royale.events.MouseEvent")]
> -
> - /**
> - * Set a different class for mouseOver events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="mouseOver", type="org.apache.royale.
> events.MouseEvent")]
> - /**
> - * Set a different class for mouseWheel events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="mouseWheel", type="org.apache.royale.
> events.MouseEvent")]
> -
> - /**
> - * Set a different class for doubleClick events so that
> - * there aren't dependencies on the flash classes
> - * on the JS side.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - [Event(name="doubleClick", type="org.apache.royale.
> events.MouseEvent")]
> -
> - /**
> - * The UIBase class is the base class for most composite user
> interface
> - * components. For the Flash Player, Buttons and Text controls may
> - * have a different base class and therefore may not extend UIBase.
> - * However all user interface components should implement IUIBase.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public class UIBase extends HTMLElementWrapper implements
> IStrandWithModel, IEventDispatcher, IParentIUIBase, IStyleableObject,
> ILayoutChild, IRoyaleElement
> - {
> - /**
> - * Constructor.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function UIBase()
> - {
> - super();
> -
> - COMPILE::SWF
> - {
> - MouseEventConverter.setupInstanceConverters(this);
> - doubleClickEnabled = true; // make JS and flash consistent
> - }
> -
> - COMPILE::JS
> - {
> - createElement();
> - }
> - }
> -
> - COMPILE::SWF
> - public function get $displayObject():DisplayObject
> - {
> - return this;
> - }
> -
> - public function get royale_wrapper():Object
> - {
> - return this;
> - }
> - public function set royale_wrapper(value:Object):void
> - {
> - }
> -
> - private var _explicitWidth:Number;
> -
> - /**
> - * The explicitly set width (as opposed to measured width
> - * or percentage width).
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function get explicitWidth():Number
> - {
> - return _explicitWidth;
> - }
> -
> - /**
> - * @private
> - */
> - public function set explicitWidth(value:Number):void
> - {
> - if (_explicitWidth == value)
> - return;
> -
> - // width can be pixel or percent not both
> - if (!isNaN(value))
> - _percentWidth = NaN;
> -
> - _explicitWidth = value;
> -
> - dispatchEvent(new Event("explicitWidthChanged"));
> - }
> -
> - private var _explicitHeight:Number;
> -
> - /**
> - * The explicitly set width (as opposed to measured width
> - * or percentage width).
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function get explicitHeight():Number
> - {
> - return _explicitHeight;
> - }
> -
> - /**
> - * @private
> - */
> - public function set explicitHeight(value:Number):void
> - {
> - if (_explicitHeight == value)
> - return;
> -
> - // height can be pixel or percent not both
> - if (!isNaN(value))
> - _percentHeight = NaN;
> -
> - _explicitHeight = value;
> -
> - dispatchEvent(new Event("explicitHeightChanged"));
> - }
> -
> - private var _percentWidth:Number;
> -
> - /**
> - * The requested percentage width this component
> - * should have in the parent container. Note that
> - * the actual percentage may be different if the
> - * total is more than 100% or if there are other
> - * components with explicitly set widths.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function get percentWidth():Number
> - {
> - return _percentWidth;
> - }
> -
> - /**
> - * @private
> - */
> - public function set percentWidth(value:Number):void
> - {
> - COMPILE::SWF {
> - if (_percentWidth == value)
> - return;
> -
> - if (!isNaN(value))
> - _explicitWidth = NaN;
> -
> - _percentWidth = value;
> - }
> - COMPILE::JS {
> - this._percentWidth = value;
> - this.positioner.style.width =
> value.toString() + '%';
> - if (!isNaN(value))
> - this._explicitWidth = NaN;
> - }
> -
> - dispatchEvent(new Event("percentWidthChanged"));
> - }
> -
> - private var _percentHeight:Number;
> -
> - /**
> - * The requested percentage height this component
> - * should have in the parent container. Note that
> - * the actual percentage may be different if the
> - * total is more than 100% or if there are other
> - * components with explicitly set heights.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function get percentHeight():Number
> - {
> - return _percentHeight;
> - }
> -
> - /**
> - * @private
> - */
> - public function set percentHeight(value:Number):void
> - {
> - COMPILE::SWF {
> - if (_percentHeight == value)
> - return;
> -
> - if (!isNaN(value))
> - _explicitHeight = NaN;
> -
> - _percentHeight = value;
> - }
> -
> - COMPILE::JS {
> - this._percentHeight = value;
> - this.positioner.style.height =
> value.toString() + '%';
> - if (!isNaN(value))
> - this._explicitHeight = NaN;
> - }
> -
> - dispatchEvent(new Event("percentHeightChanged"));
> - }
> -
> - private var _width:Number;
> -
> - [Bindable("widthChanged")]
> - [PercentProxy("percentWidth")]
> - /**
> - * The width of the component. If no width has been previously
> - * set the default width may be specified in the IValuesImpl
> - * or determined as the bounding box around all child
> - * components and graphics.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::SWF
> - override public function get width():Number
> - {
> - var w:Number = _width;
> - if (isNaN(w)) {
> - w = $width;
> - }
> - return w;
> - }
> -
> - [Bindable("widthChanged")]
> - [PercentProxy("percentWidth")]
> - /**
> - * @royaleignorecoercion String
> - */
> - COMPILE::JS
> - public function get width():Number
> - {
> - if(!isNaN(_explicitWidth))
> - return _explicitWidth;
> - var pixels:Number;
> - var strpixels:String = element.style.width as String;
> - if(strpixels == null)
> - pixels = NaN;
> - else
> - pixels = CSSUtils.toNumber(strpixels,NaN);
> - if (isNaN(pixels)) {
> - pixels = positioner.offsetWidth;
> - if (pixels == 0 && positioner.scrollWidth != 0) {
> - // invisible child elements cause offsetWidth to be 0.
> - pixels = positioner.scrollWidth;
> - }
> - }
> - return pixels;
> - }
> -
> - /**
> - * @private
> - */
> - COMPILE::SWF
> - override public function set width(value:Number):void
> - {
> - if (explicitWidth !== value)
> - {
> - explicitWidth = value;
> - }
> -
> - setWidth(value);
> - }
> -
> - /**
> - * @private
> - */
> - COMPILE::JS
> - public function set width(value:Number):void
> - {
> - if (explicitWidth !== value)
> - {
> - explicitWidth = value;
> - }
> -
> - setWidth(value);
> - }
> -
> - /**
> - * Retrieve the low-level bounding box width.
> - * Not implemented in JS.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::SWF
> - public function get $width():Number
> - {
> - return super.width;
> - }
> -
> - private var _height:Number;
> -
> - [Bindable("heightChanged")]
> - [PercentProxy("percentHeight")]
> - /**
> - * The height of the component. If no height has been previously
> - * set the default height may be specified in the IValuesImpl
> - * or determined as the bounding box around all child
> - * components and graphics.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::SWF
> - override public function get height():Number
> - {
> - var h:Number = _height;
> - if (isNaN(h)) {
> - h = $height;
> - }
> - return h;
> - }
> -
> - [Bindable("heightChanged")]
> - [PercentProxy("percentHeight")]
> - /**
> - * @royaleignorecoercion String
> - */
> - COMPILE::JS
> - public function get height():Number
> - {
> - if(!isNaN(_explicitHeight))
> - return _explicitHeight;
> - var pixels:Number;
> - var strpixels:String = element.style.height as String;
> - if(strpixels == null)
> - pixels = NaN;
> - else
> - pixels = CSSUtils.toNumber(strpixels,NaN);
> - if (isNaN(pixels)) {
> - pixels = positioner.offsetHeight;
> - if (pixels == 0 && positioner.scrollHeight != 0) {
> - // invisible child elements cause offsetHeight to be
> 0.
> - pixels = positioner.scrollHeight;
> - }
> - }
> - return pixels;
> - }
> -
> - /**
> - * @private
> - */
> - COMPILE::SWF
> - override public function set height(value:Number):void
> - {
> - if (explicitHeight !== value)
> - {
> - explicitHeight = value;
> - }
> -
> - setHeight(value);
> - }
> -
> - /**
> - * @private
> - */
> - COMPILE::JS
> - public function set height(value:Number):void
> - {
> - if (explicitHeight !== value)
> - {
> - explicitHeight = value;
> - }
> -
> - setHeight(value);
> - }
> -
> - /**
> - * Retrieve the low-level bounding box height.
> - * Not implemented in JS.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::SWF
> - public function get $height():Number
> - {
> - return super.height;
> - }
> -
> - /**
> - * @copy org.apache.royale.core.ILayoutChild#setHeight
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function setHeight(value:Number, noEvent:Boolean =
> false):void
> - {
> - if (_height !== value)
> - {
> - _height = value;
> - COMPILE::JS
> - {
> - this.positioner.style.height = value.toString() +
> 'px';
> - }
> - if (!noEvent)
> - dispatchEvent(new Event("heightChanged"));
> - }
> - }
> -
> - /**
> - * @copy org.apache.royale.core.ILayoutChild#setWidth
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function setWidth(value:Number, noEvent:Boolean =
> false):void
> - {
> - if (_width !== value)
> - {
> - _width = value;
> - COMPILE::JS
> - {
> - this.positioner.style.width = value.toString() + 'px';
> - }
> - if (!noEvent)
> - dispatchEvent(new Event("widthChanged"));
> - }
> - }
> -
> - /**
> - * @private
> - * Used by layout to prevent causing unnecessary reflows when
> measuring.
> - */
> - private var _measuredWidth:Number;
> -
> - public function get measuredWidth():Number
> - {
> - return _measuredWidth;
> - }
> -
> - public function set measuredWidth(value:Number):void
> - {
> - _measuredWidth = value;
> - }
> - /**
> - * @private
> - * Used by layout to prevent causing unnecessary reflows when
> measuring.
> - */
> - private var _measuredHeight:Number;
> -
> - public function get measuredHeight():Number
> - {
> - return _measuredHeight;
> - }
> -
> - public function set measuredHeight(value:Number):void
> - {
> - _measuredHeight = value;
> - }
> -
> - /**
> - * @copy org.apache.royale.core.ILayoutChild#setWidthAndHeight
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function setWidthAndHeight(newWidth:Number,
> newHeight:Number, noEvent:Boolean = false):void
> - {
> - if (_width !== newWidth)
> - {
> - _width = newWidth;
> - COMPILE::JS
> - {
> - this.positioner.style.width = newWidth.toString() +
> 'px';
> - }
> - if (!noEvent)
> - dispatchEvent(new Event("widthChanged"));
> - }
> - if (_height !== newHeight)
> - {
> - _height = newHeight;
> - COMPILE::JS
> - {
> - this.positioner.style.height = newHeight.toString() +
> 'px';
> - }
> - if (!noEvent)
> - dispatchEvent(new Event("heightChanged"));
> - }
> - dispatchEvent(new Event("sizeChanged"));
> - }
> -
> - /**
> - * @copy org.apache.royale.core.ILayoutChild#
> isWidthSizedToContent
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function isWidthSizedToContent():Boolean
> - {
> - if (!isNaN(_explicitWidth))
> - return false;
> - if (!isNaN(_percentWidth))
> - return false;
> - var left:* = ValuesManager.valuesImpl.getValue(this, "left");
> - var right:* = ValuesManager.valuesImpl.getValue(this,
> "right");
> - return (left === undefined || right === undefined);
> -
> - }
> -
> - /**
> - * @copy org.apache.royale.core.ILayoutChild#
> isHeightSizedToContent
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function isHeightSizedToContent():Boolean
> - {
> - if (!isNaN(_explicitHeight))
> - return false;
> - if (!isNaN(_percentHeight))
> - return false;
> - var top:* = ValuesManager.valuesImpl.getValue(this, "top");
> - var bottom:* = ValuesManager.valuesImpl.getValue(this,
> "bottom");
> - return (top === undefined || bottom === undefined);
> - }
> -
> - private var _x:Number;
> -
> - /**
> - * @private
> - */
> - COMPILE::SWF
> - override public function set x(value:Number):void
> - {
> - super.x = _x = value;
> - if (!style)
> - style = { left: value };
> - else
> - style.left = value;
> - }
> - /**
> - * @royaleignorecoercion HTMLElement
> - */
> - COMPILE::JS
> - public function set x(value:Number):void
> - {
> - _x = value;
> - setX(value);
> - }
> -
> - /**
> - * @royaleignorecoercion String
> - * @royaleignorecoercion HTMLElement
> - */
> - COMPILE::JS
> - public function get x():Number
> - {
> - if(!isNaN(_x))
> - return _x
> - var strpixels:String = positioner.style.left as String;
> - var pixels:Number = parseFloat(strpixels);
> - if (isNaN(pixels))
> - {
> - pixels = positioner.offsetLeft;
> - if (positioner.parentNode != positioner.offsetParent)
> - pixels -= (positioner.parentNode as
> HTMLElement).offsetLeft;
> - }
> - return pixels;
> - }
> -
> - /**
> - * @copy org.apache.royale.core.ILayoutChild#setX
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - * @royaleignorecoercion HTMLElement
> - */
> - public function setX(value:Number):void
> - {
> - COMPILE::SWF
> - {
> - super.x = value;
> - }
> - COMPILE::JS
> - {
> - //positioner.style.position = 'absolute';
> - if (positioner.parentNode != positioner.offsetParent)
> - value += (positioner.parentNode as
> HTMLElement).offsetLeft;
> - positioner.style.left = value.toString() +
> 'px';
> - }
> - }
> -
> - private var _y:Number;
> -
> - /**
> - * @private
> - */
> - COMPILE::SWF
> - override public function set y(value:Number):void
> - {
> - super.y = _y = value;
> - if (!style)
> - style = { top: value };
> - else
> - style.top = value;
> - }
> -
> - /**
> - * @royaleignorecoercion HTMLElement
> - */
> - COMPILE::JS
> - public function set y(value:Number):void
> - {
> - _y = value;
> - setY(value);
> - }
> -
> - /**
> - * @royaleignorecoercion String
> - * @royaleignorecoercion HTMLElement
> - */
> - COMPILE::JS
> - public function get y():Number
> - {
> - if(!isNaN(_y))
> - return _y
> - var strpixels:String = positioner.style.top as String;
> - var pixels:Number = parseFloat(strpixels);
> - if (isNaN(pixels))
> - {
> - pixels = positioner.offsetTop;
> - if (positioner.parentNode != positioner.offsetParent)
> - pixels -= (positioner.parentNode as
> HTMLElement).offsetTop;
> - }
> - return pixels;
> - }
> -
> - /**
> - * @copy org.apache.royale.core.ILayoutChild#setY
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - * @royaleignorecoercion HTMLElement
> - */
> - public function setY(value:Number):void
> - {
> - COMPILE::SWF
> - {
> - super.y = value;
> - }
> - COMPILE::JS
> - {
> - //positioner.style.position = 'absolute';
> - if (positioner.parentNode != positioner.offsetParent)
> - value += (positioner.parentNode as
> HTMLElement).offsetTop;
> - positioner.style.top = value.toString() +
> 'px';
> - }
> - }
> -
> - /**
> - * @private
> - */
> - [Bindable("visibleChanged")]
> - COMPILE::SWF
> - override public function set visible(value:Boolean):void
> - {
> - super.visible = value;
> - dispatchEvent(new Event(value?"show":"hide"));
> - dispatchEvent(new Event("visibleChanged"));
> - }
> -
> - COMPILE::JS
> - private var displayStyleForLayout:String;
> -
> - /**
> - * The display style is used for both visible
> - * and layout so is managed as a special case.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::JS
> - public function setDisplayStyleForLayout(
> value:String):void
> - {
> - if (positioner.style.display !== 'none')
> - positioner.style.display = value;
> - else
> - displayStyleForLayout = value;
> - }
> -
> - [Bindable("visibleChanged")]
> - COMPILE::JS
> - public function get visible():Boolean
> - {
> - return positioner.style.display !== 'none';
> - }
> -
> - COMPILE::JS
> - public function set visible(value:Boolean):void
> - {
> - var oldValue:Boolean = positioner.style.display !== 'none';
> - if (value !== oldValue)
> - {
> - if (!value)
> - {
> - displayStyleForLayout =
> positioner.style.display;
> - positioner.style.display = 'none';
> - dispatchEvent(new Event('hide'));
> - }
> - else
> - {
> - if (displayStyleForLayout != null)
> - positioner.style.display = displayStyleForLayout;
> - dispatchEvent(new Event('show'));
> - }
> - dispatchEvent(new Event('visibleChanged'));
> - }
> - }
> -
> - /**
> - * @return The array of children.
> - * @royaleignorecoercion Array
> - */
> - COMPILE::JS
> - public function internalChildren():Array
> - {
> - return element.childNodes as Array;
> - }
> -
> - COMPILE::SWF
> - private var _model:IBeadModel;
> -
> - /**
> - * An IBeadModel that serves as the data model for the component.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::SWF
> - public function get model():Object
> - {
> - if (_model == null)
> - {
> - // addbead will set _model
> - addBead(new (ValuesManager.valuesImpl.getValue(this,
> "iBeadModel")) as IBead);
> - }
> - return _model;
> - }
> -
> - /**
> - * @private
> - */
> - COMPILE::SWF
> - public function set model(value:Object):void
> - {
> - if (_model != value)
> - {
> - addBead(value as IBead);
> - dispatchEvent(new Event("modelChanged"));
> - }
> - }
> -
> - private var _view:IBeadView;
> -
> - /**
> - * An IBeadView that serves as the view for the component.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - * @royaleignorecoercion Class
> - * @royaleignorecoercion org.apache.royale.core.IBeadView
> - */
> - public function get view():IBeadView
> - {
> - if(!_view)
> - _view = loadBeadFromValuesManager(IBeadView,
> "iBeadView", this) as IBeadView;
> - return _view;
> - }
> -
> - /**
> - * @private
> - */
> - public function set view(value:IBeadView):void
> - {
> - if (_view != value)
> - {
> - addBead(value);
> - dispatchEvent(new Event("viewChanged"));
> - }
> - }
> -
> - private var _id:String;
> -
> - /**
> - * An id property for MXML documents.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function get id():String
> - {
> - return _id;
> - }
> -
> - /**
> - * @private
> - */
> - public function set id(value:String):void
> - {
> - if (_id !== value)
> - {
> - _id = value;
> - dispatchEvent(new Event("idChanged"));
> - }
> - COMPILE::JS
> - {
> - element.id = _id;
> - }
> - }
> -
> - private var _style:Object;
> -
> - /**
> - * The object that contains
> - * "styles" and other associated
> - * name-value pairs. You can
> - * also specify a string in
> - * HTML style attribute format.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function get style():Object
> - {
> - return _style;
> - }
> -
> - /**
> - * @private
> - * @royaleignorecoercion String
> - */
> - public function set style(value:Object):void
> - {
> - if (_style !== value)
> - {
> - if (value is String)
> - {
> - _style = ValuesManager.valuesImpl.parseStyles(value
> as String);
> - }
> - else
> - _style = value;
> - if (!isNaN(_y))
> - _style.top = _y;
> - if (!isNaN(_x))
> - _style.left = _x;
> - COMPILE::JS
> - {
> - if (parent)
> - ValuesManager.valuesImpl.applyStyles(this,
> _style);
> - }
> - dispatchEvent(new Event("stylesChanged"));
> - }
> - }
> -
> - /**
> - * A list of type names. Often used for CSS
> - * type selector lookups.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - *
> - * @royalesuppresspublicvarwarning
> - */
> - public var typeNames:String;
> -
> - private var _className:String;
> -
> - /**
> - * The classname. Often used for CSS
> - * class selector lookups.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function get className():String
> - {
> - return _className;
> - }
> -
> - /**
> - * @private
> - */
> - public function set className(value:String):void
> - {
> - if (_className !== value)
> - {
> - _className = value;
> -
> - COMPILE::JS
> - {
> - setClassName(computeFinalClassNames());
> - }
> -
> - dispatchEvent(new Event("classNameChanged"));
> - }
> - }
> -
> - COMPILE::JS
> - protected function computeFinalClassNames():String
> - {
> - return StringUtil.trim((_className ? _className : "") + " "
> + (typeNames ? typeNames : ""));
> - }
> -
> - COMPILE::JS
> - protected function setClassName(value:String):void
> - {
> - addStyles(element, value);
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IUIBase#element
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::SWF
> - public function get element():IRoyaleElement
> - {
> - return this;
> - }
> -
> - /**
> - * @copy org.apache.royale.core.Application#beads
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - *
> - * @royalesuppresspublicvarwarning
> - */
> - public var beads:Array;
> -
> - COMPILE::SWF
> - private var _beads:Vector.<IBead>;
> -
> - /**
> - * @copy org.apache.royale.core.IStrand#addBead()
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.9
> - * @royaleignorecoercion org.apache.royale.core.IBeadModel
> - * @royaleignorecoercion org.apache.royale.core.IBeadView
> - */
> - override public function addBead(bead:IBead):void
> - {
> - var isView:Boolean;
> - if (!_beads)
> - _beads = new Vector.<IBead>;
> - _beads.push(bead);
> - if (bead is IBeadModel)
> - _model = bead as IBeadModel;
> - else if (bead is IBeadView)
> - {
> - _view = bead as IBeadView;
> - isView = true
> - }
> - bead.strand = this;
> -
> - if (isView) {
> - dispatchEvent(new Event("viewChanged"));
> - }
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IStrand#getBeadByType()
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::SWF
> - public function getBeadByType(
> classOrInterface:Class):IBead
> - {
> - for each (var bead:IBead in _beads)
> - {
> - if (bead is classOrInterface)
> - return bead;
> - }
> - return null;
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IStrand#removeBead()
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - COMPILE::SWF
> - public function removeBead(value:IBead):IBead
> - {
> - var n:int = _beads.length;
> - for (var i:int = 0; i < n; i++)
> - {
> - var bead:IBead = _beads[i];
> - if (bead == value)
> - {
> - _beads.splice(i, 1);
> - return bead;
> - }
> - }
> - return null;
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IParent#addElement()
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - * @royaleignorecoercion org.apache.royale.core.IUIBase
> - */
> - public function addElement(c:IChild, dispatchEvent:Boolean
> = true):void
> - {
> - COMPILE::SWF
> - {
> - if (c is IUIBase)
> - {
> - if (c is IRenderedObject)
> - addChild(IRenderedObject(c).$displayObject);
> - else
> - addChild(c as DisplayObject);
> - IUIBase(c).addedToParent();
> - }
> - else
> - addChild(c as DisplayObject);
> - }
> - COMPILE::JS
> - {
> - element.appendChild(c.positioner);
> - (c as IUIBase).addedToParent();
> - }
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IParent#addElementAt()
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - * @royaleignorecoercion org.apache.royale.core.IUIBase
> - */
> - public function addElementAt(c:IChild, index:int,
> dispatchEvent:Boolean = true):void
> - {
> - COMPILE::SWF
> - {
> - if (c is IUIBase)
> - {
> - if (c is IRenderedObject)
> - addChildAt(IUIBase(c).$displayObject, index);
> - else
> - addChildAt(c as DisplayObject, index);
> - IUIBase(c).addedToParent();
> - }
> - else
> - addChildAt(c as DisplayObject, index);
> - }
> - COMPILE::JS
> - {
> - var children:Array = internalChildren();
> - if (index >= children.length)
> - addElement(c);
> - else
> - {
> - element.insertBefore(c.positioner,
> - children[index]);
> - (c as IUIBase).addedToParent();
> - }
> - }
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IParent#getElementAt()
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function getElementAt(index:int):IChild
> - {
> - COMPILE::SWF
> - {
> - return getChildAt(index) as IChild;
> - }
> - COMPILE::JS
> - {
> - var children:Array = internalChildren();
> - if (children.length == 0)
> - {
> - return null;
> - }
> - return children[index].royale_wrapper;
> - }
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IParent#getElementIndex()
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function getElementIndex(c:IChild):int
> - {
> - COMPILE::SWF
> - {
> - if (c is IRenderedObject)
> - return getChildIndex(IRenderedObject(
> c).$displayObject);
> - else
> - return getChildIndex(c as DisplayObject);
> - }
> - COMPILE::JS
> - {
> - var children:Array = internalChildren();
> - var n:int = children.length;
> - for (var i:int = 0; i < n; i++)
> - {
> - if (children[i] === c.element)
> - return i;
> - }
> - return -1;
> - }
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IParent#removeElement()
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - * @royaleignorecoercion HTMLElement
> - */
> - public function removeElement(c:IChild, dispatchEvent:Boolean =
> true):void
> - {
> - COMPILE::SWF
> - {
> - if (c is IRenderedObject)
> - removeChild(IRenderedObject(c).$displayObject);
> - else
> - removeChild(c as DisplayObject);
> - }
> - COMPILE::JS
> - {
> - element.removeChild(c.element as HTMLElement);
> - }
> - }
> -
> - /**
> - * @copy org.apache.royale.core.IParent#numElements
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - */
> - public function get numElements():int
> - {
> - COMPILE::SWF
> - {
> - return numChildren;
> - }
> - COMPILE::JS
> - {
> - var children:Array = internalChildren();
> - return children.length;
> - }
> - }
> -
> - /**
> - * The method called when added to a parent. This is a good
> - * time to set up beads.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - * @royaleignorecoercion Class
> - * @royaleignorecoercion Number
> - */
> - public function addedToParent():void
> - {
> - var c:Class;
> -
> - COMPILE::JS
> - {
> - setClassName(computeFinalClassNames());
> -
> - if (style)
> - ValuesManager.valuesImpl.applyStyles(this, style);
> - }
> -
> - if (isNaN(_explicitWidth) && isNaN(_percentWidth))
> - {
> - var value:* = ValuesManager.valuesImpl.
> getValue(this,"width");
> - if (value !== undefined)
> - {
> - if (value is String)
> - {
> - var s:String = String(value);
> - if (s.indexOf("%") > -1)
> - _percentWidth =
> Number(s.substring(0, s.length - 1));
> - else
> - {
> - if (s.indexOf("px") !== -1)
> - s = s.substring(0, s.length - 2);
> - _width = _explicitWidth = Number(s);
> - }
> - }
> - else
> - _width = _explicitWidth =
> value as Number;
> - }
> - }
> -
> - if (isNaN(_explicitHeight) &&
> isNaN(_percentHeight))
> - {
> - value = ValuesManager.valuesImpl.
> getValue(this,"height");
> - if (value !== undefined)
> - {
> - if (value is String)
> - {
> - s = String(value);
> - if (s.indexOf("%") !== -1)
> - _percentHeight =
> Number(s.substring(0, s.length - 1));
> - else
> - {
> - if (s.indexOf("px") !== -1)
> - s = s.substring(0, s.length - 2);
> - _height = _explicitHeight = Number(s);
> - }
> - }
> - else
> - _height = _explicitHeight
> = value as Number;
> - }
> - }
> -
> - for each (var bead:IBead in beads)
> - addBead(bead);
> -
> - loadBeadFromValuesManager(IBeadModel,
> "iBeadModel", this);
> - loadBeadFromValuesManager(IBeadView, "iBeadView", this);
> - loadBeadFromValuesManager(IBeadController,
> "iBeadController", this);
> - dispatchEvent(new Event("beadsAdded"));
> - }
> -
> - private var _measurementBead:IMeasurementBead;
> - /**
> - * A measurement bead, if one exists.
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.9
> - * @royaleignorecoercion org.apache.royale.core.IMeasurementBead
> - */
> - public function get measurementBead() : IMeasurementBead
> - {
> - if(!_measurementBead)
> - {
> - _measurementBead = loadBeadFromValuesManager(IMeasurementBead,
> "iMeasurementBead", this) as IMeasurementBead;
> - }
> - return _measurementBead;
> - }
> -
> - COMPILE::SWF
> - private var _stageProxy:StageProxy;
> -
> - /**
> - * @copy org.apache.royale.core.IUIBase#topMostEventDispatcher
> - *
> - * @langversion 3.0
> - * @playerversion Flash 10.2
> - * @playerversion AIR 2.6
> - * @productversion Royale 0.0
> - * @royaleignorecoercion org.apache.royale.core.
> WrappedHTMLElement
> - * @royaleignorecoercion org.apache.royale.events.
> IEventDispatcher
> - */
> - public function get topMostEventDispatcher():
> IEventDispatcher
> - {
> - COMPILE::SWF
> - {
> - if (!_stageProxy)
> - {
> - _stageProxy = new StageProxy(stage);
> - _stageProxy.addEventListener("removedFromStage",
> stageProxy_removedFromStageHandler);
> - }
> -
> - return _stageProxy;
> - }
> - COMPILE::JS
> - {
> - var e:WrappedHTMLElement = document.body as
> WrappedHTMLElement;
> - return e.royale_wrapper as IEventDispatcher;
> - }
> - }
> -
> - COMPILE::SWF
> - private function stageProxy_removedFromStageHandler(event:
> Event):void
> - {
> - _stageProxy = null;
> - }
> -
> - /**
> - * Rebroadcast an event from a sub component from the component.
> - */
> - protected function repeaterListener(event:Event):void
> - {
> - dispatchEvent(event);
> - }
> -
> - /**
> - * The HTMLElement used to position the component.
> - */
> - COMPILE::JS
> - public function get positioner():WrappedHTMLElement
> - {
> - return element;
> - }
> -
> - /**
> - * @private
> - */
> - COMPILE::JS
> - public function set positioner(value:WrappedHTMLElement):void
> - {
> - element = value;
> - }
> -
> - /**
> - * @return The actual element to be parented.
> - * @royaleignorecoercion org.apache.royale.core.
> WrappedHTMLElement
> - */
> - COMPILE::JS
> - protected function createElement():WrappedHTMLElement
> - {
> - addElementToWrapper(this,'div');
> - positioner.style.display = 'block';
> - //positioner.style.position = 'relative';
> - return element;
> - }
> -
> -
> - /**
> - * The HTMLElement used to position the component.
> - * @royaleignorecoercion String
> - */
> - COMPILE::JS
> - public function get alpha():Number
> - {
> - var stralpha:String = positioner.style.opacity as String;
> - var alpha:Number = parseFloat(stralpha);
> - return alpha;
> - }
> -
> - COMPILE::JS
> - public function set alpha(value:Number):void
> - {
> - positioner.style.opacity = value;
> - }
> -
> - /**
> - * @param value The event containing new style properties.
> - */
> - COMPILE::JS
> - protected function styleChangeHandler(value:
> ValueChangeEvent):void
> - {
> - var newStyle:Object = {};
> - newStyle[value.propertyName] = value.newValue;
> - ValuesManager.valuesImpl.applyStyles(this, newStyle);
> - }
> -
> - /**
> - * @royaleignorecoercion org.apache.royale.core.
> WrappedHTMLElement
> - * @royaleignorecoercion org.apache.royale.core.IParent
> - */
> - COMPILE::JS
> - public function get parent():IParent
> - {
> - var p:WrappedHTMLElement = this.positioner.parentNode as
> WrappedHTMLElement;
> - var wrapper:IParent = p ? p.royale_wrapper as IParent : null;
> - return wrapper;
> - }
> -
> - COMPILE::SWF
> - {
> - [SWFOverride(returns="flash.display.DisplayObjectContainer")]
> - override public function get parent():IParent
> - {
> - return super.parent as IParent;
> - }
> - }
> -
> - COMPILE::SWF
> - public function get transformElement():IRoyaleElement
> - {
> - return this;
> - }
> -
> - COMPILE::JS
> - public function get transformElement():WrappedHTMLElement
> - {
> - return element;
> - }
> -
> - COMPILE::SWF
> - {
> - [SWFOverride(params="flash.events.Event",
> altparams="org.apache.royale.events.Event:org.apache.
> royale.events.MouseEvent")]
> - override public function dispatchEvent(event:org.
> apache.royale.events.Event):Boolean
> - {
> - return super.dispatchEvent(event);
> - }
> - }
> -
> - }
> -}
>
> --
> To stop receiving notification emails like this one, please contact
> carlosrovira@apache.org.
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yes, I am hopeful we can move forward from here (probably with some bug
fixes).
Thanks,
-Alex
On 4/17/18, 1:21 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
>
>> 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, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
>> >
>> >> 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, "carlos.rovira@gmail.com on behalf of Carlos
>> >>Rovira"
>> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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
>><pi...@gmail.com>:
>> >> >
>> >> >> 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 <ah...@adobe.com.invalid>:
>> >> >>
>> >> >> > 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, "carlos.rovira@gmail.com on behalf of
>>Carlos
>> >> >> Rovira"
>> >> >> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>> >>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
>><ah...@adobe.com.invalid>:
>> >> >> > >
>> >> >> > >> 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"
>> >><pi...@gmail.com>
>> >> >> > 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
>> >> >><carlosrovira@apache.org
>> >> >> >
>> >> >> > >> >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
>> >> >> > >><pi...@gmail.com>:
>> >> >> > >> >>
>> >> >> > >> >> > 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
>> >> >> > >><carlosrovira@apache.org
>> >> >> > >> >
>> >> >> > >> >> > wrote:
>> >> >> > >> >> >
>> >> >> > >> >> > > Alex
>> >> >> > >> >> > >
>> >> >> > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui
>> >> >><aharui@adobe.com.invalid
>> >> >> >:
>> >> >> > >> >> > >
>> >> >> > >> >> > > > 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, "carlos.rovira@gmail.com on
>> behalf
>> >> of
>> >> >> > >>Carlos
>> >> >> > >> >> > > Rovira"
>> >> >> > >> >> > > > <carlos.rovira@gmail.com on behalf of
>> >> >> carlosrovira@apache.org>
>> >> >> > >> >> 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
>> >> >> > >> >><ca...@apache.org>:
>> >> >> > >> >> > > > >
>> >> >> > >> >> > > > >> 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
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
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 <ah...@adobe.com.invalid>:
> 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, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
> >
> >> 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, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <pi...@gmail.com>:
> >> >
> >> >> 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 <ah...@adobe.com.invalid>:
> >> >>
> >> >> > 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, "carlos.rovira@gmail.com on behalf of Carlos
> >> >> Rovira"
> >> >> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> >>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 <ah...@adobe.com.invalid>:
> >> >> > >
> >> >> > >> 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"
> >><pi...@gmail.com>
> >> >> > 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
> >> >><carlosrovira@apache.org
> >> >> >
> >> >> > >> >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
> >> >> > >><pi...@gmail.com>:
> >> >> > >> >>
> >> >> > >> >> > 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
> >> >> > >><carlosrovira@apache.org
> >> >> > >> >
> >> >> > >> >> > wrote:
> >> >> > >> >> >
> >> >> > >> >> > > Alex
> >> >> > >> >> > >
> >> >> > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui
> >> >><aharui@adobe.com.invalid
> >> >> >:
> >> >> > >> >> > >
> >> >> > >> >> > > > 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, "carlos.rovira@gmail.com on
> behalf
> >> of
> >> >> > >>Carlos
> >> >> > >> >> > > Rovira"
> >> >> > >> >> > > > <carlos.rovira@gmail.com on behalf of
> >> >> carlosrovira@apache.org>
> >> >> > >> >> 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
> >> >> > >> >><ca...@apache.org>:
> >> >> > >> >> > > > >
> >> >> > >> >> > > > >> 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
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
>
>> 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, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <pi...@gmail.com>:
>> >
>> >> 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 <ah...@adobe.com.invalid>:
>> >>
>> >> > 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, "carlos.rovira@gmail.com on behalf of Carlos
>> >> Rovira"
>> >> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>>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 <ah...@adobe.com.invalid>:
>> >> > >
>> >> > >> 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"
>><pi...@gmail.com>
>> >> > 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
>> >><carlosrovira@apache.org
>> >> >
>> >> > >> >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
>> >> > >><pi...@gmail.com>:
>> >> > >> >>
>> >> > >> >> > 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
>> >> > >><carlosrovira@apache.org
>> >> > >> >
>> >> > >> >> > wrote:
>> >> > >> >> >
>> >> > >> >> > > Alex
>> >> > >> >> > >
>> >> > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui
>> >><aharui@adobe.com.invalid
>> >> >:
>> >> > >> >> > >
>> >> > >> >> > > > 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, "carlos.rovira@gmail.com on behalf
>> of
>> >> > >>Carlos
>> >> > >> >> > > Rovira"
>> >> > >> >> > > > <carlos.rovira@gmail.com on behalf of
>> >> carlosrovira@apache.org>
>> >> > >> >> 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
>> >> > >> >><ca...@apache.org>:
>> >> > >> >> > > > >
>> >> > >> >> > > > >> 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
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
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 <ah...@adobe.com.invalid>:
> 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, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <pi...@gmail.com>:
> >
> >> 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 <ah...@adobe.com.invalid>:
> >>
> >> > 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, "carlos.rovira@gmail.com on behalf of Carlos
> >> Rovira"
> >> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
> >> > >
> >> > >> 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" <pi...@gmail.com>
> >> > 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
> >><carlosrovira@apache.org
> >> >
> >> > >> >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
> >> > >><pi...@gmail.com>:
> >> > >> >>
> >> > >> >> > 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
> >> > >><carlosrovira@apache.org
> >> > >> >
> >> > >> >> > wrote:
> >> > >> >> >
> >> > >> >> > > Alex
> >> > >> >> > >
> >> > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui
> >><aharui@adobe.com.invalid
> >> >:
> >> > >> >> > >
> >> > >> >> > > > 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, "carlos.rovira@gmail.com on behalf
> of
> >> > >>Carlos
> >> > >> >> > > Rovira"
> >> > >> >> > > > <carlos.rovira@gmail.com on behalf of
> >> carlosrovira@apache.org>
> >> > >> >> 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
> >> > >> >><ca...@apache.org>:
> >> > >> >> > > > >
> >> > >> >> > > > >> 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
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <pi...@gmail.com>:
>
>> 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 <ah...@adobe.com.invalid>:
>>
>> > 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, "carlos.rovira@gmail.com on behalf of Carlos
>> Rovira"
>> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
>> > >
>> > >> 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" <pi...@gmail.com>
>> > 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
>><carlosrovira@apache.org
>> >
>> > >> >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
>> > >><pi...@gmail.com>:
>> > >> >>
>> > >> >> > 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
>> > >><carlosrovira@apache.org
>> > >> >
>> > >> >> > wrote:
>> > >> >> >
>> > >> >> > > Alex
>> > >> >> > >
>> > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui
>><aharui@adobe.com.invalid
>> >:
>> > >> >> > >
>> > >> >> > > > 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, "carlos.rovira@gmail.com on behalf of
>> > >>Carlos
>> > >> >> > > Rovira"
>> > >> >> > > > <carlos.rovira@gmail.com on behalf of
>> carlosrovira@apache.org>
>> > >> >> 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
>> > >> >><ca...@apache.org>:
>> > >> >> > > > >
>> > >> >> > > > >> 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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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%7Cfa7b1b5a7b34438794aed2c178decee1%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%7Cfa7b1b5a7b34438794aed2c178decee1%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
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
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 <pi...@gmail.com>:
> 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 <ah...@adobe.com.invalid>:
>
> > 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, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
> > >
> > >> 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" <pi...@gmail.com>
> > 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 <carlosrovira@apache.org
> >
> > >> >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
> > >><pi...@gmail.com>:
> > >> >>
> > >> >> > 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
> > >><carlosrovira@apache.org
> > >> >
> > >> >> > wrote:
> > >> >> >
> > >> >> > > Alex
> > >> >> > >
> > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui <aharui@adobe.com.invalid
> >:
> > >> >> > >
> > >> >> > > > 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, "carlos.rovira@gmail.com on behalf of
> > >>Carlos
> > >> >> > > Rovira"
> > >> >> > > > <carlos.rovira@gmail.com on behalf of
> carlosrovira@apache.org>
> > >> >> 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
> > >> >><ca...@apache.org>:
> > >> >> > > > >
> > >> >> > > > >> 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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ah...@adobe.com.invalid>:
> 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, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
> >
> >> 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" <pi...@gmail.com>
> 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 <ca...@apache.org>
> >> >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
> >><pi...@gmail.com>:
> >> >>
> >> >> > 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
> >><carlosrovira@apache.org
> >> >
> >> >> > wrote:
> >> >> >
> >> >> > > Alex
> >> >> > >
> >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> >> >> > >
> >> >> > > > 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, "carlos.rovira@gmail.com on behalf of
> >>Carlos
> >> >> > > Rovira"
> >> >> > > > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> >> >> 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
> >> >><ca...@apache.org>:
> >> >> > > > >
> >> >> > > > >> 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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ah...@adobe.com.invalid>:
>
>> 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" <pi...@gmail.com> 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 <ca...@apache.org>
>> >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
>><pi...@gmail.com>:
>> >>
>> >> > 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
>><carlosrovira@apache.org
>> >
>> >> > wrote:
>> >> >
>> >> > > Alex
>> >> > >
>> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>> >> > >
>> >> > > > 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, "carlos.rovira@gmail.com on behalf of
>>Carlos
>> >> > > Rovira"
>> >> > > > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>> >> 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
>> >><ca...@apache.org>:
>> >> > > > >
>> >> > > > >> 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=TR5G34hZMVutbPgcwAzTtNlFR0mQb8quhoBewhsOnSc%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
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 <ah...@adobe.com.invalid>:
> 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" <pi...@gmail.com> 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 <ca...@apache.org>
> >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 <pi...@gmail.com>:
> >>
> >> > 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 <carlosrovira@apache.org
> >
> >> > wrote:
> >> >
> >> > > Alex
> >> > >
> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> >> > >
> >> > > > 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, "carlos.rovira@gmail.com on behalf of Carlos
> >> > > Rovira"
> >> > > > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> >> 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
> >><ca...@apache.org>:
> >> > > > >
> >> > > > >> 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=TR5G34hZMVutbPgcwAzTtNlFR0mQb8quhoBewhsOnSc%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%3D&reserved=0
> >>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <pi...@gmail.com> 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 <ca...@apache.org>
>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 <pi...@gmail.com>:
>>
>> > 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 <ca...@apache.org>
>> > wrote:
>> >
>> > > Alex
>> > >
>> > > 2018-04-14 8:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>> > >
>> > > > 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%7Cfa7b1b5a7b34438794aed2c178decee1%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%7Cfa7b1b5a7b34438794aed2c178decee1%7
>>C0%7C0%7C636593199085882368&sdata=ygYm8sTMDTniu1NFzxds3fEaa0e%2FxnNaYxHeO
>>6G3F0g%3D&reserved=0
>> > > >
>> > > > On 4/13/18, 7:18 PM, "carlos.rovira@gmail.com on behalf of Carlos
>> > > Rovira"
>> > > > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>> 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
>><ca...@apache.org>:
>> > > > >
>> > > > >> 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=TR5G34hZMVutbPgcwAzTtNlFR0mQb8quhoBewhsOnSc%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%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=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%3D&reserved=0
>>
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ca...@apache.org> 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 <pi...@gmail.com>:
>
> > 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 <ca...@apache.org>
> > wrote:
> >
> > > Alex
> > >
> > > 2018-04-14 8:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> > >
> > > > 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://measurethat.net/Benchmarks/Show/54/0/
> > > > classname-vs-setattribute-vs-c
> > > > lasslist
> > > > [2] https://jsperf.com/classname-vs-classlist-showdown/5
> > > >
> > > > On 4/13/18, 7:18 PM, "carlos.rovira@gmail.com on behalf of Carlos
> > > Rovira"
> > > > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> 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 <ca...@apache.org>:
> > > > >
> > > > >> 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=TR5G34hZMVutbPgcwAzTtNlFR0mQb8quhoBewhsOnSc%3D&reserved=0
> > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
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 <pi...@gmail.com>:
> 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 <ca...@apache.org>
> wrote:
>
> > Alex
> >
> > 2018-04-14 8:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> > > 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://measurethat.net/Benchmarks/Show/54/0/
> > > classname-vs-setattribute-vs-c
> > > lasslist
> > > [2] https://jsperf.com/classname-vs-classlist-showdown/5
> > >
> > > On 4/13/18, 7:18 PM, "carlos.rovira@gmail.com on behalf of Carlos
> > Rovira"
> > > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ca...@apache.org>:
> > > >
> > > >> 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=TR5G34hZMVutbPgcwAzTtNlFR0mQb8quhoBewhsOnSc%3D&reserved=0
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ca...@apache.org>
wrote:
> Alex
>
> 2018-04-14 8:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>
> > 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://measurethat.net/Benchmarks/Show/54/0/
> > classname-vs-setattribute-vs-c
> > lasslist
> > [2] https://jsperf.com/classname-vs-classlist-showdown/5
> >
> > On 4/13/18, 7:18 PM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ca...@apache.org>:
> > >
> > >> 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=TR5G34hZMVutbPgcwAzTtNlFR0mQb8quhoBewhsOnSc%3D&reserved=0
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Alex
2018-04-14 8:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> 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://measurethat.net/Benchmarks/Show/54/0/
> classname-vs-setattribute-vs-c
> lasslist
> [2] https://jsperf.com/classname-vs-classlist-showdown/5
>
> On 4/13/18, 7:18 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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 <ca...@apache.org>:
> >
> >> 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=TR5G34hZMVutbPgcwAzTtNlFR0mQb8quhoBewhsOnSc%3D&reserved=0
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Carlos,
It seems like either you have missed some of the discussion or maybe we
weren't clear enough.
Simply put:
-The Basic components do not need to handle classList APIs. There is no
expectation that classes will be frequently added and removed.
-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.
-MXML is better with space delimited string lists instead of arrays.
-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.
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.
More comments in-line..
[1]
https://measurethat.net/Benchmarks/Show/54/0/classname-vs-setattribute-vs-c
lasslist
[2] https://jsperf.com/classname-vs-classlist-showdown/5
On 4/13/18, 7:18 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> 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.
>
>
>2018-04-14 2:58 GMT+02:00 Carlos Rovira <ca...@apache.org>:
>
>> 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.
>>
>> 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.
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.
>> 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 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.
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.
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=TR5G34hZMVutbPgcwAzTtNlFR0mQb8quhoBewhsOnSc%3D&reserved=0
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I think the discussion now should center in numbers.
I added "performance.now()" to typedefs (how could we live without this
until now? :))
I added this code to Jewel Button:
public var start;
public var end;
override public function addedToParent():void
{
COMPILE::JS
{
start = performance.now();
}
super.addedToParent();
COMPILE::JS
{
end = performance.now();
var time = end - start;
trace('Button Execution time: ' + time);
}
}
Here's execution on current develop:
Button Execution time: 0.20000000949949026
Language.js:237 Button Execution time: 0
2Language.js:237 Button Execution time: 0.10000000474974513
Language.js:237 Button Execution time: 0.20000000949949026
4Language.js:237 Button Execution time: 0.10000000474974513
Language.js:237 Button Execution time: 0.09999997564591467
Language.js:237 Button Execution time: 0.20000000949949026
Language.js:237 Button Execution time: 0.10000000474974513
Language.js:237 Button Execution time: 0
Language.js:237 Button Execution time: 0
2Language.js:237 Button Execution time: 0.10000000474974513
Here's the execution on "feature/uibase-classname"
Button Execution time: 0.1999999803956598
3Language.js:237 Button Execution time: 0.10000000474974513
Language.js:237 Button Execution time: 0.20000000949949026
2Language.js:237 Button Execution time: 0.10000000474974513
Language.js:237 Button Execution time: 0.1999999803956598
Language.js:237 Button Execution time: 0.20000000949949026
Language.js:237 Button Execution time: 0.10000000474974513
Language.js:237 Button Execution time: 0
2Language.js:237 Button Execution time: 0.10000000474974513
Language.js:237 Button Execution time: 0
Language.js:237 Button Execution time: 0.10000000474974513
Language.js:237 Button Execution time: 0
I think numbers are near identical right?
So given very close numbers should make us choose the more simplest code
right?
Carlos
2018-04-14 2:58 GMT+02:00 Carlos Rovira <ca...@apache.org>:
> 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
>
> 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.
>
> 3) we are introducing a new array property per component to store what
> classList already do
>
> 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...
>
> 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".
>
> 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?
>
> [1] https://github.com/google/material-design-lite/blob/mdl-
> 1.x/src/button/button.js
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
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
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.
3) we are introducing a new array property per component to store what
classList already do
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...
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".
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?
[1] https://github.com/google/material-design-lite/blob/mdl-
1.x/src/button/button.js
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I made some changes to the feature/uibase-classname branch and pushed them.
The only code change in UIBase is to go back to setting element.className
instead of calling addStyles to split the list again.
Mainly I added documentation to UIBase and the classList helper functions
to explain how they interact.
Then I added code to Jewel Button to handle its properties that toggle
styles in the classList.
A key point is understanding the lifecycle. Hopefully, in just about
every instance, the element.className will be set once in addedtoParent
and then properties can toggle styles on the classList and it will just
work.
We could say that you can't set className after addedToParent. That would
simplify the code in Jewel Button that saves the propertyNames to be added
to computeFinalClassNames.
Basically, though, I think this implementation matches the scenarios.
Thoughts?
-Alex
On 4/11/18, 2:37 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi Alex,
>
>to resume,
>
>1) I agree with most of your mail. My main need is to use an API that let
>me add/remove/toggle styles easily (mine and whoever wants to deal with
>styling).
>So if you think my changes to UIBase are not ok and you want to ensure
>things are more as you have in mind, that's ok with me. But to avoid more
>investing time in discussion I prefer wait for you to make the changes in
>the UIBase classname branch. I assume that the way I use it though new
>methods like "addStyles" will not change, and so I can continue my work
>with the rest of components. So in this point I'll wait for you changes if
>is ok for you.
>
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
I think we should move UIBase back into Core. Then maybe it will be more
clear that Basic is just a set of components and not really any more
special than any other set.
IMO, the logic around what to subclass in some other component set is
standard computer science. How much code is being shared, re-used,
overridden, etc. Usability (does there need to be a common base class for
folks mixing component sets (hopefully no, interfaces should be used
instead)). Things like that. So you are best judge of what to subclass
and our users will tell us if they don't like it.
Thanks,
-Alex
On 4/11/18, 1:41 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi Alex,
>
>No, I'm not talking about JewelUIBase. If you do 1), then I'll use that,
>What I say is if you think Jewel Button and the rest of components, should
>extend directly UIBase (and copy paste functionality of the counterpart
>component in Basic if apply), or extend the Basic counterpart.
>I'm for making all Jewel components extends directly UIBase
>
>My question is if you share the same concept
>
>thanks
>
>
>
>2018-04-11 21:33 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>
>>
>> >2) About Jewel UIBase extension: I think is better to always extend
>>UIBase
>> >than the Basic component as a rule. So I'll normalize the current Jewel
>> >components so Basic and Jewel will be siblings and extend from UIBase
>> >instead jewel extend basic and basic UIBase. Let me know if you agree
>>with
>> >me that this is a better decision.
>>
>> I'm not quite sure what you mean here. I don't think Jewel needs its
>>own
>> UIBase. It should be able to use the one in Basic.
>>
>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C250837f2c4404b83d85508d5
>9fecaec3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636590761338123467&s
>data=6CyylVKceFeVVBD0NaTiOfVkUR5CRGLMNBL2SxsemJM%3D&reserved=0
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
No, I'm not talking about JewelUIBase. If you do 1), then I'll use that,
What I say is if you think Jewel Button and the rest of components, should
extend directly UIBase (and copy paste functionality of the counterpart
component in Basic if apply), or extend the Basic counterpart.
I'm for making all Jewel components extends directly UIBase
My question is if you share the same concept
thanks
2018-04-11 21:33 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>
> >2) About Jewel UIBase extension: I think is better to always extend UIBase
> >than the Basic component as a rule. So I'll normalize the current Jewel
> >components so Basic and Jewel will be siblings and extend from UIBase
> >instead jewel extend basic and basic UIBase. Let me know if you agree with
> >me that this is a better decision.
>
> I'm not quite sure what you mean here. I don't think Jewel needs its own
> UIBase. It should be able to use the one in Basic.
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 4/11/18, 2:37 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi Alex,
>
>to resume,
>
>1) I agree with most of your mail. My main need is to use an API that let
>me add/remove/toggle styles easily (mine and whoever wants to deal with
>styling).
>So if you think my changes to UIBase are not ok and you want to ensure
>things are more as you have in mind, that's ok with me. But to avoid more
>investing time in discussion I prefer wait for you to make the changes in
>the UIBase classname branch. I assume that the way I use it though new
>methods like "addStyles" will not change, and so I can continue my work
>with the rest of components. So in this point I'll wait for you changes if
>is ok for you.
OK, I will make the changes after I finish up a few other things.
>
>2) About Jewel UIBase extension: I think is better to always extend UIBase
>than the Basic component as a rule. So I'll normalize the current Jewel
>components so Basic and Jewel will be siblings and extend from UIBase
>instead jewel extend basic and basic UIBase. Let me know if you agree with
>me that this is a better decision.
I'm not quite sure what you mean here. I don't think Jewel needs its own
UIBase. It should be able to use the one in Basic.
>
>3) about separation of styles in CSS, in this part I not agree. I don't
>think is just stylistic code decision, or for me that's not the main
>motivation behind. I think that setting things like, "display", width or
>height or padding in the component class is a bad design choice, since
>you're making that component coupled to that decisions, while here for me
>applys the "separation of concerns" concept.
>Why basic label sets word-wrap in the class instead of in the CSS Label
>rule as with the rest of its beads? For me that's the right place to do
>so.
>For me the class setups the HTML structure (i.e, span, div,...) and wire
>the needed JS, then the CSS should set up all styles and transition
>effects, since is how things works in HTML. I think things like
>"display:none" should be managed, not setting that as is, but to adding a
>class "visible" to the component class list. Is this more/less efficient.
>I
>don't thing it makes any difference in performance, nobody here can said
>that is better through the myriad of browser implementations and its
>different performances, but most important in this case is separation of
>concerns and how we organize the code. since a CSS rule like ".visible"
>used for all components to set display to none or not, makes more reusable
>that code and more easy to deal with that, and then in JS you can make
>that
>and in SWF use a different code.
If it isn't stylistic, then you should be able to provide technical
reasoning including articles on the internet explaining why using styles
object is wrong or inefficient. Every website I look at is using both
classes and the style object directly, even the WordPress generated
royale.a.o. The APIs allow us to use the style object. They allow us to
use classList and/or className. What you want to do appears to be a
preference without any technical justification. There is nothing in
Royale that prevents you from contributing layouts that use classes
instead of the style object.
If you want to discuss about why UIBase.visible=false sets display:none on
the style object, I guess we can have that discussion. To me, using the
style object makes sense so you don't have to worry about other class
selectors with display styles taking precedence.
If you want to discuss about why Label sets wordWrap:none on the style
object, we can have that discussion as well. To me, the reasoning is
similar. You can't control the order of precedence in class selectors,
and the Basic Label should be single line and not have that messed with by
folks editing CSS. You are welcome to create a different Label in Jewel
if you want.
Thanks,
-Alex
>
>
>2018-04-11 7:13 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Hi Carlos,
>>
>> My proposal uses classList, but only where it will be optimal to use it
>> given the scenarios. I think you misunderstood scenario 4. The
>> application developer can certainly cause classes to be added and
>>removed
>> at runtime by manipulating properties on the component like "secondary"
>>or
>> "emphasized", but the actual applying of those styles are done by
>> framework code we write. IMO, other than the components that have the
>> same names as HTMLElements, we want the other Basic components and other
>> Royale components to abstract the underlying browser implementations so
>>if
>> we ever target another platform or output language, we aren't as tied to
>> browser APIs.
>>
>> IMO, the reason there is both a classList and className API on
>>HTMLElement
>> is that it can be more efficient to use one or the other in certain
>> scenarios. Instead of trying to always use classList or always use
>> className, my proposal uses both depending on which will be most
>> efficient, and also presents an abstraction that is backward compatible
>> with Flex and does not tie us to a browser implementation. One key
>>thing
>> to remember is that lots of articles you find on the internet are about
>> working with hand-written JS and CSS. In Royale, we have a component
>> lifecycle and can control when code runs and thus some internet advice
>> does not apply.
>>
>> If you are asking me to code up my proposal so you can see it, I guess I
>> will take the time to do so, or maybe Harbs can do it.
>>
>> Regarding whether Jewel Slider extends Basic Slider, now that I
>>understand
>> what you are saying, that isn't a problem for me. But whether you
>>extend
>> Basic Slider or not, the hope is that both Slider components implement
>>the
>> same pattern: the outer component proxies properties to/from a model or
>> directly to an HTMLElement. And if there is a View, it pulls data from
>> the model.
>>
>> Changes to UIBase probably should result in lengthy discussion to make
>> sure it is truly necessary. UIBase changes will have impact everywhere.
>> We need to consider PAYG, size, performance, usability and more. This
>>is
>> the most important thing to me. I do not want to see us repeat the
>> mistakes of Flex where we just packed the latest idea onto UIComponent
>> until it became 13,000 lines that dragged in all kinds of dependencies.
>>
>> But, IMO, we have to separate technical decisions from stylistic
>> decisions. IMO, your desire to not have any Royale component set a
>>style
>> directly and only add classes is a stylistic decision. I think Harbs
>>has
>> shown that it is less efficient. But if that's how you want to write
>>your
>> code, that's fine. Royale is designed to provide choices. Often there
>>is
>> no one right way.
>>
>> Anyway, let's see if we can get consensus on the changes to UIBase.
>>IMO,
>> that's the only thing we need to agree on. If you still need to see it
>>in
>> code, let us know.
>>
>> Thanks,
>> -Alex
>>
>> On 4/10/18, 2:49 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Hi Alex,
>> >
>> >2018-04-10 21:17 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>> >
>> >> Hi Carlos,
>> >>
>> >> I think I'm still confused. Earlier you said that half of Jewel
>> >> components do not extend Basic components. What do they extend and
>>why?
>> >>
>> >
>> >When I said does not extend Basic components, I mean that doesn't
>>extend
>> >it
>> >counterpart (i.e. Jewel Slider does not extend Basic Slider, since are
>> >very
>> >different), if not extend its counterpart at least extends UIBase
>> >
>> >
>> >>
>> >> I think I have proposed a solution to how we handle classNames that
>> >>should
>> >> work for Jewel, MDL and all other components.
>> >
>> >
>> >I think you refer to the mail with the 4 scenarios. I'm ok with 1,2,3
>>but
>> >not with 4.
>> >For example Button.primary will need to set "primary" class" but as
>>well
>> >remove others
>> >like "secondary" or "emphasized" since only one of them should exists
>>at a
>> >time.
>> >This is the same in MDL. Nowadays all set like MDL uses this a lot,
>>since
>> >all visuals
>> >depends on this things.
>> >
>> >
>> >> I think it would be better
>> >> for Royale to be able to use Jewel theme without a JewelUIBase unless
>> >> there is a really good technical reason.
>> >
>> >
>> >We should get to a consensus to reach this. I really prefer to stick
>>with
>> >UIBase if possible.
>> >
>> >
>> >> I was hoping Jewel really would
>> >> be the replacement of views and HTMLElements in the existing Basic
>> >> components.
>> >>
>> >
>> >the problem with that is that it's making a change in basic is very
>>time
>> >consuming since we all disagree on how to make things. and we have the
>> >following problems:
>> >
>> >1) Basic is now used by people and changes on it can break code. For me
>> >that's ok, since I think we are in 0.9 and change things should be
>>normal,
>> >but then
>> >many of you will oppose to changes, so...
>> >
>> >2) ..this makes each change a discussion that makes us to spend several
>> >hours
>> >
>> >3) in the other hand we want basic to remain basic. that could be ok
>>if we
>> >use views, but in the other hand we need some property methods in the
>> >class
>> >(think in
>> >"primary", "secondary" and "emphasized" in Jewel Button....we can't
>>create
>> >them in basic button, since no body will allow that, so, this makes
>>jewel
>> >themes partially unusable.
>> >
>> >4) the other huge point for me is that I don't understand style code
>>in a
>> >component. For me this is not optional and that is in many Basic code
>>un
>> >components and layouts.
>> >
>> >So I see basic mostly difficult to skin and will be use as you said for
>> >people that doesnt't want any overhead, but that's not my target in
>>this
>> >project, for this reason I doing Jewel.
>> >
>> >Alex, I think classList is a must nowadays in browser space, I already
>> >said
>> >in lots of emails. All great projects use it.
>> >I post a link from MDL that states that one of the things they require
>>in
>> >a
>> >browser (between others) is that support classList.
>> >
>> >But, if you really thing classList is not ok, and you have a better
>> >proposal of an API that allows me to add/remove easily classes at
>>runtime,
>> >I think is better that you implement it in the branch we have,
>>removing my
>> >changes so I can really understand and test it. I think that would be
>> >better for all of us. I posted my proposal. I think you should post
>>yours.
>> >If I try it and works, I'm sure yours will be very efficient, so I
>>think
>> >we
>> >can go with that. But we should not continue discussing without that
>>code
>> >to test, since I see we are doesn't understanding ok one to each other
>> >since maybe you and I are interpreting in our way what the other want
>>to
>> >express.
>> >
>> >For that reason and to avoid another long discussion, my position was
>>to
>> >extend UIBase with classList methods, that we already discussed for
>>long
>> >time in other thread
>> >in this way Basic components will not need classList, but Jewel will
>>need,
>> >since is needed.
>> >
>> >I think we should take a path or another, and to do this and avoid lost
>> >more time in emails, is that you put the few lines of code you thing
>>are
>> >right in a commit in the uibase changes branch, so I can test it
>> >
>> >Let me know what do you think about it
>> >
>> >Thanks
>> >
>> >Carlos
>> >
>> >
>> >
>> >
>> >>
>> >> Thanks,
>> >> -Alex
>> >>
>> >> On 4/10/18, 9:55 AM, "carlos.rovira@gmail.com on behalf of Carlos
>> >>Rovira"
>> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>> >>
>> >> >Hi Alex,
>> >> >
>> >> >Jewel components extends UIBase or the basic version
>> >> >For example
>> >> >Jewel Button extends Basic Button,
>> >> >Jewel TextField extends Basic TextField
>> >> >Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an
>> >>input
>> >> >range and not 2 buttons)
>> >> >
>> >> >the main reason is that majority of basic controls can be what Jewel
>> >>needs
>> >> >except for html needed (we needed structures most like MDL does) and
>> >>need
>> >> >to add some property methods to add / remove CSS rules.
>> >> >
>> >> >That's the main reason behind, in the end is to replicate what I
>>did in
>> >> >MDL
>> >> >but using royale components and our own structure since we define
>>the
>> >> >theme
>> >> >css rule selectors.
>> >> >
>> >> >Hope it make more sense now.
>> >> >
>> >> >thanks
>> >> >
>> >> >Carlos
>> >> >
>> >>
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7C8f1320421992439bea2708d5
>> >9f2cf45e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636589937783626510&s
>> >data=RXcZ%2B5%2FKm1Qoi45eL%2F98yDZAiEuRRnEd841%2B7N9cRek%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%7C1d5fd09f7a684387172f08d5
>9f8ff14c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636590362936479872&s
>data=BtTu1IpNfADxCypNkP9F0uJ%2B%2B3s4dAsaRjIyVjMNytk%3D&reserved=0
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
to resume,
1) I agree with most of your mail. My main need is to use an API that let
me add/remove/toggle styles easily (mine and whoever wants to deal with
styling).
So if you think my changes to UIBase are not ok and you want to ensure
things are more as you have in mind, that's ok with me. But to avoid more
investing time in discussion I prefer wait for you to make the changes in
the UIBase classname branch. I assume that the way I use it though new
methods like "addStyles" will not change, and so I can continue my work
with the rest of components. So in this point I'll wait for you changes if
is ok for you.
2) About Jewel UIBase extension: I think is better to always extend UIBase
than the Basic component as a rule. So I'll normalize the current Jewel
components so Basic and Jewel will be siblings and extend from UIBase
instead jewel extend basic and basic UIBase. Let me know if you agree with
me that this is a better decision.
3) about separation of styles in CSS, in this part I not agree. I don't
think is just stylistic code decision, or for me that's not the main
motivation behind. I think that setting things like, "display", width or
height or padding in the component class is a bad design choice, since
you're making that component coupled to that decisions, while here for me
applys the "separation of concerns" concept.
Why basic label sets word-wrap in the class instead of in the CSS Label
rule as with the rest of its beads? For me that's the right place to do so.
For me the class setups the HTML structure (i.e, span, div,...) and wire
the needed JS, then the CSS should set up all styles and transition
effects, since is how things works in HTML. I think things like
"display:none" should be managed, not setting that as is, but to adding a
class "visible" to the component class list. Is this more/less efficient. I
don't thing it makes any difference in performance, nobody here can said
that is better through the myriad of browser implementations and its
different performances, but most important in this case is separation of
concerns and how we organize the code. since a CSS rule like ".visible"
used for all components to set display to none or not, makes more reusable
that code and more easy to deal with that, and then in JS you can make that
and in SWF use a different code.
2018-04-11 7:13 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> Hi Carlos,
>
> My proposal uses classList, but only where it will be optimal to use it
> given the scenarios. I think you misunderstood scenario 4. The
> application developer can certainly cause classes to be added and removed
> at runtime by manipulating properties on the component like "secondary" or
> "emphasized", but the actual applying of those styles are done by
> framework code we write. IMO, other than the components that have the
> same names as HTMLElements, we want the other Basic components and other
> Royale components to abstract the underlying browser implementations so if
> we ever target another platform or output language, we aren't as tied to
> browser APIs.
>
> IMO, the reason there is both a classList and className API on HTMLElement
> is that it can be more efficient to use one or the other in certain
> scenarios. Instead of trying to always use classList or always use
> className, my proposal uses both depending on which will be most
> efficient, and also presents an abstraction that is backward compatible
> with Flex and does not tie us to a browser implementation. One key thing
> to remember is that lots of articles you find on the internet are about
> working with hand-written JS and CSS. In Royale, we have a component
> lifecycle and can control when code runs and thus some internet advice
> does not apply.
>
> If you are asking me to code up my proposal so you can see it, I guess I
> will take the time to do so, or maybe Harbs can do it.
>
> Regarding whether Jewel Slider extends Basic Slider, now that I understand
> what you are saying, that isn't a problem for me. But whether you extend
> Basic Slider or not, the hope is that both Slider components implement the
> same pattern: the outer component proxies properties to/from a model or
> directly to an HTMLElement. And if there is a View, it pulls data from
> the model.
>
> Changes to UIBase probably should result in lengthy discussion to make
> sure it is truly necessary. UIBase changes will have impact everywhere.
> We need to consider PAYG, size, performance, usability and more. This is
> the most important thing to me. I do not want to see us repeat the
> mistakes of Flex where we just packed the latest idea onto UIComponent
> until it became 13,000 lines that dragged in all kinds of dependencies.
>
> But, IMO, we have to separate technical decisions from stylistic
> decisions. IMO, your desire to not have any Royale component set a style
> directly and only add classes is a stylistic decision. I think Harbs has
> shown that it is less efficient. But if that's how you want to write your
> code, that's fine. Royale is designed to provide choices. Often there is
> no one right way.
>
> Anyway, let's see if we can get consensus on the changes to UIBase. IMO,
> that's the only thing we need to agree on. If you still need to see it in
> code, let us know.
>
> Thanks,
> -Alex
>
> On 4/10/18, 2:49 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi Alex,
> >
> >2018-04-10 21:17 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >> Hi Carlos,
> >>
> >> I think I'm still confused. Earlier you said that half of Jewel
> >> components do not extend Basic components. What do they extend and why?
> >>
> >
> >When I said does not extend Basic components, I mean that doesn't extend
> >it
> >counterpart (i.e. Jewel Slider does not extend Basic Slider, since are
> >very
> >different), if not extend its counterpart at least extends UIBase
> >
> >
> >>
> >> I think I have proposed a solution to how we handle classNames that
> >>should
> >> work for Jewel, MDL and all other components.
> >
> >
> >I think you refer to the mail with the 4 scenarios. I'm ok with 1,2,3 but
> >not with 4.
> >For example Button.primary will need to set "primary" class" but as well
> >remove others
> >like "secondary" or "emphasized" since only one of them should exists at a
> >time.
> >This is the same in MDL. Nowadays all set like MDL uses this a lot, since
> >all visuals
> >depends on this things.
> >
> >
> >> I think it would be better
> >> for Royale to be able to use Jewel theme without a JewelUIBase unless
> >> there is a really good technical reason.
> >
> >
> >We should get to a consensus to reach this. I really prefer to stick with
> >UIBase if possible.
> >
> >
> >> I was hoping Jewel really would
> >> be the replacement of views and HTMLElements in the existing Basic
> >> components.
> >>
> >
> >the problem with that is that it's making a change in basic is very time
> >consuming since we all disagree on how to make things. and we have the
> >following problems:
> >
> >1) Basic is now used by people and changes on it can break code. For me
> >that's ok, since I think we are in 0.9 and change things should be normal,
> >but then
> >many of you will oppose to changes, so...
> >
> >2) ..this makes each change a discussion that makes us to spend several
> >hours
> >
> >3) in the other hand we want basic to remain basic. that could be ok if we
> >use views, but in the other hand we need some property methods in the
> >class
> >(think in
> >"primary", "secondary" and "emphasized" in Jewel Button....we can't create
> >them in basic button, since no body will allow that, so, this makes jewel
> >themes partially unusable.
> >
> >4) the other huge point for me is that I don't understand style code in a
> >component. For me this is not optional and that is in many Basic code un
> >components and layouts.
> >
> >So I see basic mostly difficult to skin and will be use as you said for
> >people that doesnt't want any overhead, but that's not my target in this
> >project, for this reason I doing Jewel.
> >
> >Alex, I think classList is a must nowadays in browser space, I already
> >said
> >in lots of emails. All great projects use it.
> >I post a link from MDL that states that one of the things they require in
> >a
> >browser (between others) is that support classList.
> >
> >But, if you really thing classList is not ok, and you have a better
> >proposal of an API that allows me to add/remove easily classes at runtime,
> >I think is better that you implement it in the branch we have, removing my
> >changes so I can really understand and test it. I think that would be
> >better for all of us. I posted my proposal. I think you should post yours.
> >If I try it and works, I'm sure yours will be very efficient, so I think
> >we
> >can go with that. But we should not continue discussing without that code
> >to test, since I see we are doesn't understanding ok one to each other
> >since maybe you and I are interpreting in our way what the other want to
> >express.
> >
> >For that reason and to avoid another long discussion, my position was to
> >extend UIBase with classList methods, that we already discussed for long
> >time in other thread
> >in this way Basic components will not need classList, but Jewel will need,
> >since is needed.
> >
> >I think we should take a path or another, and to do this and avoid lost
> >more time in emails, is that you put the few lines of code you thing are
> >right in a commit in the uibase changes branch, so I can test it
> >
> >Let me know what do you think about it
> >
> >Thanks
> >
> >Carlos
> >
> >
> >
> >
> >>
> >> Thanks,
> >> -Alex
> >>
> >> On 4/10/18, 9:55 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> >>
> >> >Hi Alex,
> >> >
> >> >Jewel components extends UIBase or the basic version
> >> >For example
> >> >Jewel Button extends Basic Button,
> >> >Jewel TextField extends Basic TextField
> >> >Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an
> >>input
> >> >range and not 2 buttons)
> >> >
> >> >the main reason is that majority of basic controls can be what Jewel
> >>needs
> >> >except for html needed (we needed structures most like MDL does) and
> >>need
> >> >to add some property methods to add / remove CSS rules.
> >> >
> >> >That's the main reason behind, in the end is to replicate what I did in
> >> >MDL
> >> >but using royale components and our own structure since we define the
> >> >theme
> >> >css rule selectors.
> >> >
> >> >Hope it make more sense now.
> >> >
> >> >thanks
> >> >
> >> >Carlos
> >> >
> >>
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C8f1320421992439bea2708d5
> >9f2cf45e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636589937783626510&s
> >data=RXcZ%2B5%2FKm1Qoi45eL%2F98yDZAiEuRRnEd841%2B7N9cRek%3D&reserved=0
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
My proposal uses classList, but only where it will be optimal to use it
given the scenarios. I think you misunderstood scenario 4. The
application developer can certainly cause classes to be added and removed
at runtime by manipulating properties on the component like "secondary" or
"emphasized", but the actual applying of those styles are done by
framework code we write. IMO, other than the components that have the
same names as HTMLElements, we want the other Basic components and other
Royale components to abstract the underlying browser implementations so if
we ever target another platform or output language, we aren't as tied to
browser APIs.
IMO, the reason there is both a classList and className API on HTMLElement
is that it can be more efficient to use one or the other in certain
scenarios. Instead of trying to always use classList or always use
className, my proposal uses both depending on which will be most
efficient, and also presents an abstraction that is backward compatible
with Flex and does not tie us to a browser implementation. One key thing
to remember is that lots of articles you find on the internet are about
working with hand-written JS and CSS. In Royale, we have a component
lifecycle and can control when code runs and thus some internet advice
does not apply.
If you are asking me to code up my proposal so you can see it, I guess I
will take the time to do so, or maybe Harbs can do it.
Regarding whether Jewel Slider extends Basic Slider, now that I understand
what you are saying, that isn't a problem for me. But whether you extend
Basic Slider or not, the hope is that both Slider components implement the
same pattern: the outer component proxies properties to/from a model or
directly to an HTMLElement. And if there is a View, it pulls data from
the model.
Changes to UIBase probably should result in lengthy discussion to make
sure it is truly necessary. UIBase changes will have impact everywhere.
We need to consider PAYG, size, performance, usability and more. This is
the most important thing to me. I do not want to see us repeat the
mistakes of Flex where we just packed the latest idea onto UIComponent
until it became 13,000 lines that dragged in all kinds of dependencies.
But, IMO, we have to separate technical decisions from stylistic
decisions. IMO, your desire to not have any Royale component set a style
directly and only add classes is a stylistic decision. I think Harbs has
shown that it is less efficient. But if that's how you want to write your
code, that's fine. Royale is designed to provide choices. Often there is
no one right way.
Anyway, let's see if we can get consensus on the changes to UIBase. IMO,
that's the only thing we need to agree on. If you still need to see it in
code, let us know.
Thanks,
-Alex
On 4/10/18, 2:49 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi Alex,
>
>2018-04-10 21:17 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Hi Carlos,
>>
>> I think I'm still confused. Earlier you said that half of Jewel
>> components do not extend Basic components. What do they extend and why?
>>
>
>When I said does not extend Basic components, I mean that doesn't extend
>it
>counterpart (i.e. Jewel Slider does not extend Basic Slider, since are
>very
>different), if not extend its counterpart at least extends UIBase
>
>
>>
>> I think I have proposed a solution to how we handle classNames that
>>should
>> work for Jewel, MDL and all other components.
>
>
>I think you refer to the mail with the 4 scenarios. I'm ok with 1,2,3 but
>not with 4.
>For example Button.primary will need to set "primary" class" but as well
>remove others
>like "secondary" or "emphasized" since only one of them should exists at a
>time.
>This is the same in MDL. Nowadays all set like MDL uses this a lot, since
>all visuals
>depends on this things.
>
>
>> I think it would be better
>> for Royale to be able to use Jewel theme without a JewelUIBase unless
>> there is a really good technical reason.
>
>
>We should get to a consensus to reach this. I really prefer to stick with
>UIBase if possible.
>
>
>> I was hoping Jewel really would
>> be the replacement of views and HTMLElements in the existing Basic
>> components.
>>
>
>the problem with that is that it's making a change in basic is very time
>consuming since we all disagree on how to make things. and we have the
>following problems:
>
>1) Basic is now used by people and changes on it can break code. For me
>that's ok, since I think we are in 0.9 and change things should be normal,
>but then
>many of you will oppose to changes, so...
>
>2) ..this makes each change a discussion that makes us to spend several
>hours
>
>3) in the other hand we want basic to remain basic. that could be ok if we
>use views, but in the other hand we need some property methods in the
>class
>(think in
>"primary", "secondary" and "emphasized" in Jewel Button....we can't create
>them in basic button, since no body will allow that, so, this makes jewel
>themes partially unusable.
>
>4) the other huge point for me is that I don't understand style code in a
>component. For me this is not optional and that is in many Basic code un
>components and layouts.
>
>So I see basic mostly difficult to skin and will be use as you said for
>people that doesnt't want any overhead, but that's not my target in this
>project, for this reason I doing Jewel.
>
>Alex, I think classList is a must nowadays in browser space, I already
>said
>in lots of emails. All great projects use it.
>I post a link from MDL that states that one of the things they require in
>a
>browser (between others) is that support classList.
>
>But, if you really thing classList is not ok, and you have a better
>proposal of an API that allows me to add/remove easily classes at runtime,
>I think is better that you implement it in the branch we have, removing my
>changes so I can really understand and test it. I think that would be
>better for all of us. I posted my proposal. I think you should post yours.
>If I try it and works, I'm sure yours will be very efficient, so I think
>we
>can go with that. But we should not continue discussing without that code
>to test, since I see we are doesn't understanding ok one to each other
>since maybe you and I are interpreting in our way what the other want to
>express.
>
>For that reason and to avoid another long discussion, my position was to
>extend UIBase with classList methods, that we already discussed for long
>time in other thread
>in this way Basic components will not need classList, but Jewel will need,
>since is needed.
>
>I think we should take a path or another, and to do this and avoid lost
>more time in emails, is that you put the few lines of code you thing are
>right in a commit in the uibase changes branch, so I can test it
>
>Let me know what do you think about it
>
>Thanks
>
>Carlos
>
>
>
>
>>
>> Thanks,
>> -Alex
>>
>> On 4/10/18, 9:55 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Hi Alex,
>> >
>> >Jewel components extends UIBase or the basic version
>> >For example
>> >Jewel Button extends Basic Button,
>> >Jewel TextField extends Basic TextField
>> >Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an
>>input
>> >range and not 2 buttons)
>> >
>> >the main reason is that majority of basic controls can be what Jewel
>>needs
>> >except for html needed (we needed structures most like MDL does) and
>>need
>> >to add some property methods to add / remove CSS rules.
>> >
>> >That's the main reason behind, in the end is to replicate what I did in
>> >MDL
>> >but using royale components and our own structure since we define the
>> >theme
>> >css rule selectors.
>> >
>> >Hope it make more sense now.
>> >
>> >thanks
>> >
>> >Carlos
>> >
>>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8f1320421992439bea2708d5
>9f2cf45e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636589937783626510&s
>data=RXcZ%2B5%2FKm1Qoi45eL%2F98yDZAiEuRRnEd841%2B7N9cRek%3D&reserved=0
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
2018-04-10 21:17 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> Hi Carlos,
>
> I think I'm still confused. Earlier you said that half of Jewel
> components do not extend Basic components. What do they extend and why?
>
When I said does not extend Basic components, I mean that doesn't extend it
counterpart (i.e. Jewel Slider does not extend Basic Slider, since are very
different), if not extend its counterpart at least extends UIBase
>
> I think I have proposed a solution to how we handle classNames that should
> work for Jewel, MDL and all other components.
I think you refer to the mail with the 4 scenarios. I'm ok with 1,2,3 but
not with 4.
For example Button.primary will need to set "primary" class" but as well
remove others
like "secondary" or "emphasized" since only one of them should exists at a
time.
This is the same in MDL. Nowadays all set like MDL uses this a lot, since
all visuals
depends on this things.
> I think it would be better
> for Royale to be able to use Jewel theme without a JewelUIBase unless
> there is a really good technical reason.
We should get to a consensus to reach this. I really prefer to stick with
UIBase if possible.
> I was hoping Jewel really would
> be the replacement of views and HTMLElements in the existing Basic
> components.
>
the problem with that is that it's making a change in basic is very time
consuming since we all disagree on how to make things. and we have the
following problems:
1) Basic is now used by people and changes on it can break code. For me
that's ok, since I think we are in 0.9 and change things should be normal,
but then
many of you will oppose to changes, so...
2) ..this makes each change a discussion that makes us to spend several
hours
3) in the other hand we want basic to remain basic. that could be ok if we
use views, but in the other hand we need some property methods in the class
(think in
"primary", "secondary" and "emphasized" in Jewel Button....we can't create
them in basic button, since no body will allow that, so, this makes jewel
themes partially unusable.
4) the other huge point for me is that I don't understand style code in a
component. For me this is not optional and that is in many Basic code un
components and layouts.
So I see basic mostly difficult to skin and will be use as you said for
people that doesnt't want any overhead, but that's not my target in this
project, for this reason I doing Jewel.
Alex, I think classList is a must nowadays in browser space, I already said
in lots of emails. All great projects use it.
I post a link from MDL that states that one of the things they require in a
browser (between others) is that support classList.
But, if you really thing classList is not ok, and you have a better
proposal of an API that allows me to add/remove easily classes at runtime,
I think is better that you implement it in the branch we have, removing my
changes so I can really understand and test it. I think that would be
better for all of us. I posted my proposal. I think you should post yours.
If I try it and works, I'm sure yours will be very efficient, so I think we
can go with that. But we should not continue discussing without that code
to test, since I see we are doesn't understanding ok one to each other
since maybe you and I are interpreting in our way what the other want to
express.
For that reason and to avoid another long discussion, my position was to
extend UIBase with classList methods, that we already discussed for long
time in other thread
in this way Basic components will not need classList, but Jewel will need,
since is needed.
I think we should take a path or another, and to do this and avoid lost
more time in emails, is that you put the few lines of code you thing are
right in a commit in the uibase changes branch, so I can test it
Let me know what do you think about it
Thanks
Carlos
>
> Thanks,
> -Alex
>
> On 4/10/18, 9:55 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi Alex,
> >
> >Jewel components extends UIBase or the basic version
> >For example
> >Jewel Button extends Basic Button,
> >Jewel TextField extends Basic TextField
> >Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an input
> >range and not 2 buttons)
> >
> >the main reason is that majority of basic controls can be what Jewel needs
> >except for html needed (we needed structures most like MDL does) and need
> >to add some property methods to add / remove CSS rules.
> >
> >That's the main reason behind, in the end is to replicate what I did in
> >MDL
> >but using royale components and our own structure since we define the
> >theme
> >css rule selectors.
> >
> >Hope it make more sense now.
> >
> >thanks
> >
> >Carlos
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
I think I'm still confused. Earlier you said that half of Jewel
components do not extend Basic components. What do they extend and why?
I think I have proposed a solution to how we handle classNames that should
work for Jewel, MDL and all other components. I think it would be better
for Royale to be able to use Jewel theme without a JewelUIBase unless
there is a really good technical reason. I was hoping Jewel really would
be the replacement of views and HTMLElements in the existing Basic
components.
Thanks,
-Alex
On 4/10/18, 9:55 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi Alex,
>
>Jewel components extends UIBase or the basic version
>For example
>Jewel Button extends Basic Button,
>Jewel TextField extends Basic TextField
>Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an input
>range and not 2 buttons)
>
>the main reason is that majority of basic controls can be what Jewel needs
>except for html needed (we needed structures most like MDL does) and need
>to add some property methods to add / remove CSS rules.
>
>That's the main reason behind, in the end is to replicate what I did in
>MDL
>but using royale components and our own structure since we define the
>theme
>css rule selectors.
>
>Hope it make more sense now.
>
>thanks
>
>Carlos
>
>
>
>
>2018-04-10 18:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Hi Carlos,
>>
>> I'm not sure if it is better for Jewel to extend from UIBase or not. I
>> just want to understand the technical reasons why you decided not to
>> extend UIBase. We want to make sure UIBase works for as many people as
>> possible, but on the other hand, I wouldn't mind proving that the
>> framework doesn't require org.apache.royale.core.UIBase. Hopefully the
>> framework uses IUIBase instead. It should be ok for someone to come up
>> with a completely different base class as long as it conforms to IUIBase
>> and other interfaces.
>>
>> Thanks,
>> -Alex
>>
>> On 4/10/18, 8:54 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Hi Alex,
>> >
>> >the plan was to reuse as much as I can basic functionality. You think
>>is
>> >better to extend directly from UIBase? (In this case JewelUIBase)
>> >If you think is better, then I'll go that path and we can UIBase
>> >untouched.
>> >
>> >thanks
>> >
>> >2018-04-10 17:15 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>> >
>> >> Why are Jewel components not extending UIBase?
>> >>
>> >> On 4/10/18, 3:45 AM, "carlos.rovira@gmail.com on behalf of Carlos
>> >>Rovira"
>> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>> >>
>> >> >Hi
>> >> >
>> >> >I think we can take another approach. Since I'm finding that half of
>> >>Jewel
>> >> >components are not extending basic components for one reason or
>> >>another,
>> >> >maybe a good option would be:
>> >> >
>> >> >1.- Left UIBase untouched
>> >> >
>> >> >2.- Make JewelUIBase that extends UIBase, and introduced that code
>> >> >
>> >> >3.- Refactor Jewel components to use JewelUIBase
>> >> >
>> >> >In this way Basic, and other sets will remain untouched and not
>> >>affected
>> >> >by
>> >> >this change
>> >> >
>> >> >Let me know what do you think about it.
>> >> >
>> >> >Thanks
>> >> >
>> >> >
>> >> >2018-04-10 9:11 GMT+02:00 Harbs <ha...@gmail.com>:
>> >> >
>> >> >> The article you linked to was a very old article. I already
>> >>responded to
>> >> >> that. I would need some tests to prove that it’s still true today.
>> >>The
>> >> >> tests that I saw seemed to indicate that it wasn’t.
>> >> >>
>> >> >> Philosophically, I think you are tying the behavior of UIBase too
>> >> >>closely
>> >> >> with the thinking behind Jewel which relies very heavily on class
>> >>names
>> >> >>and
>> >> >> requires that users do not change that. I don’t think that’s going
>> >>to be
>> >> >> true for every component set.
>> >> >>
>> >> >> I completely agree with Alex’s response.
>> >> >>
>> >> >> My $0.02,
>> >> >> Harbs
>> >> >>
>> >> >> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira
>> >><ca...@apache.org>
>> >> >> wrote:
>> >> >> >
>> >> >> > Harbs,
>> >> >> >
>> >> >> > I though I did it. I give links to peformance links that for me
>> >>proved
>> >> >> that
>> >> >> > people is going through classList.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >Carlos Rovira
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> http%3A%2F%2Fabout.me%2
>> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> >> 7Cdaafba5ff16a4a20856508d5
>> >> >9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >> 7C636589539427581762&s
>> >> >data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%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%
>> 7C94ea37bd6a1546511d8208d5
>> >9efb78b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636589725255561689&s
>> >data=rjHuwyQi0bB9d%2Fg3dfZwUnKO6Pcgdv9WDkDduUxoBi8%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%7C0b9d443224434c0f901108d5
>9f03dcfa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636589761314845249&s
>data=p3KzCEOtVSgnaoIWAc9PPyyVUwc04489PQATkrurTLo%3D&reserved=0
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
Jewel components extends UIBase or the basic version
For example
Jewel Button extends Basic Button,
Jewel TextField extends Basic TextField
Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an input
range and not 2 buttons)
the main reason is that majority of basic controls can be what Jewel needs
except for html needed (we needed structures most like MDL does) and need
to add some property methods to add / remove CSS rules.
That's the main reason behind, in the end is to replicate what I did in MDL
but using royale components and our own structure since we define the theme
css rule selectors.
Hope it make more sense now.
thanks
Carlos
2018-04-10 18:41 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> Hi Carlos,
>
> I'm not sure if it is better for Jewel to extend from UIBase or not. I
> just want to understand the technical reasons why you decided not to
> extend UIBase. We want to make sure UIBase works for as many people as
> possible, but on the other hand, I wouldn't mind proving that the
> framework doesn't require org.apache.royale.core.UIBase. Hopefully the
> framework uses IUIBase instead. It should be ok for someone to come up
> with a completely different base class as long as it conforms to IUIBase
> and other interfaces.
>
> Thanks,
> -Alex
>
> On 4/10/18, 8:54 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi Alex,
> >
> >the plan was to reuse as much as I can basic functionality. You think is
> >better to extend directly from UIBase? (In this case JewelUIBase)
> >If you think is better, then I'll go that path and we can UIBase
> >untouched.
> >
> >thanks
> >
> >2018-04-10 17:15 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >> Why are Jewel components not extending UIBase?
> >>
> >> On 4/10/18, 3:45 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> >>
> >> >Hi
> >> >
> >> >I think we can take another approach. Since I'm finding that half of
> >>Jewel
> >> >components are not extending basic components for one reason or
> >>another,
> >> >maybe a good option would be:
> >> >
> >> >1.- Left UIBase untouched
> >> >
> >> >2.- Make JewelUIBase that extends UIBase, and introduced that code
> >> >
> >> >3.- Refactor Jewel components to use JewelUIBase
> >> >
> >> >In this way Basic, and other sets will remain untouched and not
> >>affected
> >> >by
> >> >this change
> >> >
> >> >Let me know what do you think about it.
> >> >
> >> >Thanks
> >> >
> >> >
> >> >2018-04-10 9:11 GMT+02:00 Harbs <ha...@gmail.com>:
> >> >
> >> >> The article you linked to was a very old article. I already
> >>responded to
> >> >> that. I would need some tests to prove that it’s still true today.
> >>The
> >> >> tests that I saw seemed to indicate that it wasn’t.
> >> >>
> >> >> Philosophically, I think you are tying the behavior of UIBase too
> >> >>closely
> >> >> with the thinking behind Jewel which relies very heavily on class
> >>names
> >> >>and
> >> >> requires that users do not change that. I don’t think that’s going
> >>to be
> >> >> true for every component set.
> >> >>
> >> >> I completely agree with Alex’s response.
> >> >>
> >> >> My $0.02,
> >> >> Harbs
> >> >>
> >> >> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira
> >><ca...@apache.org>
> >> >> wrote:
> >> >> >
> >> >> > Harbs,
> >> >> >
> >> >> > I though I did it. I give links to peformance links that for me
> >>proved
> >> >> that
> >> >> > people is going through classList.
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> 7Cdaafba5ff16a4a20856508d5
> >> >9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636589539427581762&s
> >> >data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%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%
> 7C94ea37bd6a1546511d8208d5
> >9efb78b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636589725255561689&s
> >data=rjHuwyQi0bB9d%2Fg3dfZwUnKO6Pcgdv9WDkDduUxoBi8%3D&reserved=0
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
I'm not sure if it is better for Jewel to extend from UIBase or not. I
just want to understand the technical reasons why you decided not to
extend UIBase. We want to make sure UIBase works for as many people as
possible, but on the other hand, I wouldn't mind proving that the
framework doesn't require org.apache.royale.core.UIBase. Hopefully the
framework uses IUIBase instead. It should be ok for someone to come up
with a completely different base class as long as it conforms to IUIBase
and other interfaces.
Thanks,
-Alex
On 4/10/18, 8:54 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi Alex,
>
>the plan was to reuse as much as I can basic functionality. You think is
>better to extend directly from UIBase? (In this case JewelUIBase)
>If you think is better, then I'll go that path and we can UIBase
>untouched.
>
>thanks
>
>2018-04-10 17:15 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Why are Jewel components not extending UIBase?
>>
>> On 4/10/18, 3:45 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Hi
>> >
>> >I think we can take another approach. Since I'm finding that half of
>>Jewel
>> >components are not extending basic components for one reason or
>>another,
>> >maybe a good option would be:
>> >
>> >1.- Left UIBase untouched
>> >
>> >2.- Make JewelUIBase that extends UIBase, and introduced that code
>> >
>> >3.- Refactor Jewel components to use JewelUIBase
>> >
>> >In this way Basic, and other sets will remain untouched and not
>>affected
>> >by
>> >this change
>> >
>> >Let me know what do you think about it.
>> >
>> >Thanks
>> >
>> >
>> >2018-04-10 9:11 GMT+02:00 Harbs <ha...@gmail.com>:
>> >
>> >> The article you linked to was a very old article. I already
>>responded to
>> >> that. I would need some tests to prove that it’s still true today.
>>The
>> >> tests that I saw seemed to indicate that it wasn’t.
>> >>
>> >> Philosophically, I think you are tying the behavior of UIBase too
>> >>closely
>> >> with the thinking behind Jewel which relies very heavily on class
>>names
>> >>and
>> >> requires that users do not change that. I don’t think that’s going
>>to be
>> >> true for every component set.
>> >>
>> >> I completely agree with Alex’s response.
>> >>
>> >> My $0.02,
>> >> Harbs
>> >>
>> >> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira
>><ca...@apache.org>
>> >> wrote:
>> >> >
>> >> > Harbs,
>> >> >
>> >> > I though I did it. I give links to peformance links that for me
>>proved
>> >> that
>> >> > people is going through classList.
>> >>
>> >>
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7Cdaafba5ff16a4a20856508d5
>> >9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636589539427581762&s
>> >data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%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%7C94ea37bd6a1546511d8208d5
>9efb78b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636589725255561689&s
>data=rjHuwyQi0bB9d%2Fg3dfZwUnKO6Pcgdv9WDkDduUxoBi8%3D&reserved=0
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
the plan was to reuse as much as I can basic functionality. You think is
better to extend directly from UIBase? (In this case JewelUIBase)
If you think is better, then I'll go that path and we can UIBase untouched.
thanks
2018-04-10 17:15 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> Why are Jewel components not extending UIBase?
>
> On 4/10/18, 3:45 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi
> >
> >I think we can take another approach. Since I'm finding that half of Jewel
> >components are not extending basic components for one reason or another,
> >maybe a good option would be:
> >
> >1.- Left UIBase untouched
> >
> >2.- Make JewelUIBase that extends UIBase, and introduced that code
> >
> >3.- Refactor Jewel components to use JewelUIBase
> >
> >In this way Basic, and other sets will remain untouched and not affected
> >by
> >this change
> >
> >Let me know what do you think about it.
> >
> >Thanks
> >
> >
> >2018-04-10 9:11 GMT+02:00 Harbs <ha...@gmail.com>:
> >
> >> The article you linked to was a very old article. I already responded to
> >> that. I would need some tests to prove that it’s still true today. The
> >> tests that I saw seemed to indicate that it wasn’t.
> >>
> >> Philosophically, I think you are tying the behavior of UIBase too
> >>closely
> >> with the thinking behind Jewel which relies very heavily on class names
> >>and
> >> requires that users do not change that. I don’t think that’s going to be
> >> true for every component set.
> >>
> >> I completely agree with Alex’s response.
> >>
> >> My $0.02,
> >> Harbs
> >>
> >> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira <ca...@apache.org>
> >> wrote:
> >> >
> >> > Harbs,
> >> >
> >> > I though I did it. I give links to peformance links that for me proved
> >> that
> >> > people is going through classList.
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7Cdaafba5ff16a4a20856508d5
> >9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636589539427581762&s
> >data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%3D&reserved=0
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Why are Jewel components not extending UIBase?
On 4/10/18, 3:45 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi
>
>I think we can take another approach. Since I'm finding that half of Jewel
>components are not extending basic components for one reason or another,
>maybe a good option would be:
>
>1.- Left UIBase untouched
>
>2.- Make JewelUIBase that extends UIBase, and introduced that code
>
>3.- Refactor Jewel components to use JewelUIBase
>
>In this way Basic, and other sets will remain untouched and not affected
>by
>this change
>
>Let me know what do you think about it.
>
>Thanks
>
>
>2018-04-10 9:11 GMT+02:00 Harbs <ha...@gmail.com>:
>
>> The article you linked to was a very old article. I already responded to
>> that. I would need some tests to prove that it’s still true today. The
>> tests that I saw seemed to indicate that it wasn’t.
>>
>> Philosophically, I think you are tying the behavior of UIBase too
>>closely
>> with the thinking behind Jewel which relies very heavily on class names
>>and
>> requires that users do not change that. I don’t think that’s going to be
>> true for every component set.
>>
>> I completely agree with Alex’s response.
>>
>> My $0.02,
>> Harbs
>>
>> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira <ca...@apache.org>
>> wrote:
>> >
>> > Harbs,
>> >
>> > I though I did it. I give links to peformance links that for me proved
>> that
>> > people is going through classList.
>>
>>
>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdaafba5ff16a4a20856508d5
>9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636589539427581762&s
>data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%3D&reserved=0
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Hi
I think we can take another approach. Since I'm finding that half of Jewel
components are not extending basic components for one reason or another,
maybe a good option would be:
1.- Left UIBase untouched
2.- Make JewelUIBase that extends UIBase, and introduced that code
3.- Refactor Jewel components to use JewelUIBase
In this way Basic, and other sets will remain untouched and not affected by
this change
Let me know what do you think about it.
Thanks
2018-04-10 9:11 GMT+02:00 Harbs <ha...@gmail.com>:
> The article you linked to was a very old article. I already responded to
> that. I would need some tests to prove that it’s still true today. The
> tests that I saw seemed to indicate that it wasn’t.
>
> Philosophically, I think you are tying the behavior of UIBase too closely
> with the thinking behind Jewel which relies very heavily on class names and
> requires that users do not change that. I don’t think that’s going to be
> true for every component set.
>
> I completely agree with Alex’s response.
>
> My $0.02,
> Harbs
>
> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Harbs,
> >
> > I though I did it. I give links to peformance links that for me proved
> that
> > people is going through classList.
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Harbs <ha...@gmail.com>.
The article you linked to was a very old article. I already responded to that. I would need some tests to prove that it’s still true today. The tests that I saw seemed to indicate that it wasn’t.
Philosophically, I think you are tying the behavior of UIBase too closely with the thinking behind Jewel which relies very heavily on class names and requires that users do not change that. I don’t think that’s going to be true for every component set.
I completely agree with Alex’s response.
My $0.02,
Harbs
> On Apr 10, 2018, at 12:50 AM, Carlos Rovira <ca...@apache.org> wrote:
>
> Harbs,
>
> I though I did it. I give links to peformance links that for me proved that
> people is going through classList.
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I spent some time reviewing the code and email thread.
My current thinking is that we have to agree on the scenarios first and
then the code. Here's what I think the scenarios are:
1) Just about every UIBase is going to set className at initialization
time.
2) A significant percentage of UIBase instances are going to set className
to more than one class name.
3) Some components will want to add and remove classes at runtime.
4) Relatively fewapplication developers will want to manipulate the list
of classes at runtime.
If I understand the jsperf data, if you have to set the class name list to
3 classes, you should set className to a single string containing the 3
class names (htmlElement.className = "foo bar baz"), as opposed to making
3 calls to classList.add or 3 calls to append a new string to className.
I suspect that is because each of the 3 calls causes the browser to start
running code since it can't know if there is yet another call to change
the classes coming. I'm not sure the test showed the cost of setting
classList once to an array of 3 strings.
So, if you agree on the scenarios, then the proposed code isn't quite
right. We shouldn't spend time splitting a string or checking for spaces
which is what addStyles would end up doing too often. We know in the
UIBase lifecycle when we are going to set className for the first time and
if we assume it will often have more than one class name, we should just
set htmlElement.className to the space-delimited string at that one point
in addedToParent.
Then the next question is how to handle changes at runtime. One idea is
to make sure our APIs lead the developer to avoid requiring the
recomputing of an array or space delimited string. So a utility function
like addStyle might just directly call classList.add and not bother to
check for multiple strings. The doc for it would say that it is good for
adding a class at runtime that isn't going to be removed later. Then
another API like addRemovableStyle or something like that would use
classList.toggle as would a removeStyle call. The doc for those two would
explain that they work as a pair. Then maybe we can even document that
folks shouldn't set className at runtime.
Those are my thoughts for now.
-Alex
On 4/9/18, 2:50 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Harbs,
>
>I though I did it. I give links to peformance links that for me proved
>that
>people is going through classList. If you read that Alex, replied that for
>him that kind of tests was not reflecting our use case, but, for me we
>should separate the performance of classList, from how we use classList.
>For tat reason Alex ask me to make a series of changes, that mostly I put
>on that change. Don't know if those are all the changes or not. That's why
>I'm asking Alex. I was assuming that since you didn't comment about that
>you were ok with the perf test I put.
>
>In the other hand, today I put the following link [1] about MDL browser
>support, if you read carefully that section, they stands for
>
>"For components, at minimum we require support for querySelector
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelope
>r.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FAPI%2FDocument%2FquerySelector&data=0
>2%7C01%7Caharui%40adobe.com%7C93cc1daba80a46f7a4e808d59e63f4f8%7Cfa7b1b5a7
>b34438794aed2c178decee1%7C0%7C0%7C636589074514678949&sdata=tTJ8RMLtPhIC6LC
>D9AyB68IhknIgzIssCFiFf7B0XvA%3D&reserved=0>,
>classList
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelope
>r.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FAPI%2FElement%2FclassList&data=02%7C0
>1%7Caharui%40adobe.com%7C93cc1daba80a46f7a4e808d59e63f4f8%7Cfa7b1b5a7b3443
>8794aed2c178decee1%7C0%7C0%7C636589074514678949&sdata=ywDL3LljN1iIbKBQx%2B
>p4EIhnt8L0YgQJVngH7Yd08%2Bo%3D&reserved=0> and
>addEventListener
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelope
>r.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FAPI%2FEventTarget%2FaddEventListener&
>data=02%7C01%7Caharui%40adobe.com%7C93cc1daba80a46f7a4e808d59e63f4f8%7Cfa7
>b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636589074514678949&sdata=kPxhGfAX9
>AiRO67k8WX8Zv8M8H0hB%2BKcl766soxsW3E%3D&reserved=0>,
>which can be polyfilled
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>om%2FModernizr%2FModernizr%2Fwiki%2FHTML5-Cross-Browser-Polyfills&data=02%
>7C01%7Caharui%40adobe.com%7C93cc1daba80a46f7a4e808d59e63f4f8%7Cfa7b1b5a7b3
>4438794aed2c178decee1%7C0%7C0%7C636589074514678949&sdata=ecispJmJK3vZHTaKy
>KsC4Fm8aQ2hKzTiL%2FIXWHtDG%2BU%3D&reserved=0> as
>needed. "
>
>So, even MDL, that is designed with performance in mind uses classList at
>his core. So what can I say more about this issue? I think instead you
>didn't put real numbers about why should not use classList and only a fear
>that it could be worse in performance when I demonstrated classList is not
>a problem, maybe the way I put it on place, that is what Alex should
>check.
>
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetmdl.io
>%2Ffaq%2Findex.html%23browser-support&data=02%7C01%7Caharui%40adobe.com%7C
>93cc1daba80a46f7a4e808d59e63f4f8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C
>0%7C63658907514678949&sdata=Hn7O76EHLGkZfnMQmwMY%2FLl6lmBYlIMDoK2CT%2FvlT
>to%3D&reserved=0
>
>
>
>
>2018-04-09 21:09 GMT+02:00 Harbs <ha...@gmail.com>:
>
>> This is a huge functional change. I don’t know that I really agree with
>> this.
>>
>> You really haven’t answered my comments about the performance
>> implications. I previously linked to jsperf tests. According to recent
>> tests, addStyle seems to perform much more poorly that changing the
>> className.
>>
>> > On Apr 9, 2018, at 9:49 PM, Carlos Rovira <ca...@apache.org>
>> wrote:
>> >
>> > Hi,
>> >
>> > this branch has the UIBase modifications that I made in Jewel. I
>>think is
>> > time to complete the change so:
>> >
>> > @Alex: Can you take a look at the diff and see if you are ok with it?
>>I
>> > think I do this with the considerations we discussed some weeks ago,
>>but
>> I
>> > think you never saw if that was finaly what you suggested.
>> >
>> > @Piotr: I think MDL is the project that needs to see how tis changes
>> > affect it. Since you're the one who are maintaining it, can you check
>>it
>> > and make the modifications in this branch needed? As we have no more
>> > MDLExamples it would be a problem for me to bring that code and see
>>it.
>> >
>> > I see some other examples (like the other day fixing databinding flat)
>> and
>> > seems to work ok since the rest are mainly royale components,
>> >
>> > I'd like to make this for 0.9.3 if possible to make Jewel as stable as
>> > possible
>> >
>> > Thanks
>> >
>> > Carlos
>> >
>> >
>> > 2018-04-09 20:41 GMT+02:00 <ca...@apache.org>:
>> >
>> >> This is an automated email from the ASF dual-hosted git repository.
>> >>
>> >> carlosrovira pushed a commit to branch feature/uibase-classname
>> >> in repository
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.a
>>pache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.c
>>om%7C93cc1daba80a46f7a4e808d59e63f4f8%7Cfa7b1b5a7b34438794aed2c178decee1%
>>7C0%7C0%7C636589074514678949&sdata=%2FqAUbFRGqk%2FRH20iqHjNR5LVwmQpI0x%2F
>>72r5B1kl6qc%3D&reserved=0
>> >>
>> >> commit cf06ede63e3e794198fd68e8647e9c6eceae383d
>> >> Author: Carlos Rovira <ca...@apache.org>
>> >> AuthorDate: Mon Apr 9 20:41:48 2018 +0200
>> >>
>> >> UIBase className changes to support new cssclassList class methods
>> >> like addStyles
>> >> ---
>> >> .../main/royale/org/apache/royale/core/UIBase.as | 18 +-
>> >> .../main/royale/org/apache/royale/core/UIBase.as | 1628
>> >> --------------------
>> >> 2 files changed, 9 insertions(+), 1637 deletions(-)
>> >>
>> >> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> >> b/frameworks/projects/Basic/src/main/royale/org/apache/
>> >> royale/core/UIBase.as
>> >> index b5f4dd1..f59d7f0 100644
>> >> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>> >> royale/core/UIBase.as
>> >> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
>> >> royale/core/UIBase.as
>> >> @@ -37,6 +37,7 @@ package org.apache.royale.core
>> >> {
>> >> import org.apache.royale.html.util.addElementToWrapper;
>> >> import org.apache.royale.utils.CSSUtils;
>> >> + import org.apache.royale.utils.cssclasslist.addStyles;
>> >> }
>> >>
>> >> /**
>> >> @@ -1085,11 +1086,13 @@ package org.apache.royale.core
>> >> {
>> >> if (_className !== value)
>> >> {
>> >> + _className = value;
>> >> +
>> >> COMPILE::JS
>> >> {
>> >> - setClassName(typeNames ? StringUtil.trim(value
>>+ '
>> '
>> >> + typeNames) : value);
>> >> + setClassName(computeFinalClassNames());
>> >> }
>> >> - _className = value;
>> >> +
>> >> dispatchEvent(new Event("classNameChanged"));
>> >> }
>> >> }
>> >> @@ -1097,13 +1100,13 @@ package org.apache.royale.core
>> >> COMPILE::JS
>> >> protected function computeFinalClassNames():String
>> >> {
>> >> - return (_className ? _className + " " : "") +
>>(typeNames ?
>> >> typeNames : "");
>> >> + return StringUtil.trim((_className ? _className : "")
>>+ "
>> "
>> >> + (typeNames ? typeNames : ""));
>> >> }
>> >>
>> >> COMPILE::JS
>> >> protected function setClassName(value:String):void
>> >> {
>> >> - element.className = value;
>> >> + addStyles(element, value);
>> >> }
>> >>
>> >> /**
>> >> @@ -1394,11 +1397,8 @@ package org.apache.royale.core
>> >>
>> >> COMPILE::JS
>> >> {
>> >> - if (typeNames)
>> >> - {
>> >> - setClassName(computeFinalClassNames());
>> >> - }
>> >> -
>> >> + setClassName(computeFinalClassNames());
>> >> +
>> >> if (style)
>> >> ValuesManager.valuesImpl.applyStyles(this,
>>style);
>> >> }
>> >> diff --git a/frameworks/projects/Jewel/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> >> b/frameworks/projects/Jewel/src/main/royale/org/apache/
>> >> royale/core/UIBase.as
>> >> deleted file mode 100644
>> >> index f59d7f0..0000000
>> >> --- a/frameworks/projects/Jewel/src/main/royale/org/apache/
>> >> royale/core/UIBase.as
>> >> +++ /dev/null
>> >> @@ -1,1628 +0,0 @@
>> >> -///////////////////////////////////////////////////////////
>> >> /////////////////////
>> >> -//
>> >> -// Licensed to the Apache Software Foundation (ASF) under one or
>>more
>> >> -// contributor license agreements. See the NOTICE file distributed
>> with
>> >> -// this work for additional information regarding copyright
>>ownership.
>> >> -// The ASF licenses this file to You under the Apache License,
>>Version
>> >> 2.0
>> >> -// (the "License"); you may not use this file except in compliance
>> with
>> >> -// the License. You may obtain a copy of the License at
>> >> -//
>> >> -//
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apach
>>e.org%2Flicenses%2FLICENSE-2.0&data=02%7C01%7Caharui%40adobe.com%7C93cc1d
>>aba80a46f7a4e808d59e63f4f8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>>36589074514678949&sdata=3gZMQksbdTYlP63ubw7KeBtuek7QOLlww2FEX1MXBnA%3D&re
>>served=0
>> >> -//
>> >> -// Unless required by applicable law or agreed to in writing,
>>software
>> >> -// distributed under the License is distributed on an "AS IS"
>>BASIS,
>> >> -// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> >> implied.
>> >> -// See the License for the specific language governing permissions
>>and
>> >> -// limitations under the License.
>> >> -//
>> >> -///////////////////////////////////////////////////////////
>> >> /////////////////////
>> >> -package org.apache.royale.core
>> >> -{
>> >> - COMPILE::SWF
>> >> - {
>> >> - import flash.display.DisplayObject;
>> >> - import flash.display.Sprite;
>> >> - import flash.display.Stage;
>> >> - import org.apache.royale.events.utils.MouseEventConverter;
>> >> - }
>> >> -
>> >> - import org.apache.royale.events.Event;
>> >> - import org.apache.royale.events.IEventDispatcher;
>> >> - import org.apache.royale.events.MouseEvent;
>> >> - import org.apache.royale.events.ValueChangeEvent;
>> >> - import org.apache.royale.utils.loadBeadFromValuesManager;
>> >> - import org.apache.royale.utils.StringUtil;
>> >> -
>> >> - COMPILE::JS
>> >> - {
>> >> - import org.apache.royale.html.util.addElementToWrapper;
>> >> - import org.apache.royale.utils.CSSUtils;
>> >> - import org.apache.royale.utils.cssclasslist.addStyles;
>> >> - }
>> >> -
>> >> - /**
>> >> - * Set a different class for click events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="click", type="org.apache.royale.
>> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * Set a different class for rollOver events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="rollOver", type="org.apache.royale.
>> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * Set a different class for rollOut events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="rollOut", type="org.apache.royale.
>> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * Set a different class for mouseDown events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="mouseDown", type="org.apache.royale.
>> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * Set a different class for mouseUp events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="mouseUp", type="org.apache.royale.
>> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * Set a different class for mouseMove events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="mouseMove", type="org.apache.royale.
>> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * Set a different class for mouseOut events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="mouseOut", type="org.apache.royale.
>> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * Set a different class for mouseOver events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="mouseOver", type="org.apache.royale.
>> >> events.MouseEvent")]
>> >> - /**
>> >> - * Set a different class for mouseWheel events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="mouseWheel", type="org.apache.royale.
>> >> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * Set a different class for doubleClick events so that
>> >> - * there aren't dependencies on the flash classes
>> >> - * on the JS side.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - [Event(name="doubleClick", type="org.apache.royale.
>> >> events.MouseEvent")]
>> >> -
>> >> - /**
>> >> - * The UIBase class is the base class for most composite user
>> >> interface
>> >> - * components. For the Flash Player, Buttons and Text controls
>> may
>> >> - * have a different base class and therefore may not extend
>> UIBase.
>> >> - * However all user interface components should implement
>>IUIBase.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public class UIBase extends HTMLElementWrapper implements
>> >> IStrandWithModel, IEventDispatcher, IParentIUIBase, IStyleableObject,
>> >> ILayoutChild, IRoyaleElement
>> >> - {
>> >> - /**
>> >> - * Constructor.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function UIBase()
>> >> - {
>> >> - super();
>> >> -
>> >> - COMPILE::SWF
>> >> - {
>> >> - MouseEventConverter.setupInstanceConverters(this);
>> >> - doubleClickEnabled = true; // make JS and flash
>> consistent
>> >> - }
>> >> -
>> >> - COMPILE::JS
>> >> - {
>> >> - createElement();
>> >> - }
>> >> - }
>> >> -
>> >> - COMPILE::SWF
>> >> - public function get $displayObject():DisplayObject
>> >> - {
>> >> - return this;
>> >> - }
>> >> -
>> >> - public function get royale_wrapper():Object
>> >> - {
>> >> - return this;
>> >> - }
>> >> - public function set royale_wrapper(value:Object):void
>> >> - {
>> >> - }
>> >> -
>> >> - private var _explicitWidth:Number;
>> >> -
>> >> - /**
>> >> - * The explicitly set width (as opposed to measured width
>> >> - * or percentage width).
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function get explicitWidth():Number
>> >> - {
>> >> - return _explicitWidth;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - public function set explicitWidth(value:Number):void
>> >> - {
>> >> - if (_explicitWidth == value)
>> >> - return;
>> >> -
>> >> - // width can be pixel or percent not both
>> >> - if (!isNaN(value))
>> >> - _percentWidth = NaN;
>> >> -
>> >> - _explicitWidth = value;
>> >> -
>> >> - dispatchEvent(new
>>Event("explicitWidthChanged"))
>> ;
>> >> - }
>> >> -
>> >> - private var _explicitHeight:Number;
>> >> -
>> >> - /**
>> >> - * The explicitly set width (as opposed to measured width
>> >> - * or percentage width).
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function get explicitHeight():Number
>> >> - {
>> >> - return _explicitHeight;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - public function set explicitHeight(value:Number):void
>> >> - {
>> >> - if (_explicitHeight == value)
>> >> - return;
>> >> -
>> >> - // height can be pixel or percent not both
>> >> - if (!isNaN(value))
>> >> - _percentHeight = NaN;
>> >> -
>> >> - _explicitHeight = value;
>> >> -
>> >> - dispatchEvent(new
>>Event("explicitHeightChanged")
>> );
>> >> - }
>> >> -
>> >> - private var _percentWidth:Number;
>> >> -
>> >> - /**
>> >> - * The requested percentage width this component
>> >> - * should have in the parent container. Note that
>> >> - * the actual percentage may be different if the
>> >> - * total is more than 100% or if there are other
>> >> - * components with explicitly set widths.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function get percentWidth():Number
>> >> - {
>> >> - return _percentWidth;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - public function set percentWidth(value:Number):void
>> >> - {
>> >> - COMPILE::SWF {
>> >> - if (_percentWidth == value)
>> >> - return;
>> >> -
>> >> - if (!isNaN(value))
>> >> - _explicitWidth = NaN;
>> >> -
>> >> - _percentWidth = value;
>> >> - }
>> >> - COMPILE::JS {
>> >> - this._percentWidth = value;
>> >> - this.positioner.style.width =
>> >> value.toString() + '%';
>> >> - if (!isNaN(value))
>> >> - this._explicitWidth = NaN;
>> >> - }
>> >> -
>> >> - dispatchEvent(new
>>Event("percentWidthChanged"));
>> >> - }
>> >> -
>> >> - private var _percentHeight:Number;
>> >> -
>> >> - /**
>> >> - * The requested percentage height this component
>> >> - * should have in the parent container. Note that
>> >> - * the actual percentage may be different if the
>> >> - * total is more than 100% or if there are other
>> >> - * components with explicitly set heights.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function get percentHeight():Number
>> >> - {
>> >> - return _percentHeight;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - public function set percentHeight(value:Number):void
>> >> - {
>> >> - COMPILE::SWF {
>> >> - if (_percentHeight == value)
>> >> - return;
>> >> -
>> >> - if (!isNaN(value))
>> >> - _explicitHeight = NaN;
>> >> -
>> >> - _percentHeight = value;
>> >> - }
>> >> -
>> >> - COMPILE::JS {
>> >> - this._percentHeight = value;
>> >> - this.positioner.style.height =
>> >> value.toString() + '%';
>> >> - if (!isNaN(value))
>> >> - this._explicitHeight = NaN;
>> >> - }
>> >> -
>> >> - dispatchEvent(new
>>Event("percentHeightChanged"))
>> ;
>> >> - }
>> >> -
>> >> - private var _width:Number;
>> >> -
>> >> - [Bindable("widthChanged")]
>> >> - [PercentProxy("percentWidth")]
>> >> - /**
>> >> - * The width of the component. If no width has been
>> previously
>> >> - * set the default width may be specified in the
>>IValuesImpl
>> >> - * or determined as the bounding box around all child
>> >> - * components and graphics.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::SWF
>> >> - override public function get width():Number
>> >> - {
>> >> - var w:Number = _width;
>> >> - if (isNaN(w)) {
>> >> - w = $width;
>> >> - }
>> >> - return w;
>> >> - }
>> >> -
>> >> - [Bindable("widthChanged")]
>> >> - [PercentProxy("percentWidth")]
>> >> - /**
>> >> - * @royaleignorecoercion String
>> >> - */
>> >> - COMPILE::JS
>> >> - public function get width():Number
>> >> - {
>> >> - if(!isNaN(_explicitWidth))
>> >> - return _explicitWidth;
>> >> - var pixels:Number;
>> >> - var strpixels:String = element.style.width as String;
>> >> - if(strpixels == null)
>> >> - pixels = NaN;
>> >> - else
>> >> - pixels = CSSUtils.toNumber(strpixels,NaN);
>> >> - if (isNaN(pixels)) {
>> >> - pixels = positioner.offsetWidth;
>> >> - if (pixels == 0 && positioner.scrollWidth != 0) {
>> >> - // invisible child elements cause offsetWidth to
>> be 0.
>> >> - pixels = positioner.scrollWidth;
>> >> - }
>> >> - }
>> >> - return pixels;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - COMPILE::SWF
>> >> - override public function set width(value:Number):void
>> >> - {
>> >> - if (explicitWidth !== value)
>> >> - {
>> >> - explicitWidth = value;
>> >> - }
>> >> -
>> >> - setWidth(value);
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - COMPILE::JS
>> >> - public function set width(value:Number):void
>> >> - {
>> >> - if (explicitWidth !== value)
>> >> - {
>> >> - explicitWidth = value;
>> >> - }
>> >> -
>> >> - setWidth(value);
>> >> - }
>> >> -
>> >> - /**
>> >> - * Retrieve the low-level bounding box width.
>> >> - * Not implemented in JS.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::SWF
>> >> - public function get $width():Number
>> >> - {
>> >> - return super.width;
>> >> - }
>> >> -
>> >> - private var _height:Number;
>> >> -
>> >> - [Bindable("heightChanged")]
>> >> - [PercentProxy("percentHeight")]
>> >> - /**
>> >> - * The height of the component. If no height has been
>> previously
>> >> - * set the default height may be specified in the
>>IValuesImpl
>> >> - * or determined as the bounding box around all child
>> >> - * components and graphics.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::SWF
>> >> - override public function get height():Number
>> >> - {
>> >> - var h:Number = _height;
>> >> - if (isNaN(h)) {
>> >> - h = $height;
>> >> - }
>> >> - return h;
>> >> - }
>> >> -
>> >> - [Bindable("heightChanged")]
>> >> - [PercentProxy("percentHeight")]
>> >> - /**
>> >> - * @royaleignorecoercion String
>> >> - */
>> >> - COMPILE::JS
>> >> - public function get height():Number
>> >> - {
>> >> - if(!isNaN(_explicitHeight))
>> >> - return _explicitHeight;
>> >> - var pixels:Number;
>> >> - var strpixels:String = element.style.height as String;
>> >> - if(strpixels == null)
>> >> - pixels = NaN;
>> >> - else
>> >> - pixels = CSSUtils.toNumber(strpixels,NaN);
>> >> - if (isNaN(pixels)) {
>> >> - pixels = positioner.offsetHeight;
>> >> - if (pixels == 0 && positioner.scrollHeight != 0) {
>> >> - // invisible child elements cause offsetHeight
>>to
>> be
>> >> 0.
>> >> - pixels = positioner.scrollHeight;
>> >> - }
>> >> - }
>> >> - return pixels;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - COMPILE::SWF
>> >> - override public function set
>>height(value:Number):void
>> >> - {
>> >> - if (explicitHeight !== value)
>> >> - {
>> >> - explicitHeight = value;
>> >> - }
>> >> -
>> >> - setHeight(value);
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - COMPILE::JS
>> >> - public function set height(value:Number):void
>> >> - {
>> >> - if (explicitHeight !== value)
>> >> - {
>> >> - explicitHeight = value;
>> >> - }
>> >> -
>> >> - setHeight(value);
>> >> - }
>> >> -
>> >> - /**
>> >> - * Retrieve the low-level bounding box height.
>> >> - * Not implemented in JS.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::SWF
>> >> - public function get $height():Number
>> >> - {
>> >> - return super.height;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.ILayoutChild#setHeight
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function setHeight(value:Number, noEvent:Boolean =
>> >> false):void
>> >> - {
>> >> - if (_height !== value)
>> >> - {
>> >> - _height = value;
>> >> - COMPILE::JS
>> >> - {
>> >> - this.positioner.style.height = value.toString()
>>+
>> >> 'px';
>> >> - }
>> >> - if (!noEvent)
>> >> - dispatchEvent(new Event("heightChanged"));
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.ILayoutChild#setWidth
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function setWidth(value:Number, noEvent:Boolean =
>> >> false):void
>> >> - {
>> >> - if (_width !== value)
>> >> - {
>> >> - _width = value;
>> >> - COMPILE::JS
>> >> - {
>> >> - this.positioner.style.width = value.toString() +
>> 'px';
>> >> - }
>> >> - if (!noEvent)
>> >> - dispatchEvent(new Event("widthChanged"));
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - * Used by layout to prevent causing unnecessary reflows
>>when
>> >> measuring.
>> >> - */
>> >> - private var _measuredWidth:Number;
>> >> -
>> >> - public function get measuredWidth():Number
>> >> - {
>> >> - return _measuredWidth;
>> >> - }
>> >> -
>> >> - public function set measuredWidth(value:Number):void
>> >> - {
>> >> - _measuredWidth = value;
>> >> - }
>> >> - /**
>> >> - * @private
>> >> - * Used by layout to prevent causing unnecessary reflows
>>when
>> >> measuring.
>> >> - */
>> >> - private var _measuredHeight:Number;
>> >> -
>> >> - public function get measuredHeight():Number
>> >> - {
>> >> - return _measuredHeight;
>> >> - }
>> >> -
>> >> - public function set measuredHeight(value:Number):void
>> >> - {
>> >> - _measuredHeight = value;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.
>> ILayoutChild#setWidthAndHeight
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function setWidthAndHeight(newWidth:Number,
>> >> newHeight:Number, noEvent:Boolean = false):void
>> >> - {
>> >> - if (_width !== newWidth)
>> >> - {
>> >> - _width = newWidth;
>> >> - COMPILE::JS
>> >> - {
>> >> - this.positioner.style.width =
>>newWidth.toString() +
>> >> 'px';
>> >> - }
>> >> - if (!noEvent)
>> >> - dispatchEvent(new Event("widthChanged"));
>> >> - }
>> >> - if (_height !== newHeight)
>> >> - {
>> >> - _height = newHeight;
>> >> - COMPILE::JS
>> >> - {
>> >> - this.positioner.style.height =
>> newHeight.toString() +
>> >> 'px';
>> >> - }
>> >> - if (!noEvent)
>> >> - dispatchEvent(new Event("heightChanged"));
>> >> - }
>> >> - dispatchEvent(new Event("sizeChanged"));
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.ILayoutChild#
>> >> isWidthSizedToContent
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function isWidthSizedToContent():Boolean
>> >> - {
>> >> - if (!isNaN(_explicitWidth))
>> >> - return false;
>> >> - if (!isNaN(_percentWidth))
>> >> - return false;
>> >> - var left:* = ValuesManager.valuesImpl.getValue(this,
>> "left");
>> >> - var right:* = ValuesManager.valuesImpl.getValue(this,
>> >> "right");
>> >> - return (left === undefined || right === undefined);
>> >> -
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.ILayoutChild#
>> >> isHeightSizedToContent
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function isHeightSizedToContent():Boolean
>> >> - {
>> >> - if (!isNaN(_explicitHeight))
>> >> - return false;
>> >> - if (!isNaN(_percentHeight))
>> >> - return false;
>> >> - var top:* = ValuesManager.valuesImpl.getValue(this,
>> "top");
>> >> - var bottom:* = ValuesManager.valuesImpl.getValue(this,
>> >> "bottom");
>> >> - return (top === undefined || bottom === undefined);
>> >> - }
>> >> -
>> >> - private var _x:Number;
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - COMPILE::SWF
>> >> - override public function set x(value:Number):void
>> >> - {
>> >> - super.x = _x = value;
>> >> - if (!style)
>> >> - style = { left: value };
>> >> - else
>> >> - style.left = value;
>> >> - }
>> >> - /**
>> >> - * @royaleignorecoercion HTMLElement
>> >> - */
>> >> - COMPILE::JS
>> >> - public function set x(value:Number):void
>> >> - {
>> >> - _x = value;
>> >> - setX(value);
>> >> - }
>> >> -
>> >> - /**
>> >> - * @royaleignorecoercion String
>> >> - * @royaleignorecoercion HTMLElement
>> >> - */
>> >> - COMPILE::JS
>> >> - public function get x():Number
>> >> - {
>> >> - if(!isNaN(_x))
>> >> - return _x
>> >> - var strpixels:String = positioner.style.left as String;
>> >> - var pixels:Number = parseFloat(strpixels);
>> >> - if (isNaN(pixels))
>> >> - {
>> >> - pixels = positioner.offsetLeft;
>> >> - if (positioner.parentNode !=
>>positioner.offsetParent)
>> >> - pixels -= (positioner.parentNode as
>> >> HTMLElement).offsetLeft;
>> >> - }
>> >> - return pixels;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.ILayoutChild#setX
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - * @royaleignorecoercion HTMLElement
>> >> - */
>> >> - public function setX(value:Number):void
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - super.x = value;
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - //positioner.style.position =
>> 'absolute';
>> >> - if (positioner.parentNode !=
>>positioner.offsetParent)
>> >> - value += (positioner.parentNode as
>> >> HTMLElement).offsetLeft;
>> >> - positioner.style.left =
>> value.toString() +
>> >> 'px';
>> >> - }
>> >> - }
>> >> -
>> >> - private var _y:Number;
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - COMPILE::SWF
>> >> - override public function set y(value:Number):void
>> >> - {
>> >> - super.y = _y = value;
>> >> - if (!style)
>> >> - style = { top: value };
>> >> - else
>> >> - style.top = value;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @royaleignorecoercion HTMLElement
>> >> - */
>> >> - COMPILE::JS
>> >> - public function set y(value:Number):void
>> >> - {
>> >> - _y = value;
>> >> - setY(value);
>> >> - }
>> >> -
>> >> - /**
>> >> - * @royaleignorecoercion String
>> >> - * @royaleignorecoercion HTMLElement
>> >> - */
>> >> - COMPILE::JS
>> >> - public function get y():Number
>> >> - {
>> >> - if(!isNaN(_y))
>> >> - return _y
>> >> - var strpixels:String = positioner.style.top as String;
>> >> - var pixels:Number = parseFloat(strpixels);
>> >> - if (isNaN(pixels))
>> >> - {
>> >> - pixels = positioner.offsetTop;
>> >> - if (positioner.parentNode !=
>>positioner.offsetParent)
>> >> - pixels -= (positioner.parentNode as
>> >> HTMLElement).offsetTop;
>> >> - }
>> >> - return pixels;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.ILayoutChild#setY
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - * @royaleignorecoercion HTMLElement
>> >> - */
>> >> - public function setY(value:Number):void
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - super.y = value;
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - //positioner.style.position =
>> 'absolute';
>> >> - if (positioner.parentNode !=
>>positioner.offsetParent)
>> >> - value += (positioner.parentNode as
>> >> HTMLElement).offsetTop;
>> >> - positioner.style.top =
>>value.toString()
>> +
>> >> 'px';
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - [Bindable("visibleChanged")]
>> >> - COMPILE::SWF
>> >> - override public function set
>>visible(value:Boolean):void
>> >> - {
>> >> - super.visible = value;
>> >> - dispatchEvent(new
>>Event(value?"show":"hide"));
>> >> - dispatchEvent(new Event("visibleChanged"));
>> >> - }
>> >> -
>> >> - COMPILE::JS
>> >> - private var displayStyleForLayout:String;
>> >> -
>> >> - /**
>> >> - * The display style is used for both visible
>> >> - * and layout so is managed as a special case.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::JS
>> >> - public function setDisplayStyleForLayout(
>> >> value:String):void
>> >> - {
>> >> - if (positioner.style.display !== 'none')
>> >> - positioner.style.display = value;
>> >> - else
>> >> - displayStyleForLayout = value;
>> >> - }
>> >> -
>> >> - [Bindable("visibleChanged")]
>> >> - COMPILE::JS
>> >> - public function get visible():Boolean
>> >> - {
>> >> - return positioner.style.display !== 'none';
>> >> - }
>> >> -
>> >> - COMPILE::JS
>> >> - public function set visible(value:Boolean):void
>> >> - {
>> >> - var oldValue:Boolean = positioner.style.display !==
>>'none';
>> >> - if (value !== oldValue)
>> >> - {
>> >> - if (!value)
>> >> - {
>> >> - displayStyleForLayout =
>> >> positioner.style.display;
>> >> - positioner.style.display = 'none';
>> >> - dispatchEvent(new Event('hide'));
>> >> - }
>> >> - else
>> >> - {
>> >> - if (displayStyleForLayout != null)
>> >> - positioner.style.display =
>> displayStyleForLayout;
>> >> - dispatchEvent(new Event('show'));
>> >> - }
>> >> - dispatchEvent(new Event('visibleChanged'));
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @return The array of children.
>> >> - * @royaleignorecoercion Array
>> >> - */
>> >> - COMPILE::JS
>> >> - public function internalChildren():Array
>> >> - {
>> >> - return element.childNodes as Array;
>> >> - }
>> >> -
>> >> - COMPILE::SWF
>> >> - private var _model:IBeadModel;
>> >> -
>> >> - /**
>> >> - * An IBeadModel that serves as the data model for the
>> component.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::SWF
>> >> - public function get model():Object
>> >> - {
>> >> - if (_model == null)
>> >> - {
>> >> - // addbead will set _model
>> >> - addBead(new (ValuesManager.valuesImpl.getValue(this,
>> >> "iBeadModel")) as IBead);
>> >> - }
>> >> - return _model;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - COMPILE::SWF
>> >> - public function set model(value:Object):void
>> >> - {
>> >> - if (_model != value)
>> >> - {
>> >> - addBead(value as IBead);
>> >> - dispatchEvent(new
>> Event("modelChanged"));
>> >> - }
>> >> - }
>> >> -
>> >> - private var _view:IBeadView;
>> >> -
>> >> - /**
>> >> - * An IBeadView that serves as the view for the component.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - * @royaleignorecoercion Class
>> >> - * @royaleignorecoercion org.apache.royale.core.IBeadView
>> >> - */
>> >> - public function get view():IBeadView
>> >> - {
>> >> - if(!_view)
>> >> - _view = loadBeadFromValuesManager(IBeadView,
>> >> "iBeadView", this) as IBeadView;
>> >> - return _view;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - public function set view(value:IBeadView):void
>> >> - {
>> >> - if (_view != value)
>> >> - {
>> >> - addBead(value);
>> >> - dispatchEvent(new Event("viewChanged"));
>> >> - }
>> >> - }
>> >> -
>> >> - private var _id:String;
>> >> -
>> >> - /**
>> >> - * An id property for MXML documents.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function get id():String
>> >> - {
>> >> - return _id;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - public function set id(value:String):void
>> >> - {
>> >> - if (_id !== value)
>> >> - {
>> >> - _id = value;
>> >> - dispatchEvent(new
>>Event("idChanged"));
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - element.id = _id;
>> >> - }
>> >> - }
>> >> -
>> >> - private var _style:Object;
>> >> -
>> >> - /**
>> >> - * The object that contains
>> >> - * "styles" and other associated
>> >> - * name-value pairs. You can
>> >> - * also specify a string in
>> >> - * HTML style attribute format.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function get style():Object
>> >> - {
>> >> - return _style;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - * @royaleignorecoercion String
>> >> - */
>> >> - public function set style(value:Object):void
>> >> - {
>> >> - if (_style !== value)
>> >> - {
>> >> - if (value is String)
>> >> - {
>> >> - _style = ValuesManager.valuesImpl.
>> parseStyles(value
>> >> as String);
>> >> - }
>> >> - else
>> >> - _style = value;
>> >> - if (!isNaN(_y))
>> >> - _style.top = _y;
>> >> - if (!isNaN(_x))
>> >> - _style.left = _x;
>> >> - COMPILE::JS
>> >> - {
>> >> - if (parent)
>> >> -
>> ValuesManager.valuesImpl.applyStyles(this,
>> >> _style);
>> >> - }
>> >> - dispatchEvent(new Event("stylesChanged"));
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * A list of type names. Often used for CSS
>> >> - * type selector lookups.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - *
>> >> - * @royalesuppresspublicvarwarning
>> >> - */
>> >> - public var typeNames:String;
>> >> -
>> >> - private var _className:String;
>> >> -
>> >> - /**
>> >> - * The classname. Often used for CSS
>> >> - * class selector lookups.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function get className():String
>> >> - {
>> >> - return _className;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - public function set className(value:String):void
>> >> - {
>> >> - if (_className !== value)
>> >> - {
>> >> - _className = value;
>> >> -
>> >> - COMPILE::JS
>> >> - {
>> >> - setClassName(computeFinalClassNames());
>> >> - }
>> >> -
>> >> - dispatchEvent(new Event("classNameChanged"));
>> >> - }
>> >> - }
>> >> -
>> >> - COMPILE::JS
>> >> - protected function computeFinalClassNames():String
>> >> - {
>> >> - return StringUtil.trim((_className ? _className : "")
>>+ "
>> "
>> >> + (typeNames ? typeNames : ""));
>> >> - }
>> >> -
>> >> - COMPILE::JS
>> >> - protected function setClassName(value:String):void
>> >> - {
>> >> - addStyles(element, value);
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IUIBase#element
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::SWF
>> >> - public function get element():IRoyaleElement
>> >> - {
>> >> - return this;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.Application#beads
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - *
>> >> - * @royalesuppresspublicvarwarning
>> >> - */
>> >> - public var beads:Array;
>> >> -
>> >> - COMPILE::SWF
>> >> - private var _beads:Vector.<IBead>;
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IStrand#addBead()
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.9
>> >> - * @royaleignorecoercion org.apache.royale.core.IBeadModel
>> >> - * @royaleignorecoercion org.apache.royale.core.IBeadView
>> >> - */
>> >> - override public function addBead(bead:IBead):void
>> >> - {
>> >> - var isView:Boolean;
>> >> - if (!_beads)
>> >> - _beads = new Vector.<IBead>;
>> >> - _beads.push(bead);
>> >> - if (bead is IBeadModel)
>> >> - _model = bead as IBeadModel;
>> >> - else if (bead is IBeadView)
>> >> - {
>> >> - _view = bead as IBeadView;
>> >> - isView = true
>> >> - }
>> >> - bead.strand = this;
>> >> -
>> >> - if (isView) {
>> >> - dispatchEvent(new
>>Event("viewChanged"));
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IStrand#getBeadByType()
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::SWF
>> >> - public function getBeadByType(
>> >> classOrInterface:Class):IBead
>> >> - {
>> >> - for each (var bead:IBead in _beads)
>> >> - {
>> >> - if (bead is classOrInterface)
>> >> - return bead;
>> >> - }
>> >> - return null;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IStrand#removeBead()
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - COMPILE::SWF
>> >> - public function removeBead(value:IBead):IBead
>> >> - {
>> >> - var n:int = _beads.length;
>> >> - for (var i:int = 0; i < n; i++)
>> >> - {
>> >> - var bead:IBead = _beads[i];
>> >> - if (bead == value)
>> >> - {
>> >> - _beads.splice(i, 1);
>> >> - return bead;
>> >> - }
>> >> - }
>> >> - return null;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IParent#addElement()
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - * @royaleignorecoercion
>>org.apache.royale.core.IUIBase
>> >> - */
>> >> - public function addElement(c:IChild,
>> dispatchEvent:Boolean
>> >> = true):void
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - if (c is IUIBase)
>> >> - {
>> >> - if (c is IRenderedObject)
>> >> - addChild(IRenderedObject(c).$displayObject);
>> >> - else
>> >> - addChild(c as DisplayObject);
>> >> - IUIBase(c).addedToParent();
>> >> - }
>> >> - else
>> >> - addChild(c as DisplayObject);
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - element.appendChild(c.positioner);
>> >> - (c as IUIBase).addedToParent();
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IParent#addElementAt()
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - * @royaleignorecoercion
>>org.apache.royale.core.IUIBase
>> >> - */
>> >> - public function addElementAt(c:IChild, index:int,
>> >> dispatchEvent:Boolean = true):void
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - if (c is IUIBase)
>> >> - {
>> >> - if (c is IRenderedObject)
>> >> - addChildAt(IUIBase(c).$displayObject,
>>index);
>> >> - else
>> >> - addChildAt(c as DisplayObject, index);
>> >> - IUIBase(c).addedToParent();
>> >> - }
>> >> - else
>> >> - addChildAt(c as DisplayObject, index);
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - var children:Array = internalChildren();
>> >> - if (index >= children.length)
>> >> - addElement(c);
>> >> - else
>> >> - {
>> >> - element.insertBefore(c.positioner,
>> >> - children[index]);
>> >> - (c as IUIBase).addedToParent();
>> >> - }
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IParent#getElementAt()
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function getElementAt(index:int):IChild
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - return getChildAt(index) as IChild;
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - var children:Array = internalChildren();
>> >> - if (children.length == 0)
>> >> - {
>> >> - return null;
>> >> - }
>> >> - return children[index].royale_wrapper;
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IParent#getElementIndex()
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function getElementIndex(c:IChild):int
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - if (c is IRenderedObject)
>> >> - return getChildIndex(IRenderedObject(
>> >> c).$displayObject);
>> >> - else
>> >> - return getChildIndex(c as DisplayObject);
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - var children:Array = internalChildren();
>> >> - var n:int = children.length;
>> >> - for (var i:int = 0; i < n; i++)
>> >> - {
>> >> - if (children[i] === c.element)
>> >> - return i;
>> >> - }
>> >> - return -1;
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IParent#removeElement()
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - * @royaleignorecoercion HTMLElement
>> >> - */
>> >> - public function removeElement(c:IChild,
>>dispatchEvent:Boolean =
>> >> true):void
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - if (c is IRenderedObject)
>> >> - removeChild(IRenderedObject(c).$displayObject);
>> >> - else
>> >> - removeChild(c as DisplayObject);
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - element.removeChild(c.element as HTMLElement);
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.IParent#numElements
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - */
>> >> - public function get numElements():int
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - return numChildren;
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - var children:Array = internalChildren();
>> >> - return children.length;
>> >> - }
>> >> - }
>> >> -
>> >> - /**
>> >> - * The method called when added to a parent. This is a
>>good
>> >> - * time to set up beads.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - * @royaleignorecoercion Class
>> >> - * @royaleignorecoercion Number
>> >> - */
>> >> - public function addedToParent():void
>> >> - {
>> >> - var c:Class;
>> >> -
>> >> - COMPILE::JS
>> >> - {
>> >> - setClassName(computeFinalClassNames());
>> >> -
>> >> - if (style)
>> >> - ValuesManager.valuesImpl.applyStyles(this,
>>style);
>> >> - }
>> >> -
>> >> - if (isNaN(_explicitWidth) &&
>> isNaN(_percentWidth))
>> >> - {
>> >> - var value:* =
>>ValuesManager.valuesImpl.
>> >> getValue(this,"width");
>> >> - if (value !== undefined)
>> >> - {
>> >> - if (value is String)
>> >> - {
>> >> - var s:String = String(value);
>> >> - if (s.indexOf("%") > -1)
>> >> - _percentWidth =
>> >> Number(s.substring(0, s.length - 1));
>> >> - else
>> >> - {
>> >> - if (s.indexOf("px") !== -1)
>> >> - s = s.substring(0, s.length - 2);
>> >> - _width = _explicitWidth = Number(s);
>> >> - }
>> >> - }
>> >> - else
>> >> - _width =
>>_explicitWidth
>> =
>> >> value as Number;
>> >> - }
>> >> - }
>> >> -
>> >> - if (isNaN(_explicitHeight) &&
>> >> isNaN(_percentHeight))
>> >> - {
>> >> - value = ValuesManager.valuesImpl.
>> >> getValue(this,"height");
>> >> - if (value !== undefined)
>> >> - {
>> >> - if (value is String)
>> >> - {
>> >> - s = String(value);
>> >> - if (s.indexOf("%") !== -1)
>> >> - _percentHeight =
>> >> Number(s.substring(0, s.length - 1));
>> >> - else
>> >> - {
>> >> - if (s.indexOf("px") !== -1)
>> >> - s = s.substring(0, s.length - 2);
>> >> - _height = _explicitHeight = Number(s);
>> >> - }
>> >> - }
>> >> - else
>> >> - _height =
>> _explicitHeight
>> >> = value as Number;
>> >> - }
>> >> - }
>> >> -
>> >> - for each (var bead:IBead in beads)
>> >> - addBead(bead);
>> >> -
>> >> - loadBeadFromValuesManager(IBeadModel,
>> >> "iBeadModel", this);
>> >> - loadBeadFromValuesManager(IBeadView, "iBeadView", this);
>> >> - loadBeadFromValuesManager(IBeadController,
>> >> "iBeadController", this);
>> >> - dispatchEvent(new Event("beadsAdded"));
>> >> - }
>> >> -
>> >> - private var _measurementBead:IMeasurementBead;
>> >> - /**
>> >> - * A measurement bead, if one exists.
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.9
>> >> - * @royaleignorecoercion org.apache.royale.core.
>> IMeasurementBead
>> >> - */
>> >> - public function get measurementBead() :
>>IMeasurementBead
>> >> - {
>> >> - if(!_measurementBead)
>> >> - {
>> >> - _measurementBead =
>> loadBeadFromValuesManager(IMeasurementBead,
>> >> "iMeasurementBead", this) as IMeasurementBead;
>> >> - }
>> >> - return _measurementBead;
>> >> - }
>> >> -
>> >> - COMPILE::SWF
>> >> - private var _stageProxy:StageProxy;
>> >> -
>> >> - /**
>> >> - * @copy org.apache.royale.core.
>> IUIBase#topMostEventDispatcher
>> >> - *
>> >> - * @langversion 3.0
>> >> - * @playerversion Flash 10.2
>> >> - * @playerversion AIR 2.6
>> >> - * @productversion Royale 0.0
>> >> - * @royaleignorecoercion org.apache.royale.core.
>> >> WrappedHTMLElement
>> >> - * @royaleignorecoercion org.apache.royale.events.
>> >> IEventDispatcher
>> >> - */
>> >> - public function get topMostEventDispatcher():
>> >> IEventDispatcher
>> >> - {
>> >> - COMPILE::SWF
>> >> - {
>> >> - if (!_stageProxy)
>> >> - {
>> >> - _stageProxy = new StageProxy(stage);
>> >> - _stageProxy.addEventListener("removedFromStage",
>> >> stageProxy_removedFromStageHandler);
>> >> - }
>> >> -
>> >> - return _stageProxy;
>> >> - }
>> >> - COMPILE::JS
>> >> - {
>> >> - var e:WrappedHTMLElement = document.body as
>> >> WrappedHTMLElement;
>> >> - return e.royale_wrapper as IEventDispatcher;
>> >> - }
>> >> - }
>> >> -
>> >> - COMPILE::SWF
>> >> - private function stageProxy_removedFromStageHandler(event:
>> >> Event):void
>> >> - {
>> >> - _stageProxy = null;
>> >> - }
>> >> -
>> >> - /**
>> >> - * Rebroadcast an event from a sub component from the
>> component.
>> >> - */
>> >> - protected function repeaterListener(event:Event):void
>> >> - {
>> >> - dispatchEvent(event);
>> >> - }
>> >> -
>> >> - /**
>> >> - * The HTMLElement used to position the component.
>> >> - */
>> >> - COMPILE::JS
>> >> - public function get positioner():WrappedHTMLElement
>> >> - {
>> >> - return element;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @private
>> >> - */
>> >> - COMPILE::JS
>> >> - public function set
>>positioner(value:WrappedHTMLElement):void
>> >> - {
>> >> - element = value;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @return The actual element to be parented.
>> >> - * @royaleignorecoercion org.apache.royale.core.
>> >> WrappedHTMLElement
>> >> - */
>> >> - COMPILE::JS
>> >> - protected function createElement():WrappedHTMLElement
>> >> - {
>> >> - addElementToWrapper(this,'div');
>> >> - positioner.style.display = 'block';
>> >> - //positioner.style.position = 'relative';
>> >> - return element;
>> >> - }
>> >> -
>> >> -
>> >> - /**
>> >> - * The HTMLElement used to position the component.
>> >> - * @royaleignorecoercion String
>> >> - */
>> >> - COMPILE::JS
>> >> - public function get alpha():Number
>> >> - {
>> >> - var stralpha:String = positioner.style.opacity as
>>String;
>> >> - var alpha:Number = parseFloat(stralpha);
>> >> - return alpha;
>> >> - }
>> >> -
>> >> - COMPILE::JS
>> >> - public function set alpha(value:Number):void
>> >> - {
>> >> - positioner.style.opacity = value;
>> >> - }
>> >> -
>> >> - /**
>> >> - * @param value The event containing new style properties.
>> >> - */
>> >> - COMPILE::JS
>> >> - protected function styleChangeHandler(value:
>> >> ValueChangeEvent):void
>> >> - {
>> >> - var newStyle:Object = {};
>> >> - newStyle[value.propertyName] = value.newValue;
>> >> - ValuesManager.valuesImpl.applyStyles(this, newStyle);
>> >> - }
>> >> -
>> >> - /**
>> >> - * @royaleignorecoercion org.apache.royale.core.
>> >> WrappedHTMLElement
>> >> - * @royaleignorecoercion org.apache.royale.core.IParent
>> >> - */
>> >> - COMPILE::JS
>> >> - public function get parent():IParent
>> >> - {
>> >> - var p:WrappedHTMLElement = this.positioner.parentNode as
>> >> WrappedHTMLElement;
>> >> - var wrapper:IParent = p ? p.royale_wrapper as IParent :
>> null;
>> >> - return wrapper;
>> >> - }
>> >> -
>> >> - COMPILE::SWF
>> >> - {
>> >> -
>>[SWFOverride(returns="flash.display.DisplayObjectContainer")]
>> >> - override public function get parent():IParent
>> >> - {
>> >> - return super.parent as IParent;
>> >> - }
>> >> - }
>> >> -
>> >> - COMPILE::SWF
>> >> - public function get transformElement():IRoyaleElement
>> >> - {
>> >> - return this;
>> >> - }
>> >> -
>> >> - COMPILE::JS
>> >> - public function get transformElement():
>> WrappedHTMLElement
>> >> - {
>> >> - return element;
>> >> - }
>> >> -
>> >> - COMPILE::SWF
>> >> - {
>> >> - [SWFOverride(params="flash.events.Event",
>> >> altparams="org.apache.royale.events.Event:org.apache.
>> >> royale.events.MouseEvent")]
>> >> - override public function dispatchEvent(event:org.
>> >> apache.royale.events.Event):Boolean
>> >> - {
>> >> - return super.dispatchEvent(event);
>> >> - }
>> >> - }
>> >> -
>> >> - }
>> >> -}
>> >>
>> >> --
>> >> To stop receiving notification emails like this one, please contact
>> >> carlosrovira@apache.org.
>> >>
>> >
>> >
>> >
>> > --
>> > Carlos Rovira
>> >
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C93cc1daba80a46f7a4e808
>>d59e63f4f8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63658907451467894
>>9&sdata=qVgIyrFMfWUHg4Kh9NTL5nwzzhltbF4aTu2Yxqh8Rvg%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%7C93cc1daba80a46f7a4e808d5
>9e63f4f8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636589074514678949&s
>data=qVgIyrFMfWUHg4Kh9NTL5nwzzhltbF4aTu2Yxqh8Rvg%3D&reserved=0
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Carlos Rovira <ca...@apache.org>.
Harbs,
I though I did it. I give links to peformance links that for me proved that
people is going through classList. If you read that Alex, replied that for
him that kind of tests was not reflecting our use case, but, for me we
should separate the performance of classList, from how we use classList.
For that reason Alex ask me to make a series of changes, that mostly I put
on that change. Don't know if those are all the changes or not. That's why
I'm asking Alex. I was assuming that since you didn't comment about that
you were ok with the perf test I put.
In the other hand, today I put the following link [1] about MDL browser
support, if you read carefully that section, they stands for
"For components, at minimum we require support for querySelector
<https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector>,
classList
<https://developer.mozilla.org/en-US/docs/Web/API/Element/classList> and
addEventListener
<https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener>,
which can be polyfilled
<https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills> as
needed. "
So, even MDL, that is designed with performance in mind uses classList at
his core. So what can I say more about this issue? I think instead you
didn't put real numbers about why should not use classList and only a fear
that it could be worse in performance when I demonstrated classList is not
a problem, maybe the way I put it on place, that is what Alex should check.
[1] https://getmdl.io/faq/index.html#browser-support
2018-04-09 21:09 GMT+02:00 Harbs <ha...@gmail.com>:
> This is a huge functional change. I don’t know that I really agree with
> this.
>
> You really haven’t answered my comments about the performance
> implications. I previously linked to jsperf tests. According to recent
> tests, addStyle seems to perform much more poorly that changing the
> className.
>
> > On Apr 9, 2018, at 9:49 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi,
> >
> > this branch has the UIBase modifications that I made in Jewel. I think is
> > time to complete the change so:
> >
> > @Alex: Can you take a look at the diff and see if you are ok with it? I
> > think I do this with the considerations we discussed some weeks ago, but
> I
> > think you never saw if that was finaly what you suggested.
> >
> > @Piotr: I think MDL is the project that needs to see how this changes
> > affect it. Since you're the one who are maintaining it, can you check it
> > and make the modifications in this branch needed? As we have no more
> > MDLExamples it would be a problem for me to bring that code and see it.
> >
> > I see some other examples (like the other day fixing databinding flat)
> and
> > seems to work ok since the rest are mainly royale components,
> >
> > I'd like to make this for 0.9.3 if possible to make Jewel as stable as
> > possible
> >
> > Thanks
> >
> > Carlos
> >
> >
> > 2018-04-09 20:41 GMT+02:00 <ca...@apache.org>:
> >
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> carlosrovira pushed a commit to branch feature/uibase-classname
> >> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> >>
> >> commit cf06ede63e3e794198fd68e8647e9c6eceae383d
> >> Author: Carlos Rovira <ca...@apache.org>
> >> AuthorDate: Mon Apr 9 20:41:48 2018 +0200
> >>
> >> UIBase className changes to support new cssclassList class methods
> >> like addStyles
> >> ---
> >> .../main/royale/org/apache/royale/core/UIBase.as | 18 +-
> >> .../main/royale/org/apache/royale/core/UIBase.as | 1628
> >> --------------------
> >> 2 files changed, 9 insertions(+), 1637 deletions(-)
> >>
> >> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/core/UIBase.as
> >> b/frameworks/projects/Basic/src/main/royale/org/apache/
> >> royale/core/UIBase.as
> >> index b5f4dd1..f59d7f0 100644
> >> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
> >> royale/core/UIBase.as
> >> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
> >> royale/core/UIBase.as
> >> @@ -37,6 +37,7 @@ package org.apache.royale.core
> >> {
> >> import org.apache.royale.html.util.addElementToWrapper;
> >> import org.apache.royale.utils.CSSUtils;
> >> + import org.apache.royale.utils.cssclasslist.addStyles;
> >> }
> >>
> >> /**
> >> @@ -1085,11 +1086,13 @@ package org.apache.royale.core
> >> {
> >> if (_className !== value)
> >> {
> >> + _className = value;
> >> +
> >> COMPILE::JS
> >> {
> >> - setClassName(typeNames ? StringUtil.trim(value + '
> '
> >> + typeNames) : value);
> >> + setClassName(computeFinalClassNames());
> >> }
> >> - _className = value;
> >> +
> >> dispatchEvent(new Event("classNameChanged"));
> >> }
> >> }
> >> @@ -1097,13 +1100,13 @@ package org.apache.royale.core
> >> COMPILE::JS
> >> protected function computeFinalClassNames():String
> >> {
> >> - return (_className ? _className + " " : "") + (typeNames ?
> >> typeNames : "");
> >> + return StringUtil.trim((_className ? _className : "") + "
> "
> >> + (typeNames ? typeNames : ""));
> >> }
> >>
> >> COMPILE::JS
> >> protected function setClassName(value:String):void
> >> {
> >> - element.className = value;
> >> + addStyles(element, value);
> >> }
> >>
> >> /**
> >> @@ -1394,11 +1397,8 @@ package org.apache.royale.core
> >>
> >> COMPILE::JS
> >> {
> >> - if (typeNames)
> >> - {
> >> - setClassName(computeFinalClassNames());
> >> - }
> >> -
> >> + setClassName(computeFinalClassNames());
> >> +
> >> if (style)
> >> ValuesManager.valuesImpl.applyStyles(this, style);
> >> }
> >> diff --git a/frameworks/projects/Jewel/src/main/royale/org/apache/
> royale/core/UIBase.as
> >> b/frameworks/projects/Jewel/src/main/royale/org/apache/
> >> royale/core/UIBase.as
> >> deleted file mode 100644
> >> index f59d7f0..0000000
> >> --- a/frameworks/projects/Jewel/src/main/royale/org/apache/
> >> royale/core/UIBase.as
> >> +++ /dev/null
> >> @@ -1,1628 +0,0 @@
> >> -///////////////////////////////////////////////////////////
> >> /////////////////////
> >> -//
> >> -// Licensed to the Apache Software Foundation (ASF) under one or more
> >> -// contributor license agreements. See the NOTICE file distributed
> with
> >> -// this work for additional information regarding copyright ownership.
> >> -// The ASF licenses this file to You under the Apache License, Version
> >> 2.0
> >> -// (the "License"); you may not use this file except in compliance
> with
> >> -// the License. You may obtain a copy of the License at
> >> -//
> >> -// http://www.apache.org/licenses/LICENSE-2.0
> >> -//
> >> -// Unless required by applicable law or agreed to in writing, software
> >> -// distributed under the License is distributed on an "AS IS" BASIS,
> >> -// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> >> implied.
> >> -// See the License for the specific language governing permissions and
> >> -// limitations under the License.
> >> -//
> >> -///////////////////////////////////////////////////////////
> >> /////////////////////
> >> -package org.apache.royale.core
> >> -{
> >> - COMPILE::SWF
> >> - {
> >> - import flash.display.DisplayObject;
> >> - import flash.display.Sprite;
> >> - import flash.display.Stage;
> >> - import org.apache.royale.events.utils.MouseEventConverter;
> >> - }
> >> -
> >> - import org.apache.royale.events.Event;
> >> - import org.apache.royale.events.IEventDispatcher;
> >> - import org.apache.royale.events.MouseEvent;
> >> - import org.apache.royale.events.ValueChangeEvent;
> >> - import org.apache.royale.utils.loadBeadFromValuesManager;
> >> - import org.apache.royale.utils.StringUtil;
> >> -
> >> - COMPILE::JS
> >> - {
> >> - import org.apache.royale.html.util.addElementToWrapper;
> >> - import org.apache.royale.utils.CSSUtils;
> >> - import org.apache.royale.utils.cssclasslist.addStyles;
> >> - }
> >> -
> >> - /**
> >> - * Set a different class for click events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="click", type="org.apache.royale.
> events.MouseEvent")]
> >> -
> >> - /**
> >> - * Set a different class for rollOver events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="rollOver", type="org.apache.royale.
> events.MouseEvent")]
> >> -
> >> - /**
> >> - * Set a different class for rollOut events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="rollOut", type="org.apache.royale.
> events.MouseEvent")]
> >> -
> >> - /**
> >> - * Set a different class for mouseDown events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="mouseDown", type="org.apache.royale.
> events.MouseEvent")]
> >> -
> >> - /**
> >> - * Set a different class for mouseUp events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="mouseUp", type="org.apache.royale.
> events.MouseEvent")]
> >> -
> >> - /**
> >> - * Set a different class for mouseMove events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="mouseMove", type="org.apache.royale.
> events.MouseEvent")]
> >> -
> >> - /**
> >> - * Set a different class for mouseOut events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="mouseOut", type="org.apache.royale.
> events.MouseEvent")]
> >> -
> >> - /**
> >> - * Set a different class for mouseOver events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="mouseOver", type="org.apache.royale.
> >> events.MouseEvent")]
> >> - /**
> >> - * Set a different class for mouseWheel events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="mouseWheel", type="org.apache.royale.
> >> events.MouseEvent")]
> >> -
> >> - /**
> >> - * Set a different class for doubleClick events so that
> >> - * there aren't dependencies on the flash classes
> >> - * on the JS side.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - [Event(name="doubleClick", type="org.apache.royale.
> >> events.MouseEvent")]
> >> -
> >> - /**
> >> - * The UIBase class is the base class for most composite user
> >> interface
> >> - * components. For the Flash Player, Buttons and Text controls
> may
> >> - * have a different base class and therefore may not extend
> UIBase.
> >> - * However all user interface components should implement IUIBase.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public class UIBase extends HTMLElementWrapper implements
> >> IStrandWithModel, IEventDispatcher, IParentIUIBase, IStyleableObject,
> >> ILayoutChild, IRoyaleElement
> >> - {
> >> - /**
> >> - * Constructor.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function UIBase()
> >> - {
> >> - super();
> >> -
> >> - COMPILE::SWF
> >> - {
> >> - MouseEventConverter.setupInstanceConverters(this);
> >> - doubleClickEnabled = true; // make JS and flash
> consistent
> >> - }
> >> -
> >> - COMPILE::JS
> >> - {
> >> - createElement();
> >> - }
> >> - }
> >> -
> >> - COMPILE::SWF
> >> - public function get $displayObject():DisplayObject
> >> - {
> >> - return this;
> >> - }
> >> -
> >> - public function get royale_wrapper():Object
> >> - {
> >> - return this;
> >> - }
> >> - public function set royale_wrapper(value:Object):void
> >> - {
> >> - }
> >> -
> >> - private var _explicitWidth:Number;
> >> -
> >> - /**
> >> - * The explicitly set width (as opposed to measured width
> >> - * or percentage width).
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function get explicitWidth():Number
> >> - {
> >> - return _explicitWidth;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - public function set explicitWidth(value:Number):void
> >> - {
> >> - if (_explicitWidth == value)
> >> - return;
> >> -
> >> - // width can be pixel or percent not both
> >> - if (!isNaN(value))
> >> - _percentWidth = NaN;
> >> -
> >> - _explicitWidth = value;
> >> -
> >> - dispatchEvent(new Event("explicitWidthChanged"))
> ;
> >> - }
> >> -
> >> - private var _explicitHeight:Number;
> >> -
> >> - /**
> >> - * The explicitly set width (as opposed to measured width
> >> - * or percentage width).
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function get explicitHeight():Number
> >> - {
> >> - return _explicitHeight;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - public function set explicitHeight(value:Number):void
> >> - {
> >> - if (_explicitHeight == value)
> >> - return;
> >> -
> >> - // height can be pixel or percent not both
> >> - if (!isNaN(value))
> >> - _percentHeight = NaN;
> >> -
> >> - _explicitHeight = value;
> >> -
> >> - dispatchEvent(new Event("explicitHeightChanged")
> );
> >> - }
> >> -
> >> - private var _percentWidth:Number;
> >> -
> >> - /**
> >> - * The requested percentage width this component
> >> - * should have in the parent container. Note that
> >> - * the actual percentage may be different if the
> >> - * total is more than 100% or if there are other
> >> - * components with explicitly set widths.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function get percentWidth():Number
> >> - {
> >> - return _percentWidth;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - public function set percentWidth(value:Number):void
> >> - {
> >> - COMPILE::SWF {
> >> - if (_percentWidth == value)
> >> - return;
> >> -
> >> - if (!isNaN(value))
> >> - _explicitWidth = NaN;
> >> -
> >> - _percentWidth = value;
> >> - }
> >> - COMPILE::JS {
> >> - this._percentWidth = value;
> >> - this.positioner.style.width =
> >> value.toString() + '%';
> >> - if (!isNaN(value))
> >> - this._explicitWidth = NaN;
> >> - }
> >> -
> >> - dispatchEvent(new Event("percentWidthChanged"));
> >> - }
> >> -
> >> - private var _percentHeight:Number;
> >> -
> >> - /**
> >> - * The requested percentage height this component
> >> - * should have in the parent container. Note that
> >> - * the actual percentage may be different if the
> >> - * total is more than 100% or if there are other
> >> - * components with explicitly set heights.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function get percentHeight():Number
> >> - {
> >> - return _percentHeight;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - public function set percentHeight(value:Number):void
> >> - {
> >> - COMPILE::SWF {
> >> - if (_percentHeight == value)
> >> - return;
> >> -
> >> - if (!isNaN(value))
> >> - _explicitHeight = NaN;
> >> -
> >> - _percentHeight = value;
> >> - }
> >> -
> >> - COMPILE::JS {
> >> - this._percentHeight = value;
> >> - this.positioner.style.height =
> >> value.toString() + '%';
> >> - if (!isNaN(value))
> >> - this._explicitHeight = NaN;
> >> - }
> >> -
> >> - dispatchEvent(new Event("percentHeightChanged"))
> ;
> >> - }
> >> -
> >> - private var _width:Number;
> >> -
> >> - [Bindable("widthChanged")]
> >> - [PercentProxy("percentWidth")]
> >> - /**
> >> - * The width of the component. If no width has been
> previously
> >> - * set the default width may be specified in the IValuesImpl
> >> - * or determined as the bounding box around all child
> >> - * components and graphics.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::SWF
> >> - override public function get width():Number
> >> - {
> >> - var w:Number = _width;
> >> - if (isNaN(w)) {
> >> - w = $width;
> >> - }
> >> - return w;
> >> - }
> >> -
> >> - [Bindable("widthChanged")]
> >> - [PercentProxy("percentWidth")]
> >> - /**
> >> - * @royaleignorecoercion String
> >> - */
> >> - COMPILE::JS
> >> - public function get width():Number
> >> - {
> >> - if(!isNaN(_explicitWidth))
> >> - return _explicitWidth;
> >> - var pixels:Number;
> >> - var strpixels:String = element.style.width as String;
> >> - if(strpixels == null)
> >> - pixels = NaN;
> >> - else
> >> - pixels = CSSUtils.toNumber(strpixels,NaN);
> >> - if (isNaN(pixels)) {
> >> - pixels = positioner.offsetWidth;
> >> - if (pixels == 0 && positioner.scrollWidth != 0) {
> >> - // invisible child elements cause offsetWidth to
> be 0.
> >> - pixels = positioner.scrollWidth;
> >> - }
> >> - }
> >> - return pixels;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - COMPILE::SWF
> >> - override public function set width(value:Number):void
> >> - {
> >> - if (explicitWidth !== value)
> >> - {
> >> - explicitWidth = value;
> >> - }
> >> -
> >> - setWidth(value);
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - COMPILE::JS
> >> - public function set width(value:Number):void
> >> - {
> >> - if (explicitWidth !== value)
> >> - {
> >> - explicitWidth = value;
> >> - }
> >> -
> >> - setWidth(value);
> >> - }
> >> -
> >> - /**
> >> - * Retrieve the low-level bounding box width.
> >> - * Not implemented in JS.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::SWF
> >> - public function get $width():Number
> >> - {
> >> - return super.width;
> >> - }
> >> -
> >> - private var _height:Number;
> >> -
> >> - [Bindable("heightChanged")]
> >> - [PercentProxy("percentHeight")]
> >> - /**
> >> - * The height of the component. If no height has been
> previously
> >> - * set the default height may be specified in the IValuesImpl
> >> - * or determined as the bounding box around all child
> >> - * components and graphics.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::SWF
> >> - override public function get height():Number
> >> - {
> >> - var h:Number = _height;
> >> - if (isNaN(h)) {
> >> - h = $height;
> >> - }
> >> - return h;
> >> - }
> >> -
> >> - [Bindable("heightChanged")]
> >> - [PercentProxy("percentHeight")]
> >> - /**
> >> - * @royaleignorecoercion String
> >> - */
> >> - COMPILE::JS
> >> - public function get height():Number
> >> - {
> >> - if(!isNaN(_explicitHeight))
> >> - return _explicitHeight;
> >> - var pixels:Number;
> >> - var strpixels:String = element.style.height as String;
> >> - if(strpixels == null)
> >> - pixels = NaN;
> >> - else
> >> - pixels = CSSUtils.toNumber(strpixels,NaN);
> >> - if (isNaN(pixels)) {
> >> - pixels = positioner.offsetHeight;
> >> - if (pixels == 0 && positioner.scrollHeight != 0) {
> >> - // invisible child elements cause offsetHeight to
> be
> >> 0.
> >> - pixels = positioner.scrollHeight;
> >> - }
> >> - }
> >> - return pixels;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - COMPILE::SWF
> >> - override public function set height(value:Number):void
> >> - {
> >> - if (explicitHeight !== value)
> >> - {
> >> - explicitHeight = value;
> >> - }
> >> -
> >> - setHeight(value);
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - COMPILE::JS
> >> - public function set height(value:Number):void
> >> - {
> >> - if (explicitHeight !== value)
> >> - {
> >> - explicitHeight = value;
> >> - }
> >> -
> >> - setHeight(value);
> >> - }
> >> -
> >> - /**
> >> - * Retrieve the low-level bounding box height.
> >> - * Not implemented in JS.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::SWF
> >> - public function get $height():Number
> >> - {
> >> - return super.height;
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.ILayoutChild#setHeight
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function setHeight(value:Number, noEvent:Boolean =
> >> false):void
> >> - {
> >> - if (_height !== value)
> >> - {
> >> - _height = value;
> >> - COMPILE::JS
> >> - {
> >> - this.positioner.style.height = value.toString() +
> >> 'px';
> >> - }
> >> - if (!noEvent)
> >> - dispatchEvent(new Event("heightChanged"));
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.ILayoutChild#setWidth
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function setWidth(value:Number, noEvent:Boolean =
> >> false):void
> >> - {
> >> - if (_width !== value)
> >> - {
> >> - _width = value;
> >> - COMPILE::JS
> >> - {
> >> - this.positioner.style.width = value.toString() +
> 'px';
> >> - }
> >> - if (!noEvent)
> >> - dispatchEvent(new Event("widthChanged"));
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - * Used by layout to prevent causing unnecessary reflows when
> >> measuring.
> >> - */
> >> - private var _measuredWidth:Number;
> >> -
> >> - public function get measuredWidth():Number
> >> - {
> >> - return _measuredWidth;
> >> - }
> >> -
> >> - public function set measuredWidth(value:Number):void
> >> - {
> >> - _measuredWidth = value;
> >> - }
> >> - /**
> >> - * @private
> >> - * Used by layout to prevent causing unnecessary reflows when
> >> measuring.
> >> - */
> >> - private var _measuredHeight:Number;
> >> -
> >> - public function get measuredHeight():Number
> >> - {
> >> - return _measuredHeight;
> >> - }
> >> -
> >> - public function set measuredHeight(value:Number):void
> >> - {
> >> - _measuredHeight = value;
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.
> ILayoutChild#setWidthAndHeight
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function setWidthAndHeight(newWidth:Number,
> >> newHeight:Number, noEvent:Boolean = false):void
> >> - {
> >> - if (_width !== newWidth)
> >> - {
> >> - _width = newWidth;
> >> - COMPILE::JS
> >> - {
> >> - this.positioner.style.width = newWidth.toString() +
> >> 'px';
> >> - }
> >> - if (!noEvent)
> >> - dispatchEvent(new Event("widthChanged"));
> >> - }
> >> - if (_height !== newHeight)
> >> - {
> >> - _height = newHeight;
> >> - COMPILE::JS
> >> - {
> >> - this.positioner.style.height =
> newHeight.toString() +
> >> 'px';
> >> - }
> >> - if (!noEvent)
> >> - dispatchEvent(new Event("heightChanged"));
> >> - }
> >> - dispatchEvent(new Event("sizeChanged"));
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.ILayoutChild#
> >> isWidthSizedToContent
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function isWidthSizedToContent():Boolean
> >> - {
> >> - if (!isNaN(_explicitWidth))
> >> - return false;
> >> - if (!isNaN(_percentWidth))
> >> - return false;
> >> - var left:* = ValuesManager.valuesImpl.getValue(this,
> "left");
> >> - var right:* = ValuesManager.valuesImpl.getValue(this,
> >> "right");
> >> - return (left === undefined || right === undefined);
> >> -
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.ILayoutChild#
> >> isHeightSizedToContent
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function isHeightSizedToContent():Boolean
> >> - {
> >> - if (!isNaN(_explicitHeight))
> >> - return false;
> >> - if (!isNaN(_percentHeight))
> >> - return false;
> >> - var top:* = ValuesManager.valuesImpl.getValue(this,
> "top");
> >> - var bottom:* = ValuesManager.valuesImpl.getValue(this,
> >> "bottom");
> >> - return (top === undefined || bottom === undefined);
> >> - }
> >> -
> >> - private var _x:Number;
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - COMPILE::SWF
> >> - override public function set x(value:Number):void
> >> - {
> >> - super.x = _x = value;
> >> - if (!style)
> >> - style = { left: value };
> >> - else
> >> - style.left = value;
> >> - }
> >> - /**
> >> - * @royaleignorecoercion HTMLElement
> >> - */
> >> - COMPILE::JS
> >> - public function set x(value:Number):void
> >> - {
> >> - _x = value;
> >> - setX(value);
> >> - }
> >> -
> >> - /**
> >> - * @royaleignorecoercion String
> >> - * @royaleignorecoercion HTMLElement
> >> - */
> >> - COMPILE::JS
> >> - public function get x():Number
> >> - {
> >> - if(!isNaN(_x))
> >> - return _x
> >> - var strpixels:String = positioner.style.left as String;
> >> - var pixels:Number = parseFloat(strpixels);
> >> - if (isNaN(pixels))
> >> - {
> >> - pixels = positioner.offsetLeft;
> >> - if (positioner.parentNode != positioner.offsetParent)
> >> - pixels -= (positioner.parentNode as
> >> HTMLElement).offsetLeft;
> >> - }
> >> - return pixels;
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.ILayoutChild#setX
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - * @royaleignorecoercion HTMLElement
> >> - */
> >> - public function setX(value:Number):void
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - super.x = value;
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - //positioner.style.position =
> 'absolute';
> >> - if (positioner.parentNode != positioner.offsetParent)
> >> - value += (positioner.parentNode as
> >> HTMLElement).offsetLeft;
> >> - positioner.style.left =
> value.toString() +
> >> 'px';
> >> - }
> >> - }
> >> -
> >> - private var _y:Number;
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - COMPILE::SWF
> >> - override public function set y(value:Number):void
> >> - {
> >> - super.y = _y = value;
> >> - if (!style)
> >> - style = { top: value };
> >> - else
> >> - style.top = value;
> >> - }
> >> -
> >> - /**
> >> - * @royaleignorecoercion HTMLElement
> >> - */
> >> - COMPILE::JS
> >> - public function set y(value:Number):void
> >> - {
> >> - _y = value;
> >> - setY(value);
> >> - }
> >> -
> >> - /**
> >> - * @royaleignorecoercion String
> >> - * @royaleignorecoercion HTMLElement
> >> - */
> >> - COMPILE::JS
> >> - public function get y():Number
> >> - {
> >> - if(!isNaN(_y))
> >> - return _y
> >> - var strpixels:String = positioner.style.top as String;
> >> - var pixels:Number = parseFloat(strpixels);
> >> - if (isNaN(pixels))
> >> - {
> >> - pixels = positioner.offsetTop;
> >> - if (positioner.parentNode != positioner.offsetParent)
> >> - pixels -= (positioner.parentNode as
> >> HTMLElement).offsetTop;
> >> - }
> >> - return pixels;
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.ILayoutChild#setY
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - * @royaleignorecoercion HTMLElement
> >> - */
> >> - public function setY(value:Number):void
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - super.y = value;
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - //positioner.style.position =
> 'absolute';
> >> - if (positioner.parentNode != positioner.offsetParent)
> >> - value += (positioner.parentNode as
> >> HTMLElement).offsetTop;
> >> - positioner.style.top = value.toString()
> +
> >> 'px';
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - [Bindable("visibleChanged")]
> >> - COMPILE::SWF
> >> - override public function set visible(value:Boolean):void
> >> - {
> >> - super.visible = value;
> >> - dispatchEvent(new Event(value?"show":"hide"));
> >> - dispatchEvent(new Event("visibleChanged"));
> >> - }
> >> -
> >> - COMPILE::JS
> >> - private var displayStyleForLayout:String;
> >> -
> >> - /**
> >> - * The display style is used for both visible
> >> - * and layout so is managed as a special case.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::JS
> >> - public function setDisplayStyleForLayout(
> >> value:String):void
> >> - {
> >> - if (positioner.style.display !== 'none')
> >> - positioner.style.display = value;
> >> - else
> >> - displayStyleForLayout = value;
> >> - }
> >> -
> >> - [Bindable("visibleChanged")]
> >> - COMPILE::JS
> >> - public function get visible():Boolean
> >> - {
> >> - return positioner.style.display !== 'none';
> >> - }
> >> -
> >> - COMPILE::JS
> >> - public function set visible(value:Boolean):void
> >> - {
> >> - var oldValue:Boolean = positioner.style.display !== 'none';
> >> - if (value !== oldValue)
> >> - {
> >> - if (!value)
> >> - {
> >> - displayStyleForLayout =
> >> positioner.style.display;
> >> - positioner.style.display = 'none';
> >> - dispatchEvent(new Event('hide'));
> >> - }
> >> - else
> >> - {
> >> - if (displayStyleForLayout != null)
> >> - positioner.style.display =
> displayStyleForLayout;
> >> - dispatchEvent(new Event('show'));
> >> - }
> >> - dispatchEvent(new Event('visibleChanged'));
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @return The array of children.
> >> - * @royaleignorecoercion Array
> >> - */
> >> - COMPILE::JS
> >> - public function internalChildren():Array
> >> - {
> >> - return element.childNodes as Array;
> >> - }
> >> -
> >> - COMPILE::SWF
> >> - private var _model:IBeadModel;
> >> -
> >> - /**
> >> - * An IBeadModel that serves as the data model for the
> component.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::SWF
> >> - public function get model():Object
> >> - {
> >> - if (_model == null)
> >> - {
> >> - // addbead will set _model
> >> - addBead(new (ValuesManager.valuesImpl.getValue(this,
> >> "iBeadModel")) as IBead);
> >> - }
> >> - return _model;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - COMPILE::SWF
> >> - public function set model(value:Object):void
> >> - {
> >> - if (_model != value)
> >> - {
> >> - addBead(value as IBead);
> >> - dispatchEvent(new
> Event("modelChanged"));
> >> - }
> >> - }
> >> -
> >> - private var _view:IBeadView;
> >> -
> >> - /**
> >> - * An IBeadView that serves as the view for the component.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - * @royaleignorecoercion Class
> >> - * @royaleignorecoercion org.apache.royale.core.IBeadView
> >> - */
> >> - public function get view():IBeadView
> >> - {
> >> - if(!_view)
> >> - _view = loadBeadFromValuesManager(IBeadView,
> >> "iBeadView", this) as IBeadView;
> >> - return _view;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - public function set view(value:IBeadView):void
> >> - {
> >> - if (_view != value)
> >> - {
> >> - addBead(value);
> >> - dispatchEvent(new Event("viewChanged"));
> >> - }
> >> - }
> >> -
> >> - private var _id:String;
> >> -
> >> - /**
> >> - * An id property for MXML documents.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function get id():String
> >> - {
> >> - return _id;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - public function set id(value:String):void
> >> - {
> >> - if (_id !== value)
> >> - {
> >> - _id = value;
> >> - dispatchEvent(new Event("idChanged"));
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - element.id = _id;
> >> - }
> >> - }
> >> -
> >> - private var _style:Object;
> >> -
> >> - /**
> >> - * The object that contains
> >> - * "styles" and other associated
> >> - * name-value pairs. You can
> >> - * also specify a string in
> >> - * HTML style attribute format.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function get style():Object
> >> - {
> >> - return _style;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - * @royaleignorecoercion String
> >> - */
> >> - public function set style(value:Object):void
> >> - {
> >> - if (_style !== value)
> >> - {
> >> - if (value is String)
> >> - {
> >> - _style = ValuesManager.valuesImpl.
> parseStyles(value
> >> as String);
> >> - }
> >> - else
> >> - _style = value;
> >> - if (!isNaN(_y))
> >> - _style.top = _y;
> >> - if (!isNaN(_x))
> >> - _style.left = _x;
> >> - COMPILE::JS
> >> - {
> >> - if (parent)
> >> -
> ValuesManager.valuesImpl.applyStyles(this,
> >> _style);
> >> - }
> >> - dispatchEvent(new Event("stylesChanged"));
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * A list of type names. Often used for CSS
> >> - * type selector lookups.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - *
> >> - * @royalesuppresspublicvarwarning
> >> - */
> >> - public var typeNames:String;
> >> -
> >> - private var _className:String;
> >> -
> >> - /**
> >> - * The classname. Often used for CSS
> >> - * class selector lookups.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function get className():String
> >> - {
> >> - return _className;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - public function set className(value:String):void
> >> - {
> >> - if (_className !== value)
> >> - {
> >> - _className = value;
> >> -
> >> - COMPILE::JS
> >> - {
> >> - setClassName(computeFinalClassNames());
> >> - }
> >> -
> >> - dispatchEvent(new Event("classNameChanged"));
> >> - }
> >> - }
> >> -
> >> - COMPILE::JS
> >> - protected function computeFinalClassNames():String
> >> - {
> >> - return StringUtil.trim((_className ? _className : "") + "
> "
> >> + (typeNames ? typeNames : ""));
> >> - }
> >> -
> >> - COMPILE::JS
> >> - protected function setClassName(value:String):void
> >> - {
> >> - addStyles(element, value);
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IUIBase#element
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::SWF
> >> - public function get element():IRoyaleElement
> >> - {
> >> - return this;
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.Application#beads
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - *
> >> - * @royalesuppresspublicvarwarning
> >> - */
> >> - public var beads:Array;
> >> -
> >> - COMPILE::SWF
> >> - private var _beads:Vector.<IBead>;
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IStrand#addBead()
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.9
> >> - * @royaleignorecoercion org.apache.royale.core.IBeadModel
> >> - * @royaleignorecoercion org.apache.royale.core.IBeadView
> >> - */
> >> - override public function addBead(bead:IBead):void
> >> - {
> >> - var isView:Boolean;
> >> - if (!_beads)
> >> - _beads = new Vector.<IBead>;
> >> - _beads.push(bead);
> >> - if (bead is IBeadModel)
> >> - _model = bead as IBeadModel;
> >> - else if (bead is IBeadView)
> >> - {
> >> - _view = bead as IBeadView;
> >> - isView = true
> >> - }
> >> - bead.strand = this;
> >> -
> >> - if (isView) {
> >> - dispatchEvent(new Event("viewChanged"));
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IStrand#getBeadByType()
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::SWF
> >> - public function getBeadByType(
> >> classOrInterface:Class):IBead
> >> - {
> >> - for each (var bead:IBead in _beads)
> >> - {
> >> - if (bead is classOrInterface)
> >> - return bead;
> >> - }
> >> - return null;
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IStrand#removeBead()
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - COMPILE::SWF
> >> - public function removeBead(value:IBead):IBead
> >> - {
> >> - var n:int = _beads.length;
> >> - for (var i:int = 0; i < n; i++)
> >> - {
> >> - var bead:IBead = _beads[i];
> >> - if (bead == value)
> >> - {
> >> - _beads.splice(i, 1);
> >> - return bead;
> >> - }
> >> - }
> >> - return null;
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IParent#addElement()
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - * @royaleignorecoercion org.apache.royale.core.IUIBase
> >> - */
> >> - public function addElement(c:IChild,
> dispatchEvent:Boolean
> >> = true):void
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - if (c is IUIBase)
> >> - {
> >> - if (c is IRenderedObject)
> >> - addChild(IRenderedObject(c).$displayObject);
> >> - else
> >> - addChild(c as DisplayObject);
> >> - IUIBase(c).addedToParent();
> >> - }
> >> - else
> >> - addChild(c as DisplayObject);
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - element.appendChild(c.positioner);
> >> - (c as IUIBase).addedToParent();
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IParent#addElementAt()
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - * @royaleignorecoercion org.apache.royale.core.IUIBase
> >> - */
> >> - public function addElementAt(c:IChild, index:int,
> >> dispatchEvent:Boolean = true):void
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - if (c is IUIBase)
> >> - {
> >> - if (c is IRenderedObject)
> >> - addChildAt(IUIBase(c).$displayObject, index);
> >> - else
> >> - addChildAt(c as DisplayObject, index);
> >> - IUIBase(c).addedToParent();
> >> - }
> >> - else
> >> - addChildAt(c as DisplayObject, index);
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - var children:Array = internalChildren();
> >> - if (index >= children.length)
> >> - addElement(c);
> >> - else
> >> - {
> >> - element.insertBefore(c.positioner,
> >> - children[index]);
> >> - (c as IUIBase).addedToParent();
> >> - }
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IParent#getElementAt()
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function getElementAt(index:int):IChild
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - return getChildAt(index) as IChild;
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - var children:Array = internalChildren();
> >> - if (children.length == 0)
> >> - {
> >> - return null;
> >> - }
> >> - return children[index].royale_wrapper;
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IParent#getElementIndex()
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function getElementIndex(c:IChild):int
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - if (c is IRenderedObject)
> >> - return getChildIndex(IRenderedObject(
> >> c).$displayObject);
> >> - else
> >> - return getChildIndex(c as DisplayObject);
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - var children:Array = internalChildren();
> >> - var n:int = children.length;
> >> - for (var i:int = 0; i < n; i++)
> >> - {
> >> - if (children[i] === c.element)
> >> - return i;
> >> - }
> >> - return -1;
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IParent#removeElement()
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - * @royaleignorecoercion HTMLElement
> >> - */
> >> - public function removeElement(c:IChild, dispatchEvent:Boolean =
> >> true):void
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - if (c is IRenderedObject)
> >> - removeChild(IRenderedObject(c).$displayObject);
> >> - else
> >> - removeChild(c as DisplayObject);
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - element.removeChild(c.element as HTMLElement);
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.IParent#numElements
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - */
> >> - public function get numElements():int
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - return numChildren;
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - var children:Array = internalChildren();
> >> - return children.length;
> >> - }
> >> - }
> >> -
> >> - /**
> >> - * The method called when added to a parent. This is a good
> >> - * time to set up beads.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - * @royaleignorecoercion Class
> >> - * @royaleignorecoercion Number
> >> - */
> >> - public function addedToParent():void
> >> - {
> >> - var c:Class;
> >> -
> >> - COMPILE::JS
> >> - {
> >> - setClassName(computeFinalClassNames());
> >> -
> >> - if (style)
> >> - ValuesManager.valuesImpl.applyStyles(this, style);
> >> - }
> >> -
> >> - if (isNaN(_explicitWidth) &&
> isNaN(_percentWidth))
> >> - {
> >> - var value:* = ValuesManager.valuesImpl.
> >> getValue(this,"width");
> >> - if (value !== undefined)
> >> - {
> >> - if (value is String)
> >> - {
> >> - var s:String = String(value);
> >> - if (s.indexOf("%") > -1)
> >> - _percentWidth =
> >> Number(s.substring(0, s.length - 1));
> >> - else
> >> - {
> >> - if (s.indexOf("px") !== -1)
> >> - s = s.substring(0, s.length - 2);
> >> - _width = _explicitWidth = Number(s);
> >> - }
> >> - }
> >> - else
> >> - _width = _explicitWidth
> =
> >> value as Number;
> >> - }
> >> - }
> >> -
> >> - if (isNaN(_explicitHeight) &&
> >> isNaN(_percentHeight))
> >> - {
> >> - value = ValuesManager.valuesImpl.
> >> getValue(this,"height");
> >> - if (value !== undefined)
> >> - {
> >> - if (value is String)
> >> - {
> >> - s = String(value);
> >> - if (s.indexOf("%") !== -1)
> >> - _percentHeight =
> >> Number(s.substring(0, s.length - 1));
> >> - else
> >> - {
> >> - if (s.indexOf("px") !== -1)
> >> - s = s.substring(0, s.length - 2);
> >> - _height = _explicitHeight = Number(s);
> >> - }
> >> - }
> >> - else
> >> - _height =
> _explicitHeight
> >> = value as Number;
> >> - }
> >> - }
> >> -
> >> - for each (var bead:IBead in beads)
> >> - addBead(bead);
> >> -
> >> - loadBeadFromValuesManager(IBeadModel,
> >> "iBeadModel", this);
> >> - loadBeadFromValuesManager(IBeadView, "iBeadView", this);
> >> - loadBeadFromValuesManager(IBeadController,
> >> "iBeadController", this);
> >> - dispatchEvent(new Event("beadsAdded"));
> >> - }
> >> -
> >> - private var _measurementBead:IMeasurementBead;
> >> - /**
> >> - * A measurement bead, if one exists.
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.9
> >> - * @royaleignorecoercion org.apache.royale.core.
> IMeasurementBead
> >> - */
> >> - public function get measurementBead() : IMeasurementBead
> >> - {
> >> - if(!_measurementBead)
> >> - {
> >> - _measurementBead =
> loadBeadFromValuesManager(IMeasurementBead,
> >> "iMeasurementBead", this) as IMeasurementBead;
> >> - }
> >> - return _measurementBead;
> >> - }
> >> -
> >> - COMPILE::SWF
> >> - private var _stageProxy:StageProxy;
> >> -
> >> - /**
> >> - * @copy org.apache.royale.core.
> IUIBase#topMostEventDispatcher
> >> - *
> >> - * @langversion 3.0
> >> - * @playerversion Flash 10.2
> >> - * @playerversion AIR 2.6
> >> - * @productversion Royale 0.0
> >> - * @royaleignorecoercion org.apache.royale.core.
> >> WrappedHTMLElement
> >> - * @royaleignorecoercion org.apache.royale.events.
> >> IEventDispatcher
> >> - */
> >> - public function get topMostEventDispatcher():
> >> IEventDispatcher
> >> - {
> >> - COMPILE::SWF
> >> - {
> >> - if (!_stageProxy)
> >> - {
> >> - _stageProxy = new StageProxy(stage);
> >> - _stageProxy.addEventListener("removedFromStage",
> >> stageProxy_removedFromStageHandler);
> >> - }
> >> -
> >> - return _stageProxy;
> >> - }
> >> - COMPILE::JS
> >> - {
> >> - var e:WrappedHTMLElement = document.body as
> >> WrappedHTMLElement;
> >> - return e.royale_wrapper as IEventDispatcher;
> >> - }
> >> - }
> >> -
> >> - COMPILE::SWF
> >> - private function stageProxy_removedFromStageHandler(event:
> >> Event):void
> >> - {
> >> - _stageProxy = null;
> >> - }
> >> -
> >> - /**
> >> - * Rebroadcast an event from a sub component from the
> component.
> >> - */
> >> - protected function repeaterListener(event:Event):void
> >> - {
> >> - dispatchEvent(event);
> >> - }
> >> -
> >> - /**
> >> - * The HTMLElement used to position the component.
> >> - */
> >> - COMPILE::JS
> >> - public function get positioner():WrappedHTMLElement
> >> - {
> >> - return element;
> >> - }
> >> -
> >> - /**
> >> - * @private
> >> - */
> >> - COMPILE::JS
> >> - public function set positioner(value:WrappedHTMLElement):void
> >> - {
> >> - element = value;
> >> - }
> >> -
> >> - /**
> >> - * @return The actual element to be parented.
> >> - * @royaleignorecoercion org.apache.royale.core.
> >> WrappedHTMLElement
> >> - */
> >> - COMPILE::JS
> >> - protected function createElement():WrappedHTMLElement
> >> - {
> >> - addElementToWrapper(this,'div');
> >> - positioner.style.display = 'block';
> >> - //positioner.style.position = 'relative';
> >> - return element;
> >> - }
> >> -
> >> -
> >> - /**
> >> - * The HTMLElement used to position the component.
> >> - * @royaleignorecoercion String
> >> - */
> >> - COMPILE::JS
> >> - public function get alpha():Number
> >> - {
> >> - var stralpha:String = positioner.style.opacity as String;
> >> - var alpha:Number = parseFloat(stralpha);
> >> - return alpha;
> >> - }
> >> -
> >> - COMPILE::JS
> >> - public function set alpha(value:Number):void
> >> - {
> >> - positioner.style.opacity = value;
> >> - }
> >> -
> >> - /**
> >> - * @param value The event containing new style properties.
> >> - */
> >> - COMPILE::JS
> >> - protected function styleChangeHandler(value:
> >> ValueChangeEvent):void
> >> - {
> >> - var newStyle:Object = {};
> >> - newStyle[value.propertyName] = value.newValue;
> >> - ValuesManager.valuesImpl.applyStyles(this, newStyle);
> >> - }
> >> -
> >> - /**
> >> - * @royaleignorecoercion org.apache.royale.core.
> >> WrappedHTMLElement
> >> - * @royaleignorecoercion org.apache.royale.core.IParent
> >> - */
> >> - COMPILE::JS
> >> - public function get parent():IParent
> >> - {
> >> - var p:WrappedHTMLElement = this.positioner.parentNode as
> >> WrappedHTMLElement;
> >> - var wrapper:IParent = p ? p.royale_wrapper as IParent :
> null;
> >> - return wrapper;
> >> - }
> >> -
> >> - COMPILE::SWF
> >> - {
> >> - [SWFOverride(returns="flash.display.DisplayObjectContainer")]
> >> - override public function get parent():IParent
> >> - {
> >> - return super.parent as IParent;
> >> - }
> >> - }
> >> -
> >> - COMPILE::SWF
> >> - public function get transformElement():IRoyaleElement
> >> - {
> >> - return this;
> >> - }
> >> -
> >> - COMPILE::JS
> >> - public function get transformElement():
> WrappedHTMLElement
> >> - {
> >> - return element;
> >> - }
> >> -
> >> - COMPILE::SWF
> >> - {
> >> - [SWFOverride(params="flash.events.Event",
> >> altparams="org.apache.royale.events.Event:org.apache.
> >> royale.events.MouseEvent")]
> >> - override public function dispatchEvent(event:org.
> >> apache.royale.events.Event):Boolean
> >> - {
> >> - return super.dispatchEvent(event);
> >> - }
> >> - }
> >> -
> >> - }
> >> -}
> >>
> >> --
> >> To stop receiving notification emails like this one, please contact
> >> carlosrovira@apache.org.
> >>
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] 01/01: UIBase className changes to support new
cssclassList class methods like addStyles
Posted by Harbs <ha...@gmail.com>.
This is a huge functional change. I don’t know that I really agree with this.
You really haven’t answered my comments about the performance implications. I previously linked to jsperf tests. According to recent tests, addStyle seems to perform much more poorly that changing the className.
> On Apr 9, 2018, at 9:49 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi,
>
> this branch has the UIBase modifications that I made in Jewel. I think is
> time to complete the change so:
>
> @Alex: Can you take a look at the diff and see if you are ok with it? I
> think I do this with the considerations we discussed some weeks ago, but I
> think you never saw if that was finaly what you suggested.
>
> @Piotr: I think MDL is the project that needs to see how this changes
> affect it. Since you're the one who are maintaining it, can you check it
> and make the modifications in this branch needed? As we have no more
> MDLExamples it would be a problem for me to bring that code and see it.
>
> I see some other examples (like the other day fixing databinding flat) and
> seems to work ok since the rest are mainly royale components,
>
> I'd like to make this for 0.9.3 if possible to make Jewel as stable as
> possible
>
> Thanks
>
> Carlos
>
>
> 2018-04-09 20:41 GMT+02:00 <ca...@apache.org>:
>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> carlosrovira pushed a commit to branch feature/uibase-classname
>> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>>
>> commit cf06ede63e3e794198fd68e8647e9c6eceae383d
>> Author: Carlos Rovira <ca...@apache.org>
>> AuthorDate: Mon Apr 9 20:41:48 2018 +0200
>>
>> UIBase className changes to support new cssclassList class methods
>> like addStyles
>> ---
>> .../main/royale/org/apache/royale/core/UIBase.as | 18 +-
>> .../main/royale/org/apache/royale/core/UIBase.as | 1628
>> --------------------
>> 2 files changed, 9 insertions(+), 1637 deletions(-)
>>
>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/core/UIBase.as
>> b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> index b5f4dd1..f59d7f0 100644
>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> @@ -37,6 +37,7 @@ package org.apache.royale.core
>> {
>> import org.apache.royale.html.util.addElementToWrapper;
>> import org.apache.royale.utils.CSSUtils;
>> + import org.apache.royale.utils.cssclasslist.addStyles;
>> }
>>
>> /**
>> @@ -1085,11 +1086,13 @@ package org.apache.royale.core
>> {
>> if (_className !== value)
>> {
>> + _className = value;
>> +
>> COMPILE::JS
>> {
>> - setClassName(typeNames ? StringUtil.trim(value + ' '
>> + typeNames) : value);
>> + setClassName(computeFinalClassNames());
>> }
>> - _className = value;
>> +
>> dispatchEvent(new Event("classNameChanged"));
>> }
>> }
>> @@ -1097,13 +1100,13 @@ package org.apache.royale.core
>> COMPILE::JS
>> protected function computeFinalClassNames():String
>> {
>> - return (_className ? _className + " " : "") + (typeNames ?
>> typeNames : "");
>> + return StringUtil.trim((_className ? _className : "") + " "
>> + (typeNames ? typeNames : ""));
>> }
>>
>> COMPILE::JS
>> protected function setClassName(value:String):void
>> {
>> - element.className = value;
>> + addStyles(element, value);
>> }
>>
>> /**
>> @@ -1394,11 +1397,8 @@ package org.apache.royale.core
>>
>> COMPILE::JS
>> {
>> - if (typeNames)
>> - {
>> - setClassName(computeFinalClassNames());
>> - }
>> -
>> + setClassName(computeFinalClassNames());
>> +
>> if (style)
>> ValuesManager.valuesImpl.applyStyles(this, style);
>> }
>> diff --git a/frameworks/projects/Jewel/src/main/royale/org/apache/royale/core/UIBase.as
>> b/frameworks/projects/Jewel/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> deleted file mode 100644
>> index f59d7f0..0000000
>> --- a/frameworks/projects/Jewel/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> +++ /dev/null
>> @@ -1,1628 +0,0 @@
>> -///////////////////////////////////////////////////////////
>> /////////////////////
>> -//
>> -// Licensed to the Apache Software Foundation (ASF) under one or more
>> -// contributor license agreements. See the NOTICE file distributed with
>> -// this work for additional information regarding copyright ownership.
>> -// The ASF licenses this file to You under the Apache License, Version
>> 2.0
>> -// (the "License"); you may not use this file except in compliance with
>> -// the License. You may obtain a copy of the License at
>> -//
>> -// http://www.apache.org/licenses/LICENSE-2.0
>> -//
>> -// Unless required by applicable law or agreed to in writing, software
>> -// distributed under the License is distributed on an "AS IS" BASIS,
>> -// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> -// See the License for the specific language governing permissions and
>> -// limitations under the License.
>> -//
>> -///////////////////////////////////////////////////////////
>> /////////////////////
>> -package org.apache.royale.core
>> -{
>> - COMPILE::SWF
>> - {
>> - import flash.display.DisplayObject;
>> - import flash.display.Sprite;
>> - import flash.display.Stage;
>> - import org.apache.royale.events.utils.MouseEventConverter;
>> - }
>> -
>> - import org.apache.royale.events.Event;
>> - import org.apache.royale.events.IEventDispatcher;
>> - import org.apache.royale.events.MouseEvent;
>> - import org.apache.royale.events.ValueChangeEvent;
>> - import org.apache.royale.utils.loadBeadFromValuesManager;
>> - import org.apache.royale.utils.StringUtil;
>> -
>> - COMPILE::JS
>> - {
>> - import org.apache.royale.html.util.addElementToWrapper;
>> - import org.apache.royale.utils.CSSUtils;
>> - import org.apache.royale.utils.cssclasslist.addStyles;
>> - }
>> -
>> - /**
>> - * Set a different class for click events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="click", type="org.apache.royale.events.MouseEvent")]
>> -
>> - /**
>> - * Set a different class for rollOver events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="rollOver", type="org.apache.royale.events.MouseEvent")]
>> -
>> - /**
>> - * Set a different class for rollOut events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="rollOut", type="org.apache.royale.events.MouseEvent")]
>> -
>> - /**
>> - * Set a different class for mouseDown events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="mouseDown", type="org.apache.royale.events.MouseEvent")]
>> -
>> - /**
>> - * Set a different class for mouseUp events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="mouseUp", type="org.apache.royale.events.MouseEvent")]
>> -
>> - /**
>> - * Set a different class for mouseMove events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="mouseMove", type="org.apache.royale.events.MouseEvent")]
>> -
>> - /**
>> - * Set a different class for mouseOut events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="mouseOut", type="org.apache.royale.events.MouseEvent")]
>> -
>> - /**
>> - * Set a different class for mouseOver events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="mouseOver", type="org.apache.royale.
>> events.MouseEvent")]
>> - /**
>> - * Set a different class for mouseWheel events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="mouseWheel", type="org.apache.royale.
>> events.MouseEvent")]
>> -
>> - /**
>> - * Set a different class for doubleClick events so that
>> - * there aren't dependencies on the flash classes
>> - * on the JS side.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - [Event(name="doubleClick", type="org.apache.royale.
>> events.MouseEvent")]
>> -
>> - /**
>> - * The UIBase class is the base class for most composite user
>> interface
>> - * components. For the Flash Player, Buttons and Text controls may
>> - * have a different base class and therefore may not extend UIBase.
>> - * However all user interface components should implement IUIBase.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public class UIBase extends HTMLElementWrapper implements
>> IStrandWithModel, IEventDispatcher, IParentIUIBase, IStyleableObject,
>> ILayoutChild, IRoyaleElement
>> - {
>> - /**
>> - * Constructor.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function UIBase()
>> - {
>> - super();
>> -
>> - COMPILE::SWF
>> - {
>> - MouseEventConverter.setupInstanceConverters(this);
>> - doubleClickEnabled = true; // make JS and flash consistent
>> - }
>> -
>> - COMPILE::JS
>> - {
>> - createElement();
>> - }
>> - }
>> -
>> - COMPILE::SWF
>> - public function get $displayObject():DisplayObject
>> - {
>> - return this;
>> - }
>> -
>> - public function get royale_wrapper():Object
>> - {
>> - return this;
>> - }
>> - public function set royale_wrapper(value:Object):void
>> - {
>> - }
>> -
>> - private var _explicitWidth:Number;
>> -
>> - /**
>> - * The explicitly set width (as opposed to measured width
>> - * or percentage width).
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function get explicitWidth():Number
>> - {
>> - return _explicitWidth;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - public function set explicitWidth(value:Number):void
>> - {
>> - if (_explicitWidth == value)
>> - return;
>> -
>> - // width can be pixel or percent not both
>> - if (!isNaN(value))
>> - _percentWidth = NaN;
>> -
>> - _explicitWidth = value;
>> -
>> - dispatchEvent(new Event("explicitWidthChanged"));
>> - }
>> -
>> - private var _explicitHeight:Number;
>> -
>> - /**
>> - * The explicitly set width (as opposed to measured width
>> - * or percentage width).
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function get explicitHeight():Number
>> - {
>> - return _explicitHeight;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - public function set explicitHeight(value:Number):void
>> - {
>> - if (_explicitHeight == value)
>> - return;
>> -
>> - // height can be pixel or percent not both
>> - if (!isNaN(value))
>> - _percentHeight = NaN;
>> -
>> - _explicitHeight = value;
>> -
>> - dispatchEvent(new Event("explicitHeightChanged"));
>> - }
>> -
>> - private var _percentWidth:Number;
>> -
>> - /**
>> - * The requested percentage width this component
>> - * should have in the parent container. Note that
>> - * the actual percentage may be different if the
>> - * total is more than 100% or if there are other
>> - * components with explicitly set widths.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function get percentWidth():Number
>> - {
>> - return _percentWidth;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - public function set percentWidth(value:Number):void
>> - {
>> - COMPILE::SWF {
>> - if (_percentWidth == value)
>> - return;
>> -
>> - if (!isNaN(value))
>> - _explicitWidth = NaN;
>> -
>> - _percentWidth = value;
>> - }
>> - COMPILE::JS {
>> - this._percentWidth = value;
>> - this.positioner.style.width =
>> value.toString() + '%';
>> - if (!isNaN(value))
>> - this._explicitWidth = NaN;
>> - }
>> -
>> - dispatchEvent(new Event("percentWidthChanged"));
>> - }
>> -
>> - private var _percentHeight:Number;
>> -
>> - /**
>> - * The requested percentage height this component
>> - * should have in the parent container. Note that
>> - * the actual percentage may be different if the
>> - * total is more than 100% or if there are other
>> - * components with explicitly set heights.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function get percentHeight():Number
>> - {
>> - return _percentHeight;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - public function set percentHeight(value:Number):void
>> - {
>> - COMPILE::SWF {
>> - if (_percentHeight == value)
>> - return;
>> -
>> - if (!isNaN(value))
>> - _explicitHeight = NaN;
>> -
>> - _percentHeight = value;
>> - }
>> -
>> - COMPILE::JS {
>> - this._percentHeight = value;
>> - this.positioner.style.height =
>> value.toString() + '%';
>> - if (!isNaN(value))
>> - this._explicitHeight = NaN;
>> - }
>> -
>> - dispatchEvent(new Event("percentHeightChanged"));
>> - }
>> -
>> - private var _width:Number;
>> -
>> - [Bindable("widthChanged")]
>> - [PercentProxy("percentWidth")]
>> - /**
>> - * The width of the component. If no width has been previously
>> - * set the default width may be specified in the IValuesImpl
>> - * or determined as the bounding box around all child
>> - * components and graphics.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::SWF
>> - override public function get width():Number
>> - {
>> - var w:Number = _width;
>> - if (isNaN(w)) {
>> - w = $width;
>> - }
>> - return w;
>> - }
>> -
>> - [Bindable("widthChanged")]
>> - [PercentProxy("percentWidth")]
>> - /**
>> - * @royaleignorecoercion String
>> - */
>> - COMPILE::JS
>> - public function get width():Number
>> - {
>> - if(!isNaN(_explicitWidth))
>> - return _explicitWidth;
>> - var pixels:Number;
>> - var strpixels:String = element.style.width as String;
>> - if(strpixels == null)
>> - pixels = NaN;
>> - else
>> - pixels = CSSUtils.toNumber(strpixels,NaN);
>> - if (isNaN(pixels)) {
>> - pixels = positioner.offsetWidth;
>> - if (pixels == 0 && positioner.scrollWidth != 0) {
>> - // invisible child elements cause offsetWidth to be 0.
>> - pixels = positioner.scrollWidth;
>> - }
>> - }
>> - return pixels;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - COMPILE::SWF
>> - override public function set width(value:Number):void
>> - {
>> - if (explicitWidth !== value)
>> - {
>> - explicitWidth = value;
>> - }
>> -
>> - setWidth(value);
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - COMPILE::JS
>> - public function set width(value:Number):void
>> - {
>> - if (explicitWidth !== value)
>> - {
>> - explicitWidth = value;
>> - }
>> -
>> - setWidth(value);
>> - }
>> -
>> - /**
>> - * Retrieve the low-level bounding box width.
>> - * Not implemented in JS.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::SWF
>> - public function get $width():Number
>> - {
>> - return super.width;
>> - }
>> -
>> - private var _height:Number;
>> -
>> - [Bindable("heightChanged")]
>> - [PercentProxy("percentHeight")]
>> - /**
>> - * The height of the component. If no height has been previously
>> - * set the default height may be specified in the IValuesImpl
>> - * or determined as the bounding box around all child
>> - * components and graphics.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::SWF
>> - override public function get height():Number
>> - {
>> - var h:Number = _height;
>> - if (isNaN(h)) {
>> - h = $height;
>> - }
>> - return h;
>> - }
>> -
>> - [Bindable("heightChanged")]
>> - [PercentProxy("percentHeight")]
>> - /**
>> - * @royaleignorecoercion String
>> - */
>> - COMPILE::JS
>> - public function get height():Number
>> - {
>> - if(!isNaN(_explicitHeight))
>> - return _explicitHeight;
>> - var pixels:Number;
>> - var strpixels:String = element.style.height as String;
>> - if(strpixels == null)
>> - pixels = NaN;
>> - else
>> - pixels = CSSUtils.toNumber(strpixels,NaN);
>> - if (isNaN(pixels)) {
>> - pixels = positioner.offsetHeight;
>> - if (pixels == 0 && positioner.scrollHeight != 0) {
>> - // invisible child elements cause offsetHeight to be
>> 0.
>> - pixels = positioner.scrollHeight;
>> - }
>> - }
>> - return pixels;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - COMPILE::SWF
>> - override public function set height(value:Number):void
>> - {
>> - if (explicitHeight !== value)
>> - {
>> - explicitHeight = value;
>> - }
>> -
>> - setHeight(value);
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - COMPILE::JS
>> - public function set height(value:Number):void
>> - {
>> - if (explicitHeight !== value)
>> - {
>> - explicitHeight = value;
>> - }
>> -
>> - setHeight(value);
>> - }
>> -
>> - /**
>> - * Retrieve the low-level bounding box height.
>> - * Not implemented in JS.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::SWF
>> - public function get $height():Number
>> - {
>> - return super.height;
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.ILayoutChild#setHeight
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function setHeight(value:Number, noEvent:Boolean =
>> false):void
>> - {
>> - if (_height !== value)
>> - {
>> - _height = value;
>> - COMPILE::JS
>> - {
>> - this.positioner.style.height = value.toString() +
>> 'px';
>> - }
>> - if (!noEvent)
>> - dispatchEvent(new Event("heightChanged"));
>> - }
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.ILayoutChild#setWidth
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function setWidth(value:Number, noEvent:Boolean =
>> false):void
>> - {
>> - if (_width !== value)
>> - {
>> - _width = value;
>> - COMPILE::JS
>> - {
>> - this.positioner.style.width = value.toString() + 'px';
>> - }
>> - if (!noEvent)
>> - dispatchEvent(new Event("widthChanged"));
>> - }
>> - }
>> -
>> - /**
>> - * @private
>> - * Used by layout to prevent causing unnecessary reflows when
>> measuring.
>> - */
>> - private var _measuredWidth:Number;
>> -
>> - public function get measuredWidth():Number
>> - {
>> - return _measuredWidth;
>> - }
>> -
>> - public function set measuredWidth(value:Number):void
>> - {
>> - _measuredWidth = value;
>> - }
>> - /**
>> - * @private
>> - * Used by layout to prevent causing unnecessary reflows when
>> measuring.
>> - */
>> - private var _measuredHeight:Number;
>> -
>> - public function get measuredHeight():Number
>> - {
>> - return _measuredHeight;
>> - }
>> -
>> - public function set measuredHeight(value:Number):void
>> - {
>> - _measuredHeight = value;
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.ILayoutChild#setWidthAndHeight
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function setWidthAndHeight(newWidth:Number,
>> newHeight:Number, noEvent:Boolean = false):void
>> - {
>> - if (_width !== newWidth)
>> - {
>> - _width = newWidth;
>> - COMPILE::JS
>> - {
>> - this.positioner.style.width = newWidth.toString() +
>> 'px';
>> - }
>> - if (!noEvent)
>> - dispatchEvent(new Event("widthChanged"));
>> - }
>> - if (_height !== newHeight)
>> - {
>> - _height = newHeight;
>> - COMPILE::JS
>> - {
>> - this.positioner.style.height = newHeight.toString() +
>> 'px';
>> - }
>> - if (!noEvent)
>> - dispatchEvent(new Event("heightChanged"));
>> - }
>> - dispatchEvent(new Event("sizeChanged"));
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.ILayoutChild#
>> isWidthSizedToContent
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function isWidthSizedToContent():Boolean
>> - {
>> - if (!isNaN(_explicitWidth))
>> - return false;
>> - if (!isNaN(_percentWidth))
>> - return false;
>> - var left:* = ValuesManager.valuesImpl.getValue(this, "left");
>> - var right:* = ValuesManager.valuesImpl.getValue(this,
>> "right");
>> - return (left === undefined || right === undefined);
>> -
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.ILayoutChild#
>> isHeightSizedToContent
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function isHeightSizedToContent():Boolean
>> - {
>> - if (!isNaN(_explicitHeight))
>> - return false;
>> - if (!isNaN(_percentHeight))
>> - return false;
>> - var top:* = ValuesManager.valuesImpl.getValue(this, "top");
>> - var bottom:* = ValuesManager.valuesImpl.getValue(this,
>> "bottom");
>> - return (top === undefined || bottom === undefined);
>> - }
>> -
>> - private var _x:Number;
>> -
>> - /**
>> - * @private
>> - */
>> - COMPILE::SWF
>> - override public function set x(value:Number):void
>> - {
>> - super.x = _x = value;
>> - if (!style)
>> - style = { left: value };
>> - else
>> - style.left = value;
>> - }
>> - /**
>> - * @royaleignorecoercion HTMLElement
>> - */
>> - COMPILE::JS
>> - public function set x(value:Number):void
>> - {
>> - _x = value;
>> - setX(value);
>> - }
>> -
>> - /**
>> - * @royaleignorecoercion String
>> - * @royaleignorecoercion HTMLElement
>> - */
>> - COMPILE::JS
>> - public function get x():Number
>> - {
>> - if(!isNaN(_x))
>> - return _x
>> - var strpixels:String = positioner.style.left as String;
>> - var pixels:Number = parseFloat(strpixels);
>> - if (isNaN(pixels))
>> - {
>> - pixels = positioner.offsetLeft;
>> - if (positioner.parentNode != positioner.offsetParent)
>> - pixels -= (positioner.parentNode as
>> HTMLElement).offsetLeft;
>> - }
>> - return pixels;
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.ILayoutChild#setX
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - * @royaleignorecoercion HTMLElement
>> - */
>> - public function setX(value:Number):void
>> - {
>> - COMPILE::SWF
>> - {
>> - super.x = value;
>> - }
>> - COMPILE::JS
>> - {
>> - //positioner.style.position = 'absolute';
>> - if (positioner.parentNode != positioner.offsetParent)
>> - value += (positioner.parentNode as
>> HTMLElement).offsetLeft;
>> - positioner.style.left = value.toString() +
>> 'px';
>> - }
>> - }
>> -
>> - private var _y:Number;
>> -
>> - /**
>> - * @private
>> - */
>> - COMPILE::SWF
>> - override public function set y(value:Number):void
>> - {
>> - super.y = _y = value;
>> - if (!style)
>> - style = { top: value };
>> - else
>> - style.top = value;
>> - }
>> -
>> - /**
>> - * @royaleignorecoercion HTMLElement
>> - */
>> - COMPILE::JS
>> - public function set y(value:Number):void
>> - {
>> - _y = value;
>> - setY(value);
>> - }
>> -
>> - /**
>> - * @royaleignorecoercion String
>> - * @royaleignorecoercion HTMLElement
>> - */
>> - COMPILE::JS
>> - public function get y():Number
>> - {
>> - if(!isNaN(_y))
>> - return _y
>> - var strpixels:String = positioner.style.top as String;
>> - var pixels:Number = parseFloat(strpixels);
>> - if (isNaN(pixels))
>> - {
>> - pixels = positioner.offsetTop;
>> - if (positioner.parentNode != positioner.offsetParent)
>> - pixels -= (positioner.parentNode as
>> HTMLElement).offsetTop;
>> - }
>> - return pixels;
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.ILayoutChild#setY
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - * @royaleignorecoercion HTMLElement
>> - */
>> - public function setY(value:Number):void
>> - {
>> - COMPILE::SWF
>> - {
>> - super.y = value;
>> - }
>> - COMPILE::JS
>> - {
>> - //positioner.style.position = 'absolute';
>> - if (positioner.parentNode != positioner.offsetParent)
>> - value += (positioner.parentNode as
>> HTMLElement).offsetTop;
>> - positioner.style.top = value.toString() +
>> 'px';
>> - }
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - [Bindable("visibleChanged")]
>> - COMPILE::SWF
>> - override public function set visible(value:Boolean):void
>> - {
>> - super.visible = value;
>> - dispatchEvent(new Event(value?"show":"hide"));
>> - dispatchEvent(new Event("visibleChanged"));
>> - }
>> -
>> - COMPILE::JS
>> - private var displayStyleForLayout:String;
>> -
>> - /**
>> - * The display style is used for both visible
>> - * and layout so is managed as a special case.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::JS
>> - public function setDisplayStyleForLayout(
>> value:String):void
>> - {
>> - if (positioner.style.display !== 'none')
>> - positioner.style.display = value;
>> - else
>> - displayStyleForLayout = value;
>> - }
>> -
>> - [Bindable("visibleChanged")]
>> - COMPILE::JS
>> - public function get visible():Boolean
>> - {
>> - return positioner.style.display !== 'none';
>> - }
>> -
>> - COMPILE::JS
>> - public function set visible(value:Boolean):void
>> - {
>> - var oldValue:Boolean = positioner.style.display !== 'none';
>> - if (value !== oldValue)
>> - {
>> - if (!value)
>> - {
>> - displayStyleForLayout =
>> positioner.style.display;
>> - positioner.style.display = 'none';
>> - dispatchEvent(new Event('hide'));
>> - }
>> - else
>> - {
>> - if (displayStyleForLayout != null)
>> - positioner.style.display = displayStyleForLayout;
>> - dispatchEvent(new Event('show'));
>> - }
>> - dispatchEvent(new Event('visibleChanged'));
>> - }
>> - }
>> -
>> - /**
>> - * @return The array of children.
>> - * @royaleignorecoercion Array
>> - */
>> - COMPILE::JS
>> - public function internalChildren():Array
>> - {
>> - return element.childNodes as Array;
>> - }
>> -
>> - COMPILE::SWF
>> - private var _model:IBeadModel;
>> -
>> - /**
>> - * An IBeadModel that serves as the data model for the component.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::SWF
>> - public function get model():Object
>> - {
>> - if (_model == null)
>> - {
>> - // addbead will set _model
>> - addBead(new (ValuesManager.valuesImpl.getValue(this,
>> "iBeadModel")) as IBead);
>> - }
>> - return _model;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - COMPILE::SWF
>> - public function set model(value:Object):void
>> - {
>> - if (_model != value)
>> - {
>> - addBead(value as IBead);
>> - dispatchEvent(new Event("modelChanged"));
>> - }
>> - }
>> -
>> - private var _view:IBeadView;
>> -
>> - /**
>> - * An IBeadView that serves as the view for the component.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - * @royaleignorecoercion Class
>> - * @royaleignorecoercion org.apache.royale.core.IBeadView
>> - */
>> - public function get view():IBeadView
>> - {
>> - if(!_view)
>> - _view = loadBeadFromValuesManager(IBeadView,
>> "iBeadView", this) as IBeadView;
>> - return _view;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - public function set view(value:IBeadView):void
>> - {
>> - if (_view != value)
>> - {
>> - addBead(value);
>> - dispatchEvent(new Event("viewChanged"));
>> - }
>> - }
>> -
>> - private var _id:String;
>> -
>> - /**
>> - * An id property for MXML documents.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function get id():String
>> - {
>> - return _id;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - public function set id(value:String):void
>> - {
>> - if (_id !== value)
>> - {
>> - _id = value;
>> - dispatchEvent(new Event("idChanged"));
>> - }
>> - COMPILE::JS
>> - {
>> - element.id = _id;
>> - }
>> - }
>> -
>> - private var _style:Object;
>> -
>> - /**
>> - * The object that contains
>> - * "styles" and other associated
>> - * name-value pairs. You can
>> - * also specify a string in
>> - * HTML style attribute format.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function get style():Object
>> - {
>> - return _style;
>> - }
>> -
>> - /**
>> - * @private
>> - * @royaleignorecoercion String
>> - */
>> - public function set style(value:Object):void
>> - {
>> - if (_style !== value)
>> - {
>> - if (value is String)
>> - {
>> - _style = ValuesManager.valuesImpl.parseStyles(value
>> as String);
>> - }
>> - else
>> - _style = value;
>> - if (!isNaN(_y))
>> - _style.top = _y;
>> - if (!isNaN(_x))
>> - _style.left = _x;
>> - COMPILE::JS
>> - {
>> - if (parent)
>> - ValuesManager.valuesImpl.applyStyles(this,
>> _style);
>> - }
>> - dispatchEvent(new Event("stylesChanged"));
>> - }
>> - }
>> -
>> - /**
>> - * A list of type names. Often used for CSS
>> - * type selector lookups.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - *
>> - * @royalesuppresspublicvarwarning
>> - */
>> - public var typeNames:String;
>> -
>> - private var _className:String;
>> -
>> - /**
>> - * The classname. Often used for CSS
>> - * class selector lookups.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function get className():String
>> - {
>> - return _className;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - public function set className(value:String):void
>> - {
>> - if (_className !== value)
>> - {
>> - _className = value;
>> -
>> - COMPILE::JS
>> - {
>> - setClassName(computeFinalClassNames());
>> - }
>> -
>> - dispatchEvent(new Event("classNameChanged"));
>> - }
>> - }
>> -
>> - COMPILE::JS
>> - protected function computeFinalClassNames():String
>> - {
>> - return StringUtil.trim((_className ? _className : "") + " "
>> + (typeNames ? typeNames : ""));
>> - }
>> -
>> - COMPILE::JS
>> - protected function setClassName(value:String):void
>> - {
>> - addStyles(element, value);
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IUIBase#element
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::SWF
>> - public function get element():IRoyaleElement
>> - {
>> - return this;
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.Application#beads
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - *
>> - * @royalesuppresspublicvarwarning
>> - */
>> - public var beads:Array;
>> -
>> - COMPILE::SWF
>> - private var _beads:Vector.<IBead>;
>> -
>> - /**
>> - * @copy org.apache.royale.core.IStrand#addBead()
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.9
>> - * @royaleignorecoercion org.apache.royale.core.IBeadModel
>> - * @royaleignorecoercion org.apache.royale.core.IBeadView
>> - */
>> - override public function addBead(bead:IBead):void
>> - {
>> - var isView:Boolean;
>> - if (!_beads)
>> - _beads = new Vector.<IBead>;
>> - _beads.push(bead);
>> - if (bead is IBeadModel)
>> - _model = bead as IBeadModel;
>> - else if (bead is IBeadView)
>> - {
>> - _view = bead as IBeadView;
>> - isView = true
>> - }
>> - bead.strand = this;
>> -
>> - if (isView) {
>> - dispatchEvent(new Event("viewChanged"));
>> - }
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IStrand#getBeadByType()
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::SWF
>> - public function getBeadByType(
>> classOrInterface:Class):IBead
>> - {
>> - for each (var bead:IBead in _beads)
>> - {
>> - if (bead is classOrInterface)
>> - return bead;
>> - }
>> - return null;
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IStrand#removeBead()
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - COMPILE::SWF
>> - public function removeBead(value:IBead):IBead
>> - {
>> - var n:int = _beads.length;
>> - for (var i:int = 0; i < n; i++)
>> - {
>> - var bead:IBead = _beads[i];
>> - if (bead == value)
>> - {
>> - _beads.splice(i, 1);
>> - return bead;
>> - }
>> - }
>> - return null;
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IParent#addElement()
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - * @royaleignorecoercion org.apache.royale.core.IUIBase
>> - */
>> - public function addElement(c:IChild, dispatchEvent:Boolean
>> = true):void
>> - {
>> - COMPILE::SWF
>> - {
>> - if (c is IUIBase)
>> - {
>> - if (c is IRenderedObject)
>> - addChild(IRenderedObject(c).$displayObject);
>> - else
>> - addChild(c as DisplayObject);
>> - IUIBase(c).addedToParent();
>> - }
>> - else
>> - addChild(c as DisplayObject);
>> - }
>> - COMPILE::JS
>> - {
>> - element.appendChild(c.positioner);
>> - (c as IUIBase).addedToParent();
>> - }
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IParent#addElementAt()
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - * @royaleignorecoercion org.apache.royale.core.IUIBase
>> - */
>> - public function addElementAt(c:IChild, index:int,
>> dispatchEvent:Boolean = true):void
>> - {
>> - COMPILE::SWF
>> - {
>> - if (c is IUIBase)
>> - {
>> - if (c is IRenderedObject)
>> - addChildAt(IUIBase(c).$displayObject, index);
>> - else
>> - addChildAt(c as DisplayObject, index);
>> - IUIBase(c).addedToParent();
>> - }
>> - else
>> - addChildAt(c as DisplayObject, index);
>> - }
>> - COMPILE::JS
>> - {
>> - var children:Array = internalChildren();
>> - if (index >= children.length)
>> - addElement(c);
>> - else
>> - {
>> - element.insertBefore(c.positioner,
>> - children[index]);
>> - (c as IUIBase).addedToParent();
>> - }
>> - }
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IParent#getElementAt()
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function getElementAt(index:int):IChild
>> - {
>> - COMPILE::SWF
>> - {
>> - return getChildAt(index) as IChild;
>> - }
>> - COMPILE::JS
>> - {
>> - var children:Array = internalChildren();
>> - if (children.length == 0)
>> - {
>> - return null;
>> - }
>> - return children[index].royale_wrapper;
>> - }
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IParent#getElementIndex()
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function getElementIndex(c:IChild):int
>> - {
>> - COMPILE::SWF
>> - {
>> - if (c is IRenderedObject)
>> - return getChildIndex(IRenderedObject(
>> c).$displayObject);
>> - else
>> - return getChildIndex(c as DisplayObject);
>> - }
>> - COMPILE::JS
>> - {
>> - var children:Array = internalChildren();
>> - var n:int = children.length;
>> - for (var i:int = 0; i < n; i++)
>> - {
>> - if (children[i] === c.element)
>> - return i;
>> - }
>> - return -1;
>> - }
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IParent#removeElement()
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - * @royaleignorecoercion HTMLElement
>> - */
>> - public function removeElement(c:IChild, dispatchEvent:Boolean =
>> true):void
>> - {
>> - COMPILE::SWF
>> - {
>> - if (c is IRenderedObject)
>> - removeChild(IRenderedObject(c).$displayObject);
>> - else
>> - removeChild(c as DisplayObject);
>> - }
>> - COMPILE::JS
>> - {
>> - element.removeChild(c.element as HTMLElement);
>> - }
>> - }
>> -
>> - /**
>> - * @copy org.apache.royale.core.IParent#numElements
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - */
>> - public function get numElements():int
>> - {
>> - COMPILE::SWF
>> - {
>> - return numChildren;
>> - }
>> - COMPILE::JS
>> - {
>> - var children:Array = internalChildren();
>> - return children.length;
>> - }
>> - }
>> -
>> - /**
>> - * The method called when added to a parent. This is a good
>> - * time to set up beads.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - * @royaleignorecoercion Class
>> - * @royaleignorecoercion Number
>> - */
>> - public function addedToParent():void
>> - {
>> - var c:Class;
>> -
>> - COMPILE::JS
>> - {
>> - setClassName(computeFinalClassNames());
>> -
>> - if (style)
>> - ValuesManager.valuesImpl.applyStyles(this, style);
>> - }
>> -
>> - if (isNaN(_explicitWidth) && isNaN(_percentWidth))
>> - {
>> - var value:* = ValuesManager.valuesImpl.
>> getValue(this,"width");
>> - if (value !== undefined)
>> - {
>> - if (value is String)
>> - {
>> - var s:String = String(value);
>> - if (s.indexOf("%") > -1)
>> - _percentWidth =
>> Number(s.substring(0, s.length - 1));
>> - else
>> - {
>> - if (s.indexOf("px") !== -1)
>> - s = s.substring(0, s.length - 2);
>> - _width = _explicitWidth = Number(s);
>> - }
>> - }
>> - else
>> - _width = _explicitWidth =
>> value as Number;
>> - }
>> - }
>> -
>> - if (isNaN(_explicitHeight) &&
>> isNaN(_percentHeight))
>> - {
>> - value = ValuesManager.valuesImpl.
>> getValue(this,"height");
>> - if (value !== undefined)
>> - {
>> - if (value is String)
>> - {
>> - s = String(value);
>> - if (s.indexOf("%") !== -1)
>> - _percentHeight =
>> Number(s.substring(0, s.length - 1));
>> - else
>> - {
>> - if (s.indexOf("px") !== -1)
>> - s = s.substring(0, s.length - 2);
>> - _height = _explicitHeight = Number(s);
>> - }
>> - }
>> - else
>> - _height = _explicitHeight
>> = value as Number;
>> - }
>> - }
>> -
>> - for each (var bead:IBead in beads)
>> - addBead(bead);
>> -
>> - loadBeadFromValuesManager(IBeadModel,
>> "iBeadModel", this);
>> - loadBeadFromValuesManager(IBeadView, "iBeadView", this);
>> - loadBeadFromValuesManager(IBeadController,
>> "iBeadController", this);
>> - dispatchEvent(new Event("beadsAdded"));
>> - }
>> -
>> - private var _measurementBead:IMeasurementBead;
>> - /**
>> - * A measurement bead, if one exists.
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.9
>> - * @royaleignorecoercion org.apache.royale.core.IMeasurementBead
>> - */
>> - public function get measurementBead() : IMeasurementBead
>> - {
>> - if(!_measurementBead)
>> - {
>> - _measurementBead = loadBeadFromValuesManager(IMeasurementBead,
>> "iMeasurementBead", this) as IMeasurementBead;
>> - }
>> - return _measurementBead;
>> - }
>> -
>> - COMPILE::SWF
>> - private var _stageProxy:StageProxy;
>> -
>> - /**
>> - * @copy org.apache.royale.core.IUIBase#topMostEventDispatcher
>> - *
>> - * @langversion 3.0
>> - * @playerversion Flash 10.2
>> - * @playerversion AIR 2.6
>> - * @productversion Royale 0.0
>> - * @royaleignorecoercion org.apache.royale.core.
>> WrappedHTMLElement
>> - * @royaleignorecoercion org.apache.royale.events.
>> IEventDispatcher
>> - */
>> - public function get topMostEventDispatcher():
>> IEventDispatcher
>> - {
>> - COMPILE::SWF
>> - {
>> - if (!_stageProxy)
>> - {
>> - _stageProxy = new StageProxy(stage);
>> - _stageProxy.addEventListener("removedFromStage",
>> stageProxy_removedFromStageHandler);
>> - }
>> -
>> - return _stageProxy;
>> - }
>> - COMPILE::JS
>> - {
>> - var e:WrappedHTMLElement = document.body as
>> WrappedHTMLElement;
>> - return e.royale_wrapper as IEventDispatcher;
>> - }
>> - }
>> -
>> - COMPILE::SWF
>> - private function stageProxy_removedFromStageHandler(event:
>> Event):void
>> - {
>> - _stageProxy = null;
>> - }
>> -
>> - /**
>> - * Rebroadcast an event from a sub component from the component.
>> - */
>> - protected function repeaterListener(event:Event):void
>> - {
>> - dispatchEvent(event);
>> - }
>> -
>> - /**
>> - * The HTMLElement used to position the component.
>> - */
>> - COMPILE::JS
>> - public function get positioner():WrappedHTMLElement
>> - {
>> - return element;
>> - }
>> -
>> - /**
>> - * @private
>> - */
>> - COMPILE::JS
>> - public function set positioner(value:WrappedHTMLElement):void
>> - {
>> - element = value;
>> - }
>> -
>> - /**
>> - * @return The actual element to be parented.
>> - * @royaleignorecoercion org.apache.royale.core.
>> WrappedHTMLElement
>> - */
>> - COMPILE::JS
>> - protected function createElement():WrappedHTMLElement
>> - {
>> - addElementToWrapper(this,'div');
>> - positioner.style.display = 'block';
>> - //positioner.style.position = 'relative';
>> - return element;
>> - }
>> -
>> -
>> - /**
>> - * The HTMLElement used to position the component.
>> - * @royaleignorecoercion String
>> - */
>> - COMPILE::JS
>> - public function get alpha():Number
>> - {
>> - var stralpha:String = positioner.style.opacity as String;
>> - var alpha:Number = parseFloat(stralpha);
>> - return alpha;
>> - }
>> -
>> - COMPILE::JS
>> - public function set alpha(value:Number):void
>> - {
>> - positioner.style.opacity = value;
>> - }
>> -
>> - /**
>> - * @param value The event containing new style properties.
>> - */
>> - COMPILE::JS
>> - protected function styleChangeHandler(value:
>> ValueChangeEvent):void
>> - {
>> - var newStyle:Object = {};
>> - newStyle[value.propertyName] = value.newValue;
>> - ValuesManager.valuesImpl.applyStyles(this, newStyle);
>> - }
>> -
>> - /**
>> - * @royaleignorecoercion org.apache.royale.core.
>> WrappedHTMLElement
>> - * @royaleignorecoercion org.apache.royale.core.IParent
>> - */
>> - COMPILE::JS
>> - public function get parent():IParent
>> - {
>> - var p:WrappedHTMLElement = this.positioner.parentNode as
>> WrappedHTMLElement;
>> - var wrapper:IParent = p ? p.royale_wrapper as IParent : null;
>> - return wrapper;
>> - }
>> -
>> - COMPILE::SWF
>> - {
>> - [SWFOverride(returns="flash.display.DisplayObjectContainer")]
>> - override public function get parent():IParent
>> - {
>> - return super.parent as IParent;
>> - }
>> - }
>> -
>> - COMPILE::SWF
>> - public function get transformElement():IRoyaleElement
>> - {
>> - return this;
>> - }
>> -
>> - COMPILE::JS
>> - public function get transformElement():WrappedHTMLElement
>> - {
>> - return element;
>> - }
>> -
>> - COMPILE::SWF
>> - {
>> - [SWFOverride(params="flash.events.Event",
>> altparams="org.apache.royale.events.Event:org.apache.
>> royale.events.MouseEvent")]
>> - override public function dispatchEvent(event:org.
>> apache.royale.events.Event):Boolean
>> - {
>> - return super.dispatchEvent(event);
>> - }
>> - }
>> -
>> - }
>> -}
>>
>> --
>> To stop receiving notification emails like this one, please contact
>> carlosrovira@apache.org.
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira