Re: Streaming video to FMS?

[Nicholas Kwiatkowski]

Unfortunately, they don't expose the APIs to be able to fake the camera
input, so there really isn't any way to do it.  There are drivers that
exist at the OS level that allow you to do this (TechSmith used to make
one, but it wasn't updated to W10 and later OSX versions) -- and they
essentially allows the OS to emulate a camera which allowed FP/AIR to think
it was talking to to a cam, but rather the input was coming from a file or
a screen sharing app.



On Tue, Sep 26, 2017 at 5:22 PM, David Frank  wrote:

> Thank you, Nick and Peter. Yeah, the FFMPEG option was my backup in case
> this didn't work.
>
> So, if we could fake the mp4 stream to appear like a camera stream then
> this should work wouldn't it? I tried exploring the NetStream instance but
> there doesn't seem to be anything obvious enough to do this. Any way of
> doing this in Air?
>
> Thank you,
> David
>
>
> -Original Message-
> From: Peter Ginneberge [mailto:p.ginnebe...@gmail.com]
> Sent: Monday, September 25, 2017 3:28 PM
> To: dev@flex.apache.org
> Subject: Re: Streaming video to FMS?
>
>
> One way to do it would be via FFMpeg.
>
> You can run FFMpeg via a NativeProcess from AIR. However, the air
> application then needs to be compiled as a native application (exe, dmg).
>
> http://help.adobe.com/en_US/air/html/dev/WSb2ba3b1aad8a27b060d22f991220
> f00ad8a-8000.html
>
> regards,
> Peter
>
> On 25/09/2017 23:25, Nicholas Kwiatkowski wrote:
> > David,
> >
> > Unfortunately, Adobe's FMS (now Adobe Media Server) does not support
> > sending content from Flex/AIR/JS, unless it is from a camera input.
> > No idea why they didn't implement it, but you have to use their
> > proprietary client to do the streaming.
> >
> > Wowza allows you to stream MP4 files via an HTTP Post, which you can
> > do with AIR/Flex.  The only gotcha I would note is the file size that
> > you want to stream -- anything over 2GB will start to cap out the
> > memory in the AIR client and won't produce favorable results.
> >
> > -Nick
> >
> > On Thu, Sep 21, 2017 at 3:49 PM, David Frank 
> wrote:
> >
> >> Hi there Flex experts!
> >>
> >> Does Apache AIR SDK have support for streaming a video file (mp4) to
> >> a media server (FMS/Wowza)? I know how to stream a camera feed to a
> >> media server. But what I need is to be able to stream a local mp4
> >> file to a media server. This mp4 file will then get re-streamed to
> >> other peers from the media server.
> >>
> >> Is this possible using the NetStream/NetConnection/Other classes? If
> >> it isn't directly possible to do this, then is there a way I can
> >> simulate the video as a camera feed and then attach this to the
> NetStream instance?
> >>
> >> Thank you,
> >> David Frank
> >>
> >>
> >>
> >
>

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Harbs]

That’s probably it.

It really needs bracket access.

Alex, if you are looking for a task in the compiler, here’s a suggestion that 
would drastically reduce bugs in minified apps:

1. For all untyped objects, dot notation should be rewritten to bracket 
notation:

var myObj:Object = myArr[idx];
doSomthing(myObj.foobaz);

Should probably become:

var myObj:Object = myArr[idx];
doSomthing(myObj[“foobaz”]);

2. Object literals should not be minified:

var foo:Object = {
name:”foo”,
age:15,
vegetable:true
}

Should be rewritten to:
var foo:Object = {
“name":”foo”,
“age":15,
“vegetable":true
}

I have been doing a LOT of manual fixing of these kinds of errors. It’s really 
tedious and hard to find all of them. Basically, unless you’re really good an 
find/replace, your app is almost guaranteed to blow up on some of these and 
then you need to find the needle in the haystack to fix it.

Harbs

> On Sep 27, 2017, at 12:33 AM, Alex Harui  wrote:
> 
> You can grab the JSON files from the Jenkins server, but the Ant build
> should also build them.
> 
> My guess is that the code isn't finding properties from the JSON objects
> because GCC renamed the properties.
> 
> -Alex
> 
> On 9/26/17, 2:25 PM, "Harbs"  wrote:
> 
>> I can’t test because I’m missing the json files and I’m not sure how to
>> generate them.
>> 
>> Looks like some binding problem probably due to renaming. The json files
>> appear to be loading correctly from the web.
>> 
>>> On Sep 26, 2017, at 11:41 PM, Alex Harui 
>>> wrote:
>>> 
>>> Feel free to take a investigate.  Peter's old ASDoc page points to the
>>> js-debug version.  It loads slowly some times, but at least it is
>>> functional.  I'd rather work on other things right now than chasing
>>> down a
>>> js-release problem.
>>> 
>>> -Alex
>>> 
>>> On 9/26/17, 1:36 PM, "Harbs"  wrote:
>>> 
 FWIW, the debug version is working, but the release version does not
 appear to work:
 
 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefl
 ex
 
 build.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSuccessfulB
 ui
 
 ld%2Fartifact%2Fexamples%2Fflexjs%2FASDoc%2Fbin%2Fjs-release%2Findex.htm
 l&
 
 data=02%7C01%7C%7C54179a88620d4b09851a08d5051e4e2b%7Cfa7b1b5a7b34438794a
 ed
 
 2c178decee1%7C0%7C0%7C636420550126149199=%2BTvYxjGSPD%2FJidjhxawDs
 cN
 4YnE1vPWE%2BarU5wgrolk%3D=0
 
 
 
> On Sep 26, 2017, at 11:02 PM, Alex Harui 
> wrote:
> 
> Or are you saying ASDoc isn't working for you on some browser?
 
>>> 
>> 
> 

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Alex Harui]

You can grab the JSON files from the Jenkins server, but the Ant build
should also build them.

My guess is that the code isn't finding properties from the JSON objects
because GCC renamed the properties.

-Alex

On 9/26/17, 2:25 PM, "Harbs"  wrote:

