Hi Harbs,
I'm adding Royale dev list.
I just checked your changes with more complex app and apart of many
conflicts during merge with my custom SDK I don't see any problems. Take a
look into my comments to one of your commit. Once you do that from my sight
is green light to merge it to develop.
Harbs,
Give me couple of days and I will pick up that branch and try it out. I
will also review those changes and give the feedback.
Thanks!
2017-09-26 20:50 GMT+02:00 Harbs :
> I think I’m done. Any reason to not merge into develop?
>
> > On Sep 26, 2017, at 7:01 PM, Piotr Zarzycki
> wrote:
>
I think I’m done. Any reason to not merge into develop?
> On Sep 26, 2017, at 7:01 PM, Piotr Zarzycki wrote:
>
> Harbs,
>
> Please push those changes into separate branch "feature/" no matter how non
> serious it look. I hope your changes will simplify things.
>
> Thank you!
>
>
> 2017-09-26
No. I just used it because it’s the simplest UI component. I don’t remember off
hand what I needed it for.
> On Sep 26, 2017, at 8:59 PM, Alex Harui wrote:
>
> You aren't the only one, but why did you do it? Is there some subclass of
> UIBase missing from the component set? ScratchPad? Space
You aren't the only one, but why did you do it? Is there some subclass of
UIBase missing from the component set? ScratchPad? Spacer?
On 9/26/17, 10:53 AM, "Harbs" wrote:
>I’ve used it.
>
>> On Sep 26, 2017, at 8:41 PM, Alex Harui
>>wrote:
>>
>> IMO, the first question is, do we really need
I’ve used it.
> On Sep 26, 2017, at 8:41 PM, Alex Harui wrote:
>
> IMO, the first question is, do we really need to support "new UIBase()"?
Funny you mention that. I added addElementToWrapper() as a top level function
which attaches elements to UIBases. I have just finished implementing this in
all Basic and MDL components.
That pretty much removes the need to call super.
I’m committing my changes soon (to a branch).
> On Sep 26,
IMO, the first question is, do we really need to support "new UIBase()"?
I remember being surprised in regular Flex when folks did "new
UIComponent()". There aren't abstract classes in ActionScript, but I
would have made UIComponent and UIBase abstract if I could.
But if the answer is that we wan
Huh? Why would the subclass call super.createElement() and assume the element
will not be created?
FWIW, super.createElement() is barely called, and when it is (from all the
cases I’ve found so far in the whole Basic and MDL), it’s expecting the default
div element.
> On Sep 26, 2017, at 8:15
IIRC, UIBase has that code so if you do "new UIBase()" you will get an
element, but if subclasses call super.createElement() by habit, we won't
overwrite anybody's element. It isn't truly PAYG, it depends on how folks
feel about "requiring" that you know not to call super.createElement() on
UIBase
FYI: TableRowItemRenderer in MDL has a separate positioner.
> On Sep 26, 2017, at 7:01 PM, Piotr Zarzycki wrote:
>
> Harbs,
>
> Please push those changes into separate branch "feature/" no matter how non
> serious it look. I hope your changes will simplify things.
>
> Thank you!
>
>
> 2017-0
Harbs,
Please push those changes into separate branch "feature/" no matter how non
serious it look. I hope your changes will simplify things.
Thank you!
2017-09-26 17:54 GMT+02:00 Harbs :
> I’m working on refactoring this.
>
> Is there a reason for the null check in UIBase.createElement()?
>
>
I’m working on refactoring this.
Is there a reason for the null check in UIBase.createElement()?
Why would createElement be called if the element is already created? None of
the subclasses have this null check.
if (element == null)
element = document.createElement('div') as WrappedHTMLEleme
I believe there are components where more than one HTMLElement is created
but only one is (and can be) assigned as "element" but all have
flexjs_wrapper assigned to the wrapping IUIBase.
If in fact no components need a separate positioner, it is fine to remove
it. But if we keep it, even as a get
@Harbs: yes on get positioner returning element. This way someone could
override the getter and return something else if it suited their needs.
—peter
On 9/26/17, 9:25 AM, "Harbs" wrote:
>I looked at MDL and I don’t see any problem there.
>
>I’m talking about simplifying things across the board
I looked at MDL and I don’t see any problem there.
I’m talking about simplifying things across the board. I don’t see how it could
effect anything.
@Peter I think removing positioner might not be a bad idea, but keeping it and
using it as a pointer to element is basically just as cheap.
> On S
I should also have addressed "cloneNode". I keep operating in the twilight
world between SWF and HTML/JS. The main guiding principle is to make it
work for HTML/JS as simply as possible and then replicate it for SWF. I
think since the Flash announcement, this should really be the defining
principle
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 f
Hi Harbs,
If you will do such changes like moving to set flexjs_wrapper in the setter
of element - please make it on the separate branch. Let me test with my app
whether MDL will not breaking up. I hope that we could avoid this one, even
if I think that it seems to be quite reasonable to do that.
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 ele
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 litt
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
elemen
22 matches
Mail list logo
