The original intent of positioner was to allow the element to be different. The NumericStepper was the use case. The positioner was to be the enclosing div or DisplayObjectContainer. The element was to be the input or TextField. We thought there might be more complex components that would benefit from that treatment.
The problem is, I think most developers would access element for everything and simply forget the positioner. Also, element and positioner should really be hidden from app developers are they are platform dependent (or should be IMO). So a component like NumericStepper might let you do: stepper.inputField by that itself is a FlexJS component, TextInput, so that would be safe. Likewise for the buttons. At this point, I'm not sure positioner is valuable enough to even keep. And element/flexjs_wrapper are closely paired. —peter On 9/26/17, 9:02 AM, "Harbs" <harbs.li...@gmail.com> wrote: >Yishay and I were working on drag/drop today and we were modifying one of >the classes you wrote for generating the drag image. > >The code can be simplified by using cloneNode() and stuffing the results >into the element. The thing is, it does not work until you assign the >flexjs_wrapper to the element. IMO, calling the element setter should do >that automatically. > >On a similar note, Every IUIBase object has a positioner set. I don’t >know of a single class which has a different positioner than the element. >It seems to me that positioner should be a getter (which normally returns >the element) that’s overridden for classes which need a different one. >That will save memory for every IUIBase created. > >Harbs > >> On Sep 26, 2017, at 3:23 PM, Peter Ent <p...@adobe.com.INVALID> wrote: >> >> The setter for element is in HTMLElementWrapper, the super class for >> UIBase. The setter for flexes_wrapper is in UIBase. So if the element >> setter were to also set the flexjs_wrapper, it would have to be an >> override in UIBase to do it. At least that¹s how I understand it. >> >> Could you elaborate a little more on the issue that is raising this >> concern? >> >> Your question made me scan through these classes. Looking at this code >>now >> makes me think we can do a better and more consistent job organizing it >> for Royale. After all, having code that can be quickly understood and >> modified is important. >> >> ‹peter >> >> On 9/26/17, 7:13 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> Currently, setting the element of a IUIBase will not work correctly >>> because the flexjs_wrapper is not set. This makes it error prone when >>> there¹s a need to work with the underlying DOM elements for HTML >>>output. >>> >>> I cannot think of a reason why the wrapper should not be set when >>>calling >>> the element setter. Instead of setting the flexjs_wrapper in >>> createElement(), it seems to me that it should be set in the element >>> setter in HTMLElementWrapper. >>> >>> Anyone have a reason not to do this? >>> >>> Harbs >> >