>I can’t test because I’m missing the json files and I’m not sure how to
>generate them.
>
>Looks like some binding problem probably due to renaming. The json files
>appear to be loading correctly from the web.
>
>> On Sep 26, 2017, at 11:41 PM, Alex Harui 
>>wrote:
>> 
>> Feel free to take a investigate.  Peter's old ASDoc page points to the
>> js-debug version.  It loads slowly some times, but at least it is
>> functional.  I'd rather work on other things right now than chasing
>>down a
>> js-release problem.
>> 
>> -Alex
>> 
>> On 9/26/17, 1:36 PM, "Harbs"  wrote:
>> 
>>> FWIW, the debug version is working, but the release version does not
>>> appear to work:
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefl
>>>ex
>>> 
>>>build.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSuccessfulB
>>>ui
>>> 
>>>ld%2Fartifact%2Fexamples%2Fflexjs%2FASDoc%2Fbin%2Fjs-release%2Findex.htm
>>>l&
>>> 
>>>data=02%7C01%7C%7C54179a88620d4b09851a08d5051e4e2b%7Cfa7b1b5a7b34438794a
>>>ed
>>> 
>>>2c178decee1%7C0%7C0%7C636420550126149199=%2BTvYxjGSPD%2FJidjhxawDs
>>>cN
>>> 4YnE1vPWE%2BarU5wgrolk%3D=0
>>> 
>>>>>le
>>> 
>>>xbuild.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSuccessful
>>>Bu
>>> 
>>>ild%2Fartifact%2Fexamples%2Fflexjs%2FASDoc%2Fbin%2Fjs-release%2Findex.ht
>>>ml
>>> 
>>>=02%7C01%7C%7C54179a88620d4b09851a08d5051e4e2b%7Cfa7b1b5a7b34438794
>>>ae
>>> 
>>>d2c178decee1%7C0%7C0%7C636420550126149199=%2BTvYxjGSPD%2FJidjhxawD
>>>sc
>>> N4YnE1vPWE%2BarU5wgrolk%3D=0>
>>> 
 On Sep 26, 2017, at 11:02 PM, Alex Harui 
 wrote:
 
 Or are you saying ASDoc isn't working for you on some browser?
>>> 
>> 
>

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Harbs]

I can’t test because I’m missing the json files and I’m not sure how to 
generate them.

Looks like some binding problem probably due to renaming. The json files appear 
to be loading correctly from the web.

> On Sep 26, 2017, at 11:41 PM, Alex Harui  wrote:
> 
> Feel free to take a investigate.  Peter's old ASDoc page points to the
> js-debug version.  It loads slowly some times, but at least it is
> functional.  I'd rather work on other things right now than chasing down a
> js-release problem.
> 
> -Alex
> 
> On 9/26/17, 1:36 PM, "Harbs"  wrote:
> 
>> FWIW, the debug version is working, but the release version does not
>> appear to work:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheflex
>> build.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSuccessfulBui
>> ld%2Fartifact%2Fexamples%2Fflexjs%2FASDoc%2Fbin%2Fjs-release%2Findex.html&
>> data=02%7C01%7C%7C54179a88620d4b09851a08d5051e4e2b%7Cfa7b1b5a7b34438794aed
>> 2c178decee1%7C0%7C0%7C636420550126149199=%2BTvYxjGSPD%2FJidjhxawDscN
>> 4YnE1vPWE%2BarU5wgrolk%3D=0
>> > xbuild.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSuccessfulBu
>> ild%2Fartifact%2Fexamples%2Fflexjs%2FASDoc%2Fbin%2Fjs-release%2Findex.html
>> =02%7C01%7C%7C54179a88620d4b09851a08d5051e4e2b%7Cfa7b1b5a7b34438794ae
>> d2c178decee1%7C0%7C0%7C636420550126149199=%2BTvYxjGSPD%2FJidjhxawDsc
>> N4YnE1vPWE%2BarU5wgrolk%3D=0>
>> 
>>> On Sep 26, 2017, at 11:02 PM, Alex Harui 
>>> wrote:
>>> 
>>> Or are you saying ASDoc isn't working for you on some browser?
>> 
> 

RE: Streaming video to FMS?

[David Frank]

Thank you, Nick and Peter. Yeah, the FFMPEG option was my backup in case this 
didn't work.

So, if we could fake the mp4 stream to appear like a camera stream then this 
should work wouldn't it? I tried exploring the NetStream instance but there 
doesn't seem to be anything obvious enough to do this. Any way of doing this in 
Air?

Thank you,
David


-Original Message-
From: Peter Ginneberge [mailto:p.ginnebe...@gmail.com] 
Sent: Monday, September 25, 2017 3:28 PM
To: dev@flex.apache.org
Subject: Re: Streaming video to FMS?


One way to do it would be via FFMpeg.

You can run FFMpeg via a NativeProcess from AIR. However, the air application 
then needs to be compiled as a native application (exe, dmg).

http://help.adobe.com/en_US/air/html/dev/WSb2ba3b1aad8a27b060d22f991220f00ad8a-8000.html

regards,
Peter

On 25/09/2017 23:25, Nicholas Kwiatkowski wrote:
> David,
> 
> Unfortunately, Adobe's FMS (now Adobe Media Server) does not support 
> sending content from Flex/AIR/JS, unless it is from a camera input.  
> No idea why they didn't implement it, but you have to use their 
> proprietary client to do the streaming.
> 
> Wowza allows you to stream MP4 files via an HTTP Post, which you can 
> do with AIR/Flex.  The only gotcha I would note is the file size that 
> you want to stream -- anything over 2GB will start to cap out the 
> memory in the AIR client and won't produce favorable results.
> 
> -Nick
> 
> On Thu, Sep 21, 2017 at 3:49 PM, David Frank  wrote:
> 
>> Hi there Flex experts!
>>
>> Does Apache AIR SDK have support for streaming a video file (mp4) to 
>> a media server (FMS/Wowza)? I know how to stream a camera feed to a 
>> media server. But what I need is to be able to stream a local mp4 
>> file to a media server. This mp4 file will then get re-streamed to 
>> other peers from the media server.
>>
>> Is this possible using the NetStream/NetConnection/Other classes? If 
>> it isn't directly possible to do this, then is there a way I can 
>> simulate the video as a camera feed and then attach this to the NetStream 
>> instance?
>>
>> Thank you,
>> David Frank
>>
>>
>>
> 

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Alex Harui]

Feel free to take a investigate.  Peter's old ASDoc page points to the
js-debug version.  It loads slowly some times, but at least it is
functional.  I'd rather work on other things right now than chasing down a
js-release problem.

-Alex

On 9/26/17, 1:36 PM, "Harbs"  wrote:

>FWIW, the debug version is working, but the release version does not
>appear to work:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheflex
>build.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSuccessfulBui
>ld%2Fartifact%2Fexamples%2Fflexjs%2FASDoc%2Fbin%2Fjs-release%2Findex.html&
>data=02%7C01%7C%7C54179a88620d4b09851a08d5051e4e2b%7Cfa7b1b5a7b34438794aed
>2c178decee1%7C0%7C0%7C636420550126149199=%2BTvYxjGSPD%2FJidjhxawDscN
>4YnE1vPWE%2BarU5wgrolk%3D=0
>xbuild.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSuccessfulBu
>ild%2Fartifact%2Fexamples%2Fflexjs%2FASDoc%2Fbin%2Fjs-release%2Findex.html
>=02%7C01%7C%7C54179a88620d4b09851a08d5051e4e2b%7Cfa7b1b5a7b34438794ae
>d2c178decee1%7C0%7C0%7C636420550126149199=%2BTvYxjGSPD%2FJidjhxawDsc
>N4YnE1vPWE%2BarU5wgrolk%3D=0>
>
>> On Sep 26, 2017, at 11:02 PM, Alex Harui 
>>wrote:
>> 
>> Or are you saying ASDoc isn't working for you on some browser?
>

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Harbs]

FWIW, the debug version is working, but the release version does not appear to 
work:
http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSuccessfulBuild/artifact/examples/flexjs/ASDoc/bin/js-release/index.html
 


> On Sep 26, 2017, at 11:02 PM, Alex Harui  wrote:
> 
> Or are you saying ASDoc isn't working for you on some browser?

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Alex Harui]

If I understand the problem (which I'm not sure, since the fix you posted
runs code if not Safari), you could create a
OneFlexibleChildLayoutWithSafariXSupport and put your fixes with browser
sniffing in there.  That way folks who don't need it, don't pay for the
sniffing.  There might be a version of Safari some day that behaves like
the other browsers.

My 2 cents,
-Alex

On 9/26/17, 1:25 PM, "Harbs"  wrote:

>I’m showing how to fix the “non-ForOverflow” layouts.
>
>The problem is that Safari handles flex layouts differently than other
>browsers.
>
>I’d like to use the flexbox layouts and AFAICT, they need browser
>sniffing to work across the board. Ideally, the browser sniffing should
>be included in the layout itself, but I was not sure the best way to do
>that…
>
>> On Sep 26, 2017, at 11:02 PM, Alex Harui 
>>wrote:
>> 
>> I'm not sure if you have the exact same problem as ASDoc, but the ASDoc
>> example is working fine with the "ForOverflow" layouts and no extra code
>> in the app.  Or are you saying ASDoc isn't working for you on some
>>browser?
>> 
>> IMO, that's the whole point of having many different flavors of layouts.
>> Folks can try different ones until they find one that works.  No need to
>> add custom code 3 places in the app.  Fixes for quirks get encapsulated
>> into a PAYG variant of a base component.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 9/26/17, 12:56 PM, "Harbs"  wrote:
>> 
>>> I ran into the Safari problem in my app.
>>> 
>>> I needed to add code like this:
>>> 
>>> var info:BrowserInfo = BrowserInfo.current();
>>> if(info.browser != "Safari" && info.formFactor.indexOf("iP") == -1){
>>> outerContainer.percentHeight = 100;
>>> leftResizeThumb.percentHeight = 100;
>>> }
>>> 
>>> The components look something like this:
>>> 
>>> >> id="dockAndOuterContainer"
>>> height="0%" style="align-items:stretch">
>>> 
>>> >>flexibleChild="outerContainer"/>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> >> 
>>> Basically, all browsers except Safari and iOS browsers need to be set
>>>to
>>> 100%. Safari and iOS browsers CANNOT be set to 100%.
>>> 
>>> I’m not sure how to generalize this code…
>>> 
>>> I have it in three places in my app to make it behave correctly.
>>> 
>>> I’ve been meaning to bring up this issue on the dev@ list. Sorry I
>>>didn’t
>>> do it sooner… ;-)
>>> 
>>> Harbs
>>> 
 On Sep 26, 2017, at 10:44 PM, Alex Harui 
 wrote:
 
 I just reverted ASDoc back to the "ForOverflow" layouts.  ASDoc was
not
 showing up correctly for me (Safari).  Maybe flex-basis is handled
 differently on different browsers.  We can look into it more later.
 
 Looking into this did make me glad we are changing over to "Royale" so
 "Flex" and "FlexJS" will not be confused with FlexBox and the flex-xxx
 attributes.
 
 -Alex
 
 On 7/31/17, 12:57 AM, "Harbs"  wrote:
 
> The only example I found was the ASDoc app.
> 
> I switched it and it appears to work. (I pushed my changes.)
> 
>> On Jul 31, 2017, at 7:35 AM, Alex Harui 
>> wrote:
>> 
>> It will either work in the examples that use it or it won't.  Try it
>> and
>> find out.
>> 
>> -Alex
>> 
>> On 7/30/17, 3:04 AM, "Harbs"  wrote:
>> 
>>> I think I just ran into the same issue.
>>> 
>>> This layout seems to more-or-less do the job, but it’s kind of
>>>heavy.
>>> 
>>> I did some research into flexbox and it appear that setting
>>> flex-basis
>>> to
>>> 0 does the job. It needs to be set on ONLY the one flexible child.
>>> 
>>> Here’s a codepen which shows a use case.
>>> 
>>> 
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcod
>>>ep
>>> en
>>> .i
>>> 
>>> 
>>> 
>>>o%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae0
>>>8d
>>> 4d
>>> 73
>>> 
>>> 
>>> 
>>>2638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63637005881876651
>>>1&
>>> sd
>>> at
>>> a=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0
>>> 
>>> 
>>> 
>>>>>de
>>> pe
>>> n.
>>> 
>>> 
>>> 
>>>io%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae
>>>08
>>> d4
>>> d7
>>> 
>>> 
>>> 
>>>32638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363700588187665
>>>11
>>> 
>>> da
>>> ta=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0>
>>> 
>>> I noticed that the OneFlexibleLayouts have code which set the
>>> flex-basis

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Harbs]

I’m showing how to fix the “non-ForOverflow” layouts.

The problem is that Safari handles flex layouts differently than other browsers.

I’d like to use the flexbox layouts and AFAICT, they need browser sniffing to 
work across the board. Ideally, the browser sniffing should be included in the 
layout itself, but I was not sure the best way to do that…

> On Sep 26, 2017, at 11:02 PM, Alex Harui  wrote:
> 
> I'm not sure if you have the exact same problem as ASDoc, but the ASDoc
> example is working fine with the "ForOverflow" layouts and no extra code
> in the app.  Or are you saying ASDoc isn't working for you on some browser?
> 
> IMO, that's the whole point of having many different flavors of layouts.
> Folks can try different ones until they find one that works.  No need to
> add custom code 3 places in the app.  Fixes for quirks get encapsulated
> into a PAYG variant of a base component.
> 
> My 2 cents,
> -Alex
> 
> On 9/26/17, 12:56 PM, "Harbs"  wrote:
> 
>> I ran into the Safari problem in my app.
>> 
>> I needed to add code like this:
>> 
>> var info:BrowserInfo = BrowserInfo.current();
>> if(info.browser != "Safari" && info.formFactor.indexOf("iP") == -1){
>>  outerContainer.percentHeight = 100;
>>  leftResizeThumb.percentHeight = 100;
>> }
>> 
>> The components look something like this:
>> 
>>  > id="dockAndOuterContainer"
>> height="0%" style="align-items:stretch">
>>  
>>  > flexibleChild="outerContainer"/>
>>  
>>  
>>  
>>  
>>  
>>  > 
>> Basically, all browsers except Safari and iOS browsers need to be set to
>> 100%. Safari and iOS browsers CANNOT be set to 100%.
>> 
>> I’m not sure how to generalize this code…
>> 
>> I have it in three places in my app to make it behave correctly.
>> 
>> I’ve been meaning to bring up this issue on the dev@ list. Sorry I didn’t
>> do it sooner… ;-)
>> 
>> Harbs
>> 
>>> On Sep 26, 2017, at 10:44 PM, Alex Harui 
>>> wrote:
>>> 
>>> I just reverted ASDoc back to the "ForOverflow" layouts.  ASDoc was not
>>> showing up correctly for me (Safari).  Maybe flex-basis is handled
>>> differently on different browsers.  We can look into it more later.
>>> 
>>> Looking into this did make me glad we are changing over to "Royale" so
>>> "Flex" and "FlexJS" will not be confused with FlexBox and the flex-xxx
>>> attributes.
>>> 
>>> -Alex
>>> 
>>> On 7/31/17, 12:57 AM, "Harbs"  wrote:
>>> 
 The only example I found was the ASDoc app.
 
 I switched it and it appears to work. (I pushed my changes.)
 
> On Jul 31, 2017, at 7:35 AM, Alex Harui 
> wrote:
> 
> It will either work in the examples that use it or it won't.  Try it
> and
> find out.
> 
> -Alex
> 
> On 7/30/17, 3:04 AM, "Harbs"  wrote:
> 
>> I think I just ran into the same issue.
>> 
>> This layout seems to more-or-less do the job, but it’s kind of heavy.
>> 
>> I did some research into flexbox and it appear that setting
>> flex-basis
>> to
>> 0 does the job. It needs to be set on ONLY the one flexible child.
>> 
>> Here’s a codepen which shows a use case.
>> 
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodep
>> en
>> .i
>> 
>> 
>> o%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae08d
>> 4d
>> 73
>> 
>> 
>> 2638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636370058818766511&
>> sd
>> at
>> a=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0
>> 
>> 
>> > pe
>> n.
>> 
>> 
>> io%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae08
>> d4
>> d7
>> 
>> 
>> 32638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636370058818766511
>> 
>> da
>> ta=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0>
>> 
>> I noticed that the OneFlexibleLayouts have code which set the
>> flex-basis
>> of the children if a percentage value is set. When setting the size
>> of
>> the one flexible child to 0% this causes the flex-basis to be set to
>> 0
>> and then the one flexible child will fit the remaining space even if
>> it
>> might overflow because of its children.
>> 
>> I have wasted quite a bit of time before I discovered this. I’m not
>> sure
>> whether the OneFlexibleLayout classes should be changed, or maybe we
>> need
>> documentation that to fit content that might overflow, the percentage
>> should be set to 0. It could be there are cases where the entire
>> OnFlexibleLayout should be fit when 

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Alex Harui]

I'm not sure if you have the exact same problem as ASDoc, but the ASDoc
example is working fine with the "ForOverflow" layouts and no extra code
in the app.  Or are you saying ASDoc isn't working for you on some browser?

IMO, that's the whole point of having many different flavors of layouts.
Folks can try different ones until they find one that works.  No need to
add custom code 3 places in the app.  Fixes for quirks get encapsulated
into a PAYG variant of a base component.

My 2 cents,
-Alex

On 9/26/17, 12:56 PM, "Harbs"  wrote:

>I ran into the Safari problem in my app.
>
>I needed to add code like this:
>
>var info:BrowserInfo = BrowserInfo.current();
>if(info.browser != "Safari" && info.formFactor.indexOf("iP") == -1){
>   outerContainer.percentHeight = 100;
>   leftResizeThumb.percentHeight = 100;
>}
>
>The components look something like this:
>
>id="dockAndOuterContainer"
>height="0%" style="align-items:stretch">
>   
>flexibleChild="outerContainer"/>
>   
>   
>   
>   
>   
>   
>Basically, all browsers except Safari and iOS browsers need to be set to
>100%. Safari and iOS browsers CANNOT be set to 100%.
>
>I’m not sure how to generalize this code…
>
>I have it in three places in my app to make it behave correctly.
>
>I’ve been meaning to bring up this issue on the dev@ list. Sorry I didn’t
>do it sooner… ;-)
>
>Harbs
>
>> On Sep 26, 2017, at 10:44 PM, Alex Harui 
>>wrote:
>> 
>> I just reverted ASDoc back to the "ForOverflow" layouts.  ASDoc was not
>> showing up correctly for me (Safari).  Maybe flex-basis is handled
>> differently on different browsers.  We can look into it more later.
>> 
>> Looking into this did make me glad we are changing over to "Royale" so
>> "Flex" and "FlexJS" will not be confused with FlexBox and the flex-xxx
>> attributes.
>> 
>> -Alex
>> 
>> On 7/31/17, 12:57 AM, "Harbs"  wrote:
>> 
>>> The only example I found was the ASDoc app.
>>> 
>>> I switched it and it appears to work. (I pushed my changes.)
>>> 
 On Jul 31, 2017, at 7:35 AM, Alex Harui 
 wrote:
 
 It will either work in the examples that use it or it won't.  Try it
and
 find out.
 
 -Alex
 
 On 7/30/17, 3:04 AM, "Harbs"  wrote:
 
> I think I just ran into the same issue.
> 
> This layout seems to more-or-less do the job, but it’s kind of heavy.
> 
> I did some research into flexbox and it appear that setting
>flex-basis
> to
> 0 does the job. It needs to be set on ONLY the one flexible child.
> 
> Here’s a codepen which shows a use case.
> 
> 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodep
>en
> .i
> 
> 
>o%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae08d
>4d
> 73
> 
> 
>2638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636370058818766511&
>sd
> at
> a=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0
> 
> 
>pe
> n.
> 
> 
>io%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae08
>d4
> d7
> 
> 
>32638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636370058818766511
>
> da
> ta=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0>
> 
> I noticed that the OneFlexibleLayouts have code which set the
> flex-basis
> of the children if a percentage value is set. When setting the size
>of
> the one flexible child to 0% this causes the flex-basis to be set to
>0
> and then the one flexible child will fit the remaining space even if
>it
> might overflow because of its children.
> 
> I have wasted quite a bit of time before I discovered this. I’m not
> sure
> whether the OneFlexibleLayout classes should be changed, or maybe we
> need
> documentation that to fit content that might overflow, the percentage
> should be set to 0. It could be there are cases where the entire
> OnFlexibleLayout should be fit when smaller and expand (and not
>scroll)
> when bigger. In that case, the current behavior might be correct.
> 
> Thoughts?
> Harbs
> 
>> On May 23, 2017, at 10:16 AM, aha...@apache.org wrote:
>> 
>> give up on trying to use FlexBox for full-screen 3-pane views.
>> FlexBox
>> seems more happy stretching to content size instead of clipping at
>>the
>> computed flex-ed size.  These custom layouts will do the proper
>>sizing
>> 
>> 
>> Project: 
>> 
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-w
>>ip
>> -u

Re: [07/13] git commit: [flex-asjs] [refs/heads/release0.8.0] - give up on trying to use FlexBox for full-screen 3-pane views. FlexBox seems more happy stretching to content size instead of clipping a

[Harbs]

I ran into the Safari problem in my app.

I needed to add code like this:

var info:BrowserInfo = BrowserInfo.current();
if(info.browser != "Safari" && info.formFactor.indexOf("iP") == -1){
outerContainer.percentHeight = 100;
leftResizeThumb.percentHeight = 100;
}

The components look something like this:









 On Sep 26, 2017, at 10:44 PM, Alex Harui  wrote:
> 
> I just reverted ASDoc back to the "ForOverflow" layouts.  ASDoc was not
> showing up correctly for me (Safari).  Maybe flex-basis is handled
> differently on different browsers.  We can look into it more later.
> 
> Looking into this did make me glad we are changing over to "Royale" so
> "Flex" and "FlexJS" will not be confused with FlexBox and the flex-xxx
> attributes.
> 
> -Alex
> 
> On 7/31/17, 12:57 AM, "Harbs"  wrote:
> 
>> The only example I found was the ASDoc app.
>> 
>> I switched it and it appears to work. (I pushed my changes.)
>> 
>>> On Jul 31, 2017, at 7:35 AM, Alex Harui 
>>> wrote:
>>> 
>>> It will either work in the examples that use it or it won't.  Try it and
>>> find out.
>>> 
>>> -Alex
>>> 
>>> On 7/30/17, 3:04 AM, "Harbs"  wrote:
>>> 
 I think I just ran into the same issue.
 
 This layout seems to more-or-less do the job, but it’s kind of heavy.
 
 I did some research into flexbox and it appear that setting flex-basis
 to
 0 does the job. It needs to be set on ONLY the one flexible child.
 
 Here’s a codepen which shows a use case.
 
 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodepen
 .i
 
 o%2Fjpdevries%2Fpen%2FoXxPOP=02%7C01%7C%7C699bbb170b2c4f0bf3ae08d4d
 73
 
 2638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636370058818766511
 at
 a=tSTNYANFFiQ4DMGYbAZaz0dJ9qYDYpcwP2ZoSYRIcG8%3D=0
 
 
 
 I noticed that the OneFlexibleLayouts have code which set the
 flex-basis
 of the children if a percentage value is set. When setting the size of
 the one flexible child to 0% this causes the flex-basis to be set to 0
 and then the one flexible child will fit the remaining space even if it
 might overflow because of its children.
 
 I have wasted quite a bit of time before I discovered this. I’m not
 sure
 whether the OneFlexibleLayout classes should be changed, or maybe we
 need
 documentation that to fit content that might overflow, the percentage
 should be set to 0. It could be there are cases where the entire
 OnFlexibleLayout should be fit when smaller and expand (and not scroll)
 when bigger. In that case, the current behavior might be correct.
 
 Thoughts?
 Harbs
 
> On May 23, 2017, at 10:16 AM, aha...@apache.org wrote:
> 
> give up on trying to use FlexBox for full-screen 3-pane views.
> FlexBox
> seems more happy stretching to content size instead of clipping at the
> computed flex-ed size.  These custom layouts will do the proper sizing
> 
> 
> Project: 
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip
> -u
> 
> s.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Frepo=02%7C01%7C%7C699bbb1
> 70
> 
> b2c4f0bf3ae08d4d732638a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63
> 63
> 
> 70058818766511=P%2FMkfZAwCYwpQEoCe5UGx8tW0mZaIZsMdDg6VxlaKWA%3D
> es
> erved=0
> Commit: 
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip
> -u
> 
> s.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Fcommit%2Fbdd34d2e=02%7C01
> %7
> 
> C%7C699bbb170b2c4f0bf3ae08d4d732638a%7Cfa7b1b5a7b34438794aed2c178decee1
> %7
> 
> C0%7C0%7C636370058818766511=QosBAau8lE4nCS7c%2F8B6GDc%2Bqa%2BpSko
> P5
> 5x3oji5FnI%3D=0
> Tree: 
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip
> -u
> 
> s.apache.org%2Frepos%2Fasf%2Fflex-asjs%2Ftree%2Fbdd34d2e=02%7C01%7
> C%
> 
> 7C699bbb170b2c4f0bf3ae08d4d732638a%7Cfa7b1b5a7b34438794aed2c178decee1%7
> C0
> 
> %7C0%7C636370058818766511=T4CCqwtn%2FgFTmAnaI%2BuCXqtX0P75ebpKVZO
> xf
> XOTbIE%3D=0
> Diff: 
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit-wip
> -u
> 
> 

Re: [DISCUSS} Fork FlexJS from Apache Flex

[Alex Harui]

I just fixed the SWF version.  Working on the JS version now.

-Alex

On 9/26/17, 6:55 AM, "yishayw"  wrote:

>The address is ok but tags.json isn't found...
>
>
>
>
>
>--
>Sent from: 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2F=02%7C01%7C%7C3d7199659a8e42626
>c5508d504e63dad%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364203092854
>80637=w8lzMqte0%2Bz1fUNI9ZRx0qCnxZSHljVekabpRnuKwmg%3D=0

Re: [Discuss] Pros and Cons of Using Royale to Build Websites

[Alex Harui]

Harbs has to request the repos and mailing lists, and then Infra will
hookup GitPubSub and we'll be able to set up royale.apache.org.  And when
we do, I suggest that we stick in some static pages just for now.  I can
do it, but will look ugly if I do, so best if someone else can do it.

But over time, IMO, we want to replace our static pages with dynamic pages
and eventually a dynamic single-page "app".  Our website is going to be
designed to attract, inform and retain visitors, and I think it is well
established that proper use of dynamic behavior can help achieve those
goals better than a pile of static pages.

I think of the difference between a static landing page where the visitor
has to scan it looking for information, and a dynamic page that greets you
with "How can I help you today?".  I think we'd love it if we had a chat
center open 24/7 for Royale "evangelism and support".  Why can't we build
out such a thing on the web?  But instead of actual humans answering the
visitor, intelligent code is answering instead.  If you want to learn a
new technology, do you want to read a book about it, or interact with a
friendly expert?

We do have to solve how Search Engines will find us, although I'm not sure
I care about any other search engine other than Google.  The nice thing is
that SEO for dynamic apps have been a problem for years.  This is not a
problem that we have to solve by ourselves, instead we can expect that
Google and a whole bunch of other folks are also working to solve it.  Our
part of the work may be as "simple" as making sure our screens render fast
enough.

The cool thing about Royale is that we have a compiler and that allows us
to change the output without requiring the developer to change the source
code.  We can add stuff to the HTML wrapper, generate site maps, generate
a search-friendly DOM and more.

The framework can also help.  If we have to run the JS in a fixed amount
of time, we can alter what JS runs if we know we are being loaded by a
headless search engine crawler.  For example, we could add code that
doesn't load mouse and keyboard beads.  We could even skip layout if that
makes a difference.

The important part is that Google recognizes that dynamic web content is
going to be a key part of the modern web and is dedicated to making it
searchable.

Articles like [1] that discuss the drawbacks of JS-based web sites are
interesting, but for me, I don't worry about them too much.  There is no
perfect, no-trade-off environment.  If your concern is performance, I'll
bet I can go find an article that says that native code will be faster
than the browser will ever be.  There are probably articles about how
content delivery via Browsers are not as good as providing Apps.
Progressive Enhancement can help, but only if the basic content is known
and can be enhanced.  I expect there will be plenty of folks who will
decide to use Browsers and a Framework and a structured language and
dynamic content for many years to come.  And another group interested in
Apps.  We just have to show them that we can be a valid choice, not
necessarily the perfect choice.  I think we can do that.

My 2 cents,
-Alex

On 9/25/17, 10:56 PM, "yishayw"  wrote:

>Olaf Krueger wrote
>> That said, I think you just need a couple of static HTML files to get it
>> work. 
>> No complex controls or complex logic needed.
>> For this use case I don't see the benefit of using Royale or other
>>complex
>> frameworks.
>
>To me it's easier to write in MXML than in HTML, especially if there are
>good layouts. If there are recurring sections or pages that can be
>abstracted to MXML tags that's an advantage too.
>
>
>>>I found this [1] an interesting read on the >subject
>> 
>> Mhhh  maybe I got it wrong but it seems to me that a couple of
>>points
>> could be also true for Royale(JS). (If you basically share the ideas
>>that
>> are provided within this article)
>
>I was using [1] to get an intro to the challenges one faces when using a
>client side framework to create a website. I'm interested to hear opinions
>on whether Royale can meet these challenges. SEO, for example, has been
>cited as a major disadvantage of using client side rendering. But reading
>[2] it looks like there are ways around that.
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lease
>web.com%2Flabs%2F2013%2F07%2F10-very-good-reasons-to-stop-using-javascript
>%2F=02%7C01%7C%7Cf436fdd3645546bc931f08d504a3506f%7Cfa7b1b5a7b3443879
>4aed2c178decee1%7C0%7C0%7C636420021841903617=CZICAWNFI09bOpvaArv%2B1
>JRN1Pr%2F2Kp5m2EEkxcIeyQ%3D=0
>[2] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoz.com%2
>Fblog%2Fjavascript-seo=02%7C01%7C%7Cf436fdd3645546bc931f08d504a3506f%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636420021841903617=zCf6
>XGSYguNycu3Hn5wAkLBNiSMnD6jh2TFN%2Br0AELI%3D=0
>[2]  
>
>
>
>--
>Sent from: 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle

Re: FlexJS element setter

[Piotr Zarzycki]

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:
> >
> > 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()?
> >>
> >> 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 WrappedHTMLElement;
> >>
> >> Do you think it’s safe to remove the check?
> >>
> >>> On Sep 26, 2017, at 6:42 PM, Alex Harui 
> >> wrote:
> >>>
> >>> 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 getter returning element, we have to
> >>> make sure our code that positions things uses positioner and not
> element
> >>> in case someone does try to override positioner some day.
> >>>
> >>> As Peter mentioned, the original thinking was that element would be the
> >>> HTMLElement that defines the node in the DOM that dispatches
> interaction
> >>> events, but positioner might be some parent of the element like a Div
> >> used
> >>> to give the element appropriate visuals, chrome, accessory widgets,
> etc,
> >>> like NumericStepper, ComboBox, DateField, and maybe more sophisticated
> >>> components like a RichTextEditor where the "element" is a Div that gets
> >>> focus and holds the text lines, but is a child of a positioner Div that
> >>> also contains child buttons for bold/italic/underline.  Another example
> >>> may be VideoPlayback.  The element might be some sort of video widget
> but
> >>> the positioner might be a div that also contains child buttons for
> >>> stop/pause/rewind/forward.
> >>>
> >>> Of course, I could be wrong...
> >>> -Alex
> >>>
> >>> On 9/26/17, 6:27 AM, "Peter Ent"  wrote:
> >>>
>  @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 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 Sep 26, 2017, at 4:12 PM, Piotr Zarzycki <
> >> piotrzarzyck...@gmail.com>
> >> wrote:
> >>
> >> 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.
> >>
> >> Can you for example do this only for your custom component not for
> the
> >> global IUIBase class ?
> >>
> >> Let see what Peter say.
> >>
> >> Thanks, Piotr
> >>
> >>
> >> 2017-09-26 15:02 GMT+02:00 Harbs :
> >>
> >>> 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, 

Re: FlexJS element setter

[Harbs]

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 17:54 GMT+02:00 Harbs :
> 
>> 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 WrappedHTMLElement;
>> 
>> Do you think it’s safe to remove the check?
>> 
>>> On Sep 26, 2017, at 6:42 PM, Alex Harui 
>> wrote:
>>> 
>>> 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 getter returning element, we have to
>>> make sure our code that positions things uses positioner and not element
>>> in case someone does try to override positioner some day.
>>> 
>>> As Peter mentioned, the original thinking was that element would be the
>>> HTMLElement that defines the node in the DOM that dispatches interaction
>>> events, but positioner might be some parent of the element like a Div
>> used
>>> to give the element appropriate visuals, chrome, accessory widgets, etc,
>>> like NumericStepper, ComboBox, DateField, and maybe more sophisticated
>>> components like a RichTextEditor where the "element" is a Div that gets
>>> focus and holds the text lines, but is a child of a positioner Div that
>>> also contains child buttons for bold/italic/underline.  Another example
>>> may be VideoPlayback.  The element might be some sort of video widget but
>>> the positioner might be a div that also contains child buttons for
>>> stop/pause/rewind/forward.
>>> 
>>> Of course, I could be wrong...
>>> -Alex
>>> 
>>> On 9/26/17, 6:27 AM, "Peter Ent"  wrote:
>>> 
 @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 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 Sep 26, 2017, at 4:12 PM, Piotr Zarzycki <
>> piotrzarzyck...@gmail.com>
>> wrote:
>> 
>> 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.
>> 
>> Can you for example do this only for your custom component not for the
>> global IUIBase class ?
>> 
>> Let see what Peter say.
>> 
>> Thanks, Piotr
>> 
>> 
>> 2017-09-26 15:02 GMT+02:00 Harbs :
>> 
>>> 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 
 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 

Re: FlexJS element setter

[Harbs]

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?  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 to support "new UIBase()"?
>> 
> 

Re: FlexJS element setter

[Alex Harui]

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 to support "new UIBase()"?
>

Re: FlexJS element setter

[Harbs]

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()"?

Re: FlexJS element setter

[Harbs]

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, 2017, at 8:41 PM, Alex Harui  wrote:
> 
> 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 want to allow "new UIBase()" and expect it to
> generate a child HTMLElement, then how do we want to instruct folks to
> write their createElement overrides?  A common override pattern is this:
> 
> public class MyClass extends UIBase {
> 
>  override protected function createElement(){
>element = document.createElement("input");
>super.createElement();
>  }
> }
> 
> Or this:
> 
> public class MyClass extends UIBase {
> 
>  override protected function createElement(){
>super.createElement();
>element = document.createElement("input");
>  }
> }
> 
> 
> Maybe the API is poorly designed. Maybe UIBase.createElement() should take
> a String and UIBase would call it with 'div' and subclasses can change the
> 'div' to something else before calling super.createElement.
> 
> Of course, I could be wrong...
> -Alex
> 
> 
> 
> On 9/26/17, 10:21 AM, "Harbs"  wrote:
> 
>> 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 PM, Alex Harui 
>>> wrote:
>>> 
>>> 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.
>>> 
>>> I don't have an opinion on what is "right".
>>> 
>>> -Alex
>>> 
>>> On 9/26/17, 8:54 AM, "Harbs"  wrote:
>>> 
 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 WrappedHTMLElement;
 
 Do you think it’s safe to remove the check?
 
> On Sep 26, 2017, at 6:42 PM, Alex Harui 
> wrote:
> 
> 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 getter returning element, we have to
> make sure our code that positions things uses positioner and not
> element
> in case someone does try to override positioner some day.
> 
> As Peter mentioned, the original thinking was that element would be
> the
> HTMLElement that defines the node in the DOM that dispatches
> interaction
> events, but positioner might be some parent of the element like a Div
> used
> to give the element appropriate visuals, chrome, accessory widgets,
> etc,
> like NumericStepper, ComboBox, DateField, and maybe more sophisticated
> components like a RichTextEditor where the "element" is a Div that
> gets
> focus and holds the text lines, but is a child of a positioner Div
> that
> also contains child buttons for bold/italic/underline.  Another
> example
> may be VideoPlayback.  The element might be some sort of video widget
> but
> the positioner might be a div that also contains child buttons for
> stop/pause/rewind/forward.
> 
> Of course, I could be wrong...
> -Alex
> 
> On 9/26/17, 6:27 AM, "Peter Ent"  wrote:
> 
>> @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 don’t see
>>> how it
>>> could effect anything.
>>> 
>>> @Peter I think removing positioner might not 

Re: FlexJS element setter

[Alex Harui]

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.

I don't have an opinion on what is "right".

-Alex

On 9/26/17, 8:54 AM, "Harbs"  wrote:

>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 WrappedHTMLElement;
>
>Do you think it’s safe to remove the check?
>
>> On Sep 26, 2017, at 6:42 PM, Alex Harui 
>>wrote:
>> 
>> 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 getter returning element, we have to
>> make sure our code that positions things uses positioner and not element
>> in case someone does try to override positioner some day.
>> 
>> As Peter mentioned, the original thinking was that element would be the
>> HTMLElement that defines the node in the DOM that dispatches interaction
>> events, but positioner might be some parent of the element like a Div
>>used
>> to give the element appropriate visuals, chrome, accessory widgets, etc,
>> like NumericStepper, ComboBox, DateField, and maybe more sophisticated
>> components like a RichTextEditor where the "element" is a Div that gets
>> focus and holds the text lines, but is a child of a positioner Div that
>> also contains child buttons for bold/italic/underline.  Another example
>> may be VideoPlayback.  The element might be some sort of video widget
>>but
>> the positioner might be a div that also contains child buttons for
>> stop/pause/rewind/forward.
>> 
>> Of course, I could be wrong...
>> -Alex
>> 
>> On 9/26/17, 6:27 AM, "Peter Ent"  wrote:
>> 
>>> @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 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 Sep 26, 2017, at 4:12 PM, Piotr Zarzycki
>
> wrote:
> 
> 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.
> 
> Can you for example do this only for your custom component not for
>the
> global IUIBase class ?
> 
> Let see what Peter say.
> 
> Thanks, Piotr
> 
> 
> 2017-09-26 15:02 GMT+02:00 Harbs :
> 
>> 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 
>>> 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?

Re: FlexJS element setter

[Harbs]

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-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()?
>> 
>> 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 WrappedHTMLElement;
>> 
>> Do you think it’s safe to remove the check?
>> 
>>> On Sep 26, 2017, at 6:42 PM, Alex Harui 
>> wrote:
>>> 
>>> 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 getter returning element, we have to
>>> make sure our code that positions things uses positioner and not element
>>> in case someone does try to override positioner some day.
>>> 
>>> As Peter mentioned, the original thinking was that element would be the
>>> HTMLElement that defines the node in the DOM that dispatches interaction
>>> events, but positioner might be some parent of the element like a Div
>> used
>>> to give the element appropriate visuals, chrome, accessory widgets, etc,
>>> like NumericStepper, ComboBox, DateField, and maybe more sophisticated
>>> components like a RichTextEditor where the "element" is a Div that gets
>>> focus and holds the text lines, but is a child of a positioner Div that
>>> also contains child buttons for bold/italic/underline.  Another example
>>> may be VideoPlayback.  The element might be some sort of video widget but
>>> the positioner might be a div that also contains child buttons for
>>> stop/pause/rewind/forward.
>>> 
>>> Of course, I could be wrong...
>>> -Alex
>>> 
>>> On 9/26/17, 6:27 AM, "Peter Ent"  wrote:
>>> 
 @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 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 Sep 26, 2017, at 4:12 PM, Piotr Zarzycki <
>> piotrzarzyck...@gmail.com>
>> wrote:
>> 
>> 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.
>> 
>> Can you for example do this only for your custom component not for the
>> global IUIBase class ?
>> 
>> Let see what Peter say.
>> 
>> Thanks, Piotr
>> 
>> 
>> 2017-09-26 15:02 GMT+02:00 Harbs :
>> 
>>> 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 
 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 

Re: FlexJS element setter

[Piotr Zarzycki]

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()?
>
> 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 WrappedHTMLElement;
>
> Do you think it’s safe to remove the check?
>
> > On Sep 26, 2017, at 6:42 PM, Alex Harui 
> wrote:
> >
> > 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 getter returning element, we have to
> > make sure our code that positions things uses positioner and not element
> > in case someone does try to override positioner some day.
> >
> > As Peter mentioned, the original thinking was that element would be the
> > HTMLElement that defines the node in the DOM that dispatches interaction
> > events, but positioner might be some parent of the element like a Div
> used
> > to give the element appropriate visuals, chrome, accessory widgets, etc,
> > like NumericStepper, ComboBox, DateField, and maybe more sophisticated
> > components like a RichTextEditor where the "element" is a Div that gets
> > focus and holds the text lines, but is a child of a positioner Div that
> > also contains child buttons for bold/italic/underline.  Another example
> > may be VideoPlayback.  The element might be some sort of video widget but
> > the positioner might be a div that also contains child buttons for
> > stop/pause/rewind/forward.
> >
> > Of course, I could be wrong...
> > -Alex
> >
> > On 9/26/17, 6:27 AM, "Peter Ent"  wrote:
> >
> >> @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 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 Sep 26, 2017, at 4:12 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
>  wrote:
> 
>  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.
> 
>  Can you for example do this only for your custom component not for the
>  global IUIBase class ?
> 
>  Let see what Peter say.
> 
>  Thanks, Piotr
> 
> 
>  2017-09-26 15:02 GMT+02:00 Harbs :
> 
> > 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 
> >> 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

Re: [DISCUSS} Fork FlexJS from Apache Flex

[yishayw]

The address is ok but tags.json isn't found...





--
Sent from: http://apache-flex-development.247.n4.nabble.com/

Re: FlexJS element setter

[Peter Ent]

@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 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 Sep 26, 2017, at 4:12 PM, Piotr Zarzycki 
>>wrote:
>> 
>> 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.
>> 
>> Can you for example do this only for your custom component not for the
>> global IUIBase class ?
>> 
>> Let see what Peter say.
>> 
>> Thanks, Piotr
>> 
>> 
>> 2017-09-26 15:02 GMT+02:00 Harbs :
>> 
>>> 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  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"  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
 
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> Piotr Zarzycki
>> 
>> mobile: +48 880 859 557
>> skype: zarzycki10
>> 
>> LinkedIn: 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linke
>>din.com%2Fpiotrzarzycki=02%7C01%7C%7C6716901213624a0e804708d504e2039
>>f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636420291136295544=f
>>Q1CjLGkCpNKxSQBmZn%2BnKZEplQpGl25XACOqq0gO2o%3D=0
>> 
>>>edin.com%2Fin%2Fpiotr-zarzycki-92a53552=02%7C01%7C%7C6716901213624a0
>>e804708d504e2039f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364202911
>>36295544=LzIej2n6WVnm9AG1Hi4NqIZjOQS%2Byo4w%2BPYTX0Rq8Gc%3D
>>d=0>
>> 
>> GitHub: 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fpiotrzarzycki21=02%7C01%7C%7C6716901213624a0e804708d504e2039f%7
>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636420291136295544=WeIl
>>LzVsJzRKniD1r9F2xb%2BwljhCLHnurBnl03kBM9E%3D=0
>

Re: FlexJS element setter

[Harbs]

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 Sep 26, 2017, at 4:12 PM, Piotr Zarzycki  wrote:
> 
> 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.
> 
> Can you for example do this only for your custom component not for the
> global IUIBase class ?
> 
> Let see what Peter say.
> 
> Thanks, Piotr
> 
> 
> 2017-09-26 15:02 GMT+02:00 Harbs :
> 
>> 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  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"  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
>>> 
>> 
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> mobile: +48 880 859 557
> skype: zarzycki10
> 
> LinkedIn: http://www.linkedin.com/piotrzarzycki
> 
> 
> GitHub: https://github.com/piotrzarzycki21

Re: FlexJS element setter

[Peter Ent]

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"  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  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"  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
>> 
>

Re: FlexJS element setter

[Piotr Zarzycki]

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.

Can you for example do this only for your custom component not for the
global IUIBase class ?

Let see what Peter say.

Thanks, Piotr


2017-09-26 15:02 GMT+02:00 Harbs :

> 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  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"  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
> >
>
>


-- 

Piotr Zarzycki

mobile: +48 880 859 557
skype: zarzycki10

LinkedIn: http://www.linkedin.com/piotrzarzycki


GitHub: https://github.com/piotrzarzycki21

Re: FlexJS element setter

[Harbs]

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  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"  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
> 

Re: FlexJS element setter

[Peter Ent]

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"  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

FlexJS element setter

[Harbs]

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

Re: [DISCUSS} Fork FlexJS from Apache Flex

[Lee29]

Thanks for your reply!
But there is a problem, I can not open the two links in:
http://people.apache.org/~pent/asdoc-flexjs/index.html
Are these docs moved to another new place, so it can not be opend now?
Or is it just my network problem?
If the address has been updated, please tell me where it is now.
Thanks very much.



--
Sent from: http://apache-flex-development.247.n4.nabble.com/

Re: [Discuss] Pros and Cons of Using Royale to Build Websites

[Carlos Rovira]

Hi,

when I tried to replicate an MDL web page example (from MDL official
samples). I found I was at maybe 90% to get the same results with our
Royale MDL library, the problems at that time was from CSS processed by
Royale that was not prepared for all uses cases. About the CSS problems,
most of them was complex CSS selectors that was not considerer by Royale
compiler.

There's an MDLBlogExample I committed at that time where you can see the
results. I think to get full HTML/CSS web site layouts mainly CSS bugs
should be removed. Don't know if in this months someone has fixed some of
the issues.



2017-09-26 7:56 GMT+02:00 yishayw :

> Olaf Krueger wrote
> > That said, I think you just need a couple of static HTML files to get it
> > work.
> > No complex controls or complex logic needed.
> > For this use case I don't see the benefit of using Royale or other
> complex
> > frameworks.
>
> To me it's easier to write in MXML than in HTML, especially if there are
> good layouts. If there are recurring sections or pages that can be
> abstracted to MXML tags that's an advantage too.
>
>
> >>I found this [1] an interesting read on the >subject
> >
> > Mhhh  maybe I got it wrong but it seems to me that a couple of points
> > could be also true for Royale(JS). (If you basically share the ideas that
> > are provided within this article)
>
> I was using [1] to get an intro to the challenges one faces when using a
> client side framework to create a website. I'm interested to hear opinions
> on whether Royale can meet these challenges. SEO, for example, has been
> cited as a major disadvantage of using client side rendering. But reading
> [2] it looks like there are ways around that.
>
> [1]
> https://www.leaseweb.com/labs/2013/07/10-very-good-reasons-
> to-stop-using-javascript/
> [2] https://moz.com/blog/javascript-seo
> [2]
>
>
>
> --
> Sent from: http://apache-flex-development.247.n4.nabble.com/
>



-- 



Carlos Rovira

Director General

M: +34 607 22 60 05

http://www.codeoscopic.com

http://www.avant2.es


Conocenos en 1 minuto! 


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [DISCUSS} Fork FlexJS from Apache Flex

[yishayw]

Yes and No. See this [1].

[1]
http://apache-flex-users.246.n4.nabble.com/How-To-Start-Converting-A-Browser-Project-to-FlexJS-td15946.html#a15950



--
Sent from: http://apache-flex-development.247.n4.nabble.com/