subject:"FlexJS"

Alex, your e-mail is hidden on this thread.

I'm using directly nabble website.

Anyway, this was my post (attempt to):

Following
http://apache-flex-development.247.n4.nabble.com/Question-on-Migrating-from-Flex-to-FlexJS-td65514.html
...

"we have some tooling to try to analyze your code"
Great. Can you please point me where this tools are and how to use them (I
suposed that's a command line) ?

A few questions:
1. Apache Roayle support FXG (visual elements and colors with XML) in the
same way as Flex SDK or there is plans to ?
2. Flex SDK on AIR have native support (without ANE) for SQLite. This is
very important for mobile applications and also for offline content on
desktop applications. Does Royale supports this ?
3. AIR supports native extensions that are important for mobile. How Apache
Roayle deals with that ?

Chears,
Hugo.



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

Re: Question on Migrating from Flex to FlexJS

Alex, your e-mail is hidden on this thread.

I'm using directly nabble website.

Anyway, this was my post (attempt to):

Following
http://apache-flex-development.247.n4.nabble.com/Question-on-Migrating-from-Flex-to-FlexJS-td65514.html
...

"we have some tooling to try to analyze your code"
Great. Can you please point me where this tools are and how to use them (I
suposed that's a command line) ?

A few questions:
1. Apache Roayle support FXG (visual elements and colors with XML) in the
same way as Flex SDK or there is plans to ?
2. Flex SDK on AIR have native support (without ANE) for SQLite. This is
very important for mobile applications and also for offline content on
desktop applications. Does Royale supports this ?
3. AIR supports native extensions that are important for mobile. How Apache
Roayle deals with that ?

Chears,
Hugo.



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

Re: Question on Migrating from Flex to FlexJS

Alex,

The e-mail links are hidden !
Anyway, I tried to subscribe again.

Meanwhile I tried to get the night build (I really, really want to see
MX/Spark emulation on action) but I got a page error !

"we have some tooling to try to analyze your code"
Great. Can you please point me where this tools are and how to use them (I
suposed that's a command line) ?

A few more questions:
1. Apache Roayle support FXG (visual elements and colors with XML) in the
same way as Flex SDK or there is plans to ?
2. Flex SDK on AIR have native support (without ANE) for SQLite. This is
very important for mobile applications and also for offline content on
desktop applications. Does Royale supports this ?
3. AIR supports native extensions that are important for mobile. How Apache
Roayle deals with that ?



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

Re: Question on Migrating from Flex to FlexJS

Alex,

Wall your e-mails shows as hidden for me.

I tryed again and got this message:
This message was sent from hferreira...@gmail.com to the
us...@royale.apache.org mailing list. 
This message will not appear in this archive until it has been accepted by
the mailing list. You may want to save a copy of this message in case it is
not accepted.



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

Re: Question on Migrating from Flex to FlexJS

2018-11-08 Thread Olaf Krueger

Hmm... just a test, I just replied and it seems my post didn't make it to the
list.




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

Re: Question on Migrating from Flex to FlexJS

2018-11-08 Thread Olaf Krueger

I noticed that rarely/sporadically some posts don't make it to the list for
whatever reason.
Maybe you just should give it another try...?

Olaf




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

Re: Question on Migrating from Flex to FlexJS

2018-11-07 Thread Alex Harui

Hmm.  Try sending an email to d...@royale.apache.org and cc aha...@apache.org 
so I can see what you send.

Thanks,
-Alex

On 11/7/18, 2:54 PM, "hferreira"  wrote:

Alex Harui-2,

I tried both !



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cba602fb975c642eb9c9108d6450407cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772280950151954&sdata=pPe9TByqFWnI30Cjk4xTDgd5n3KOXmqpeNf46i3rImg%3D&reserved=0

Re: Question on Migrating from Flex to FlexJS

Alex Harui-2,

I tried both !



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

Re: Question on Migrating from Flex to FlexJS

2018-11-07 Thread Carlos Rovira

Hi Hugo,

for quick tutorials please check this:

https://royale.apache.org/category/royale-examples/

To see what's capable Royale actually check as well Jewel Example test
project:

https://github.com/apache/royale-asjs/tree/develop/examples/royale/JewelExample

(I think we should have this in running in the website, hope to add this
soon)

To see videos of Royale in action we posted several animated Gif here

http://twitter.com/apacheroyale

IMHO, I'm working in a real Apache Royale for a client now, and I think we
have mostly all the pieces, to go to production at least with Jewel UI set,
and we are focusing in fix bug and add enhancements as we needed.

So I think we are in a beta quality product (and no more an alpha) at least
in some parts and paths to get a real application done today.

If you can join us, and support fixing bugs or doing PRs, that will do a
huge difference to have two more hands contributing

Thanks!

Carlos








El mié., 7 nov. 2018 a las 17:33, Alex Harui ()
escribió:

> Hmm.  Are you using Nabble to email the Royale Dev list or directly
> emailing d...@royale.apache.org?
>
> All Apache lists are moderated.  It is recommended that you subscribe by
> emailing dev-subscr...@royale.apache.org and the email robot will send
> you an acknowledge email that you have to respond to.  If you directly
> email dev@ without subscribing, it should show up in the moderation queue
> and I didn't see anything in the queue.  If you are using Nabble, I don't
> know how it works because I don't use it.  Maybe someone else can help.
>
> -Alex
>
> On 11/7/18, 1:17 AM, "hferreira"  wrote:
>
> Hi Alex,
>
> I have replied on Apache Royale mailing list for users.
> I don't see my post there.
> There is an approval process ?
>
> Regards,
> Hugo.
>
>
>
> --
> Sent from:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cab670c3bd99a467b1ec008d64491dd29%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636771790612395770&sdata=3P4LuqvvPUaH2QuZyxqOpOMUyy%2BPU0wyNqJkt0HXMU8%3D&reserved=0
>
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Question on Migrating from Flex to FlexJS

2018-11-07 Thread Alex Harui

Hmm.  Are you using Nabble to email the Royale Dev list or directly emailing 
d...@royale.apache.org?

All Apache lists are moderated.  It is recommended that you subscribe by 
emailing dev-subscr...@royale.apache.org and the email robot will send you an 
acknowledge email that you have to respond to.  If you directly email dev@ 
without subscribing, it should show up in the moderation queue and I didn't see 
anything in the queue.  If you are using Nabble, I don't know how it works 
because I don't use it.  Maybe someone else can help.

-Alex

On 11/7/18, 1:17 AM, "hferreira"  wrote:

Hi Alex,

I have replied on Apache Royale mailing list for users.
I don't see my post there.
There is an approval process ?

Regards,
Hugo.



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cab670c3bd99a467b1ec008d64491dd29%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636771790612395770&sdata=3P4LuqvvPUaH2QuZyxqOpOMUyy%2BPU0wyNqJkt0HXMU8%3D&reserved=0

Re: Question on Migrating from Flex to FlexJS

OK,

First, as said before it's the top one for Apache Roayle (congrats).
While I'm trying to code, the IDE didn't popup any intelisense (also I don't
saw any window with a log error, so I assumed that intelisense was not
supported).
If you would like to investigated, I don't know where I can help without
logs but I'm using macOS (latest OS version) on a MacBook Pro (latest
version).



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

Re: Question on Migrating from Flex to FlexJS

2018-11-07 Thread Piotr Zarzycki

Hugo,

Even if you won't end up using Moonshine with Royale - your initial
experience would be very valuable to us. We wanted to improve that IDE
until experience will be smooth. :)

Thanks,
Piotr

śr., 7 lis 2018 o 10:22 hferreira  napisał(a):

> piotrz,
>
> "In case of Moonshine are you saying that your experience was bad
> previously"
> I appreciate your efforts about Moonshine but I believe that I never said
> that. I'm focus with Apache Royale and tried now Moonshine among others.
>
> "Moonshine has full intellisence support."
> I didn't know. I assume that intelisense was not supported.
>
> "We are a bit delayed with release cause Apple App
> store hold us"
> That's why I don't use Apple Store for desktop Apps :D
>
>
>
> --
> Sent from: http://apache-flex-development.247.n4.nabble.com/
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Question on Migrating from Flex to FlexJS

piotrz,

"In case of Moonshine are you saying that your experience was bad 
previously"
I appreciate your efforts about Moonshine but I believe that I never said
that. I'm focus with Apache Royale and tried now Moonshine among others.

"Moonshine has full intellisence support."
I didn't know. I assume that intelisense was not supported.

"We are a bit delayed with release cause Apple App 
store hold us"
That's why I don't use Apple Store for desktop Apps :D



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

Re: Question on Migrating from Flex to FlexJS

Hi Alex,

I have replied on Apache Royale mailing list for users.
I don't see my post there.
There is an approval process ?

Regards,
Hugo.



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

Re: Question on Migrating from Flex to FlexJS

2018-11-07 Thread Piotr Zarzycki

Hugo,

Moonshine has full intellisence support. If something doesn't work for you
provide details. I do recommend using Nightly Build of Royale for now. We
have on our pipeline release Moonshine 1.16.0. I can send you off the list
Nightly build as well. We are a bit delayed with release cause Apple App
store hold us with new requirements which we are trying to full fill.

Thanks,
Piotr

śr., 7 lis 2018 o 10:04 Piotr Zarzycki 
napisał(a):

> Hi Hugo,
>
> In case of Moonshine are you saying that your experience was bad
> previously, currently nothing change for you as well ?
>
> Thanks,
> Piotr
>
> wt., 6 lis 2018 o 19:28 hferreira  napisał(a):
>
>> I just checked the Apache Royale web site and seems good (comparing to my
>> last visit a long time ago).
>> Still many "TODO" pages.
>>
>> By change, I tried the starting IntelliJ and a TODO page.
>> However I see that the others IDE's already have a start page, but I don't
>> use Flash Builder (for many years now), Visual Studio Code it's not a IDE
>> and I would not go thru Moonshine (I don't want to see me there), so I
>> will
>> try with Visual Studio Code the tutorial.
>>
>> I checked the mailing list (for the very first time) and surprisingly
>> seems
>> to be very active).
>>
>> I definitively will try later to build a sample use case.
>>
>> I know that this is a community project (and that a strong point on my
>> opinion), however I continue to think that an important peace is messing:
>> A
>> lot of tutorials and sample starting projects.
>>
>>
>>
>> --
>> Sent from: http://apache-flex-development.247.n4.nabble.com/
>>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Question on Migrating from Flex to FlexJS

2018-11-07 Thread Piotr Zarzycki

Hi Hugo,

In case of Moonshine are you saying that your experience was bad
previously, currently nothing change for you as well ?

Thanks,
Piotr

wt., 6 lis 2018 o 19:28 hferreira  napisał(a):

> I just checked the Apache Royale web site and seems good (comparing to my
> last visit a long time ago).
> Still many "TODO" pages.
>
> By change, I tried the starting IntelliJ and a TODO page.
> However I see that the others IDE's already have a start page, but I don't
> use Flash Builder (for many years now), Visual Studio Code it's not a IDE
> and I would not go thru Moonshine (I don't want to see me there), so I will
> try with Visual Studio Code the tutorial.
>
> I checked the mailing list (for the very first time) and surprisingly seems
> to be very active).
>
> I definitively will try later to build a sample use case.
>
> I know that this is a community project (and that a strong point on my
> opinion), however I continue to think that an important peace is messing: A
> lot of tutorials and sample starting projects.
>
>
>
> --
> Sent from: http://apache-flex-development.247.n4.nabble.com/
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Question on Migrating from Flex to FlexJS

Hi,

The next release should have better support for emulation components. You do
have to change the xml namespace to use them:

xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:s="library://ns.adobe.com/flex/spark"

need to be changed to:

xmlns:mx="library://ns.apache.org/royale/mx"
xmlns:s="library://ns.apache.org/royale/spark"

Regarding migrating your application, we have some tooling to try to analyze
your code and see what Flash and Flex APIs are using. And you can just fork
your code, replace the XML namespaces and see what happens.

Regarding the external components, you can examine the imports they use to see
what flash classes are being used. MXML files have some hidden "automatic"
imports so it is a bit harder to see what they use. We have emulated some
Flash classes, but it is not a goal to emulate all of them. We want to get
away from dependencies on Flash APIs because some sort of rely on the way Flash
renders, and some features like listener priorities and weak references are not
easily reproduced on other platforms.

You can get started now with a nightly build. Please continue the conversation
over at d...@royale.apache.org.

Thanks,
-Alex

On 11/6/18, 5:26 PM, "hferreira" wrote:

Hi Alex,

I just come from the first Apache Royale test (current version 0.9.2).
I think that my last attempt was 0.5 (or less) !

Starting on the IDE:
I know by now why there is no starting tutorial for IntelliJ: Because does
guys are waiting to see where this will end up, so there is no official
IntelliJ support by now.
Flash Builder as said before is not an opinion for years and I will not go
back there.
I tryed Moonshine and seems that this IDE was designed for Apache Royale. I
couldn't expect that could be easier to start a project (even for a
beginner), however without intellisense support unfortunately it's a no.
For last but not least, I went thru Visual Studio Code (ho, boy that text
editor evolved from my last test). Everything it's manual however following
this instructions

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FVisual-Studio-Code&data=02%7C01%7Caharui%40adobe.com%7C49a953b78b2a4e324c2208d6444fff87%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636771507711668266&sdata=jIJop6p5wZur1kZksz%2BvBUGjxeQmchJ06Rpq21ffsoQ%3D&reserved=0
I was able to
build a Hello Word test project and then started to play around.
Intellisense works out of the box !
And I saw references to TLF on intellisense that you mentioned before (very
good :) ).

Pure Apache Royale it's noticeable more mature than before and without
compiling errors on the first experience. It's not a alpha product anymore
an deserves to be almost version 1.0 but this was a short test.
I didn't even care about debug for now.

As explain before, for me, to be even possible to move from Apache Flex to
Apache Royale, I need to:
1. Move a very big ship (block by block) to your new approach emulation
components (accepting that they will not optimised for speed);
2. Find a way to move a few external components (I have the source code of
all them);
3. Fix a lot of issues during a few months in tests;
4. Then and only then, I can start moving pieces of components to pure
Apache Royale (accepting that there is the possibility to end up with a mix
of pure Apache Royale components and emulated ones but I already have that
with MX and Spark anyway).

During this test, I tryed but not be able to use any MX component so my
guess is that is not yet on this release and perhaps only on the night
builds or even on your local machine waiting for commit. This assumption is
correct ?
MX and Spark emulation are predicted for the next 0.9.3 ?

As you can imagine, there is old code that is not following the best
approach.
I have the business logic separated from the UI but it's not all the cases.
My first work will be starting refactoring and this, I can start right now.
As much perfection my code is before the port, easier will be.
Then, only after MX and Spark emulation be on a release will make sense to
start but I'm excited to do and when I enter on that space, for sure that I
will be a contributor (at least on documentation for others, report bugs and
provide fixs).

Thank you very much for you work since always on this project.
For what I saw, I believe that one day I may move my code (I was not
expecting that).

--
Sent from:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C49a953b78b2a4e324c2208d6444fff87%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636771507711668266&sdata=4slKcrT4gvKwLoDhtvOfNXPMX%2BDEf7sGRI7qDUOcPts%3D&r

Re: Question on Migrating from Flex to FlexJS

Hi Alex,

I just come from the first Apache Royale test (current version 0.9.2).
I think that my last attempt was 0.5 (or less) !

Starting on the IDE:
I know by now why there is no starting tutorial for IntelliJ: Because does
guys are waiting to see where this will end up, so there is no official
IntelliJ support by now.
Flash Builder as said before is not an opinion for years and I will not go
back there.
I tryed Moonshine and seems that this IDE was designed for Apache Royale. I
couldn't expect that could be easier to start a project (even for a
beginner), however without intellisense support unfortunately it's a no.
For last but not least, I went thru Visual Studio Code (ho, boy that text
editor evolved from my last test). Everything it's manual however following
this instructions
https://github.com/apache/royale-asjs/wiki/Visual-Studio-Code I was able to
build a Hello Word test project and then started to play around.
Intellisense works out of the box !
And I saw references to TLF on intellisense that you mentioned before (very
good :) ).

Pure Apache Royale it's noticeable more mature than before and without
compiling errors on the first experience. It's not a alpha product anymore
an deserves to be almost version 1.0 but this was a short test.
I didn't even care about debug for now.

As explain before, for me, to be even possible to move from Apache Flex to
Apache Royale, I need to:
1. Move a very big ship (block by block) to your new approach emulation
components (accepting that they will not optimised for speed);
2. Find a way to move a few external components (I have the source code of
all them);
3. Fix a lot of issues during a few months in tests;
4. Then and only then, I can start moving pieces of components to pure
Apache Royale (accepting that there is the possibility to end up with a mix
of pure Apache Royale components and emulated ones but I already have that
with MX and Spark anyway).

During this test, I tryed but not be able to use any MX component so my
guess is that is not yet on this release and perhaps only on the night
builds or even on your local machine waiting for commit. This assumption is
correct ?
MX and Spark emulation are predicted for the next 0.9.3 ?

As you can imagine, there is old code that is not following the best
approach.
I have the business logic separated from the UI but it's not all the cases.
My first work will be starting refactoring and this, I can start right now.
As much perfection my code is before the port, easier will be.
Then, only after MX and Spark emulation be on a release will make sense to
start but I'm excited to do and when I enter on that space, for sure that I
will be a contributor (at least on documentation for others, report bugs and
provide fixs).

Thank you very much for you work since always on this project.
For what I saw, I believe that one day I may move my code (I was not
expecting that).



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

Re: Question on Migrating from Flex to FlexJS

Hi,

Yes, your understanding is correct in that there is a set of components in
Royale called Basic that are aimed more at small, fast applications than at
backward-compatibility with Flex.

It is a fair amount of work to migrate your code to the Basic components,
although still much less work than porting all of our code to some other JS
Framework. If you have good separation of "business logic" from your UI, you
should find that your business logic can be used with few changes. That's the
biggest savings as you don't have to debug all of those lines of code agin.
Instead, the work is in rewriting your UI to use the Basic components, although
some folks want to do that anyway to modernize their UI.

Carlos is working on a component set called Jewel that has more modern UI
widgets.

And I and some others are working on the Emulation Components. Their goal is
to require much less rewriting of your existing Flex MXML. It won't be as
small and fast, and you will be able to swap out some pieces for smaller/faster
ones if you need to and have the time. It isn't really a one-man show. For
sure, I am doing a significant amount of the work, but there are others helping
out in smaller contributions and every contribution counts. We hope you and
others will join us.

Thanks,
-Alex

On 11/6/18, 11:10 AM, "hferreira" wrote:

My beloved flex tour (not see for a long time now) in Roayle :D
I read in the past that intention but did not know it was actually done.

"I am focused on the Emulation Components that are intended to mimic MX and
Spark components in Flex in order to lower the effort of migrating from Flex
to Royale"
That would definitively make the things easier and it's on my opinion the
good way to go.
I understand that started as things in Royale that are not compatible with
Flex, so you could evolve however have a compatible layer it's a most to
have.
If I migrate an entire project, later I can move each piece for something
more like Royale.

I understand that this is a community but end up with one man show (you).

I would love to contribute as I already did (a little) with Flex, however I
need to first enter on Roayle that it's a completly new game for me, so I'm
new on that field but you wake up my interested, so I will check later.

Thank you.

--
Sent from:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ce0c59550ffae46b87de408d6441b7dd2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636771282197811599&sdata=CVggiJDcWzGHhWKKU930jt2RmG4Lj5fA87EL1HQJKz0%3D&reserved=0

Re: Question on Migrating from Flex to FlexJS

My beloved flex tour (not see for a long time now) in Roayle :D
I read in the past that intention but did not know it was actually done.

"I am focused on the Emulation Components that are intended to mimic MX and
Spark components in Flex in order to lower the effort of migrating from Flex
to Royale"
That would definitively make the things easier and it's on my opinion the
good way to go.
I understand that started as things in Royale that are not compatible with
Flex, so you could evolve however have a compatible layer it's a most to
have.
If I migrate an entire project, later I can move each piece for something
more like Royale.

I understand that this is a community but end up with one man show (you).

I would love to contribute as I already did (a little) with Flex, however I
need to first enter on Roayle that it's a completly new game for me, so I'm
new on that field but you wake up my interested, so I will check later.

Thank you.




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

Re: Question on Migrating from Flex to FlexJS

Yep, we can always use more tutorials and other "on-boarding" material.

I personally have not worked too much on that because I think for right now, my
energy is best spent on making sure that the code actually works. It seems
that most folks don't have the experience and time to work on that. I think
that there are more folks, including you, who are capable of writing small bits
of documentation and examples and could help us build up that set of material.

One thing about Royale is that there is no one set of UI widgets that you must
use. I think that's good in that you are not locked into using MX or Spark or
in Royale's case, the Basic components or Jewel. You can use Jquery, CreateJS,
Material Design Lite. You can wrap any existing JS framework that has a
procedural API, and probably others if you really wanted to. Royale is really
in the business of creating a software developer workflow for assembling chunks
of JavaScript together. But that makes it harder for generating
getting-started materials because there are multiple paths you can get started
on.

Right now, I am focused on the Emulation Components that are intended to mimic
MX and Spark components in Flex in order to lower the effort of migrating from
Flex to Royale. It won't be 100% backward compatible, but should be much less
rewriting than porting to other JS frameworks.

Here is a link to Tour De Flex migrated to Royale with relatively few changes:
http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/TourDeFlexMigration/lastSuccessfulBuild/artifact/examples/mxroyale/tourdeflexmodules/bin/js-debug/index.html

Only the MX/Visual Components/General Controls have been seen to run (except
ColorPicker), but I'm finishing up LineChart right now. The demo may break at
times and the visuals are not tuned up, but it will give you an idea of what is
possible. We just need more folks to contribute. Anyone who contributes helps
lower the cost of migrating for everyone else. If we get lots of people
pitching in, it is like having a large team to migrate your app.

-Alex

On 11/6/18, 10:28 AM, "hferreira" wrote:

I just checked the Apache Royale web site and seems good (comparing to my
last visit a long time ago).
Still many "TODO" pages.

By change, I tried the starting IntelliJ and a TODO page.
However I see that the others IDE's already have a start page, but I don't
use Flash Builder (for many years now), Visual Studio Code it's not a IDE
and I would not go thru Moonshine (I don't want to see me there), so I will
try with Visual Studio Code the tutorial.

I checked the mailing list (for the very first time) and surprisingly seems
to be very active).

I definitively will try later to build a sample use case.

I know that this is a community project (and that a strong point on my
opinion), however I continue to think that an important peace is messing: A
lot of tutorials and sample starting projects.

--
Sent from:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C98beed1437d84a741e8d08d64415b3c4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636771257328824888&sdata=Bza%2BXb2j9086t6pxylfvIbm2vP%2FusJxy4pGrWHquuJc%3D&reserved=0

Re: Question on Migrating from Flex to FlexJS

I just checked the Apache Royale web site and seems good (comparing to my
last visit a long time ago).
Still many "TODO" pages.

By change, I tried the starting IntelliJ and a TODO page.
However I see that the others IDE's already have a start page, but I don't
use Flash Builder (for many years now), Visual Studio Code it's not a IDE
and I would not go thru Moonshine (I don't want to see me there), so I will
try with Visual Studio Code the tutorial.

I checked the mailing list (for the very first time) and surprisingly seems
to be very active).

I definitively will try later to build a sample use case.

I know that this is a community project (and that a strong point on my
opinion), however I continue to think that an important peace is messing: A
lot of tutorials and sample starting projects.



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

Re: Question on Migrating from Flex to FlexJS

"but TLF is running in Royale without Flash/AIR"
Really !
That's good news (for me) to know.
I'm out of Royale, so I'm probably outdated on that area.

As said before, my experience with FlexJS (now Apache Royale) was a long
time ago on a early days and on that time, what I saw was a pre-alpha
quality product.
Perhaps I should try again now and see what is capable of.

There is a tutorial for scratch using IntelliJ (or other IDEA but I prefer
IntelliJ) ?
A simple hello word that I could just build (ie transpite) and then evolve
to check was is possible to do and what is not ?



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

Re: Question on Migrating from Flex to FlexJS

FWIW, Harbs can say more about what didn't get migrated, but TLF is running in 
Royale without Flash/AIR.

What else is on your list of missing features?

Thanks,
-Alex

On 11/6/18, 3:30 AM, "hferreira"  wrote:

Hi,

I will give you my input of this one:
I have a large Flex project for many years now (more than 1.5 millions lines
of code and growing).
This project started for AIR because on that time was predicted that one day
Flash on Web will end and HTML5 was just an ideia on that time (also there
was the intention to use features directly from desktop that they are very
difficult to get on the web space).
Even so, this project have very complex features that it's not possible on
the present with any web technology that I know !

    I already tested FlexJS (now Apache Royale) for about 2 years now and "for
me" it was a pre-alpha quality product on that time.
I believe that now it's more mature but even so without things like Flex TLF
support I wouldn't even take a look and probably we will never get this kind
of specific features.

If I was you, I would take a look on Apache Royale and invest a few time to
try to port the code (at least you will know if this is an option to
consider or not).

Than you have the AIR option that it's a guarantee low friction porting
option, however it's a change of paradigma (desktop vs web).
I strongly recommend a "click once"/"auto-update" or what ever you would
like to call, option.
For this, I designed mysef an auto-update mechanism compatible with Windows
and macOS available on Github with MIT license.



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cce0c080802bd49874d9b08d643db3f9e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63677100627482&sdata=6E6%2FQqdP4YmQ%2FZO3KhkeThl3oUpKvOmFhNd3nwX8k3A%3D&reserved=0

Re: Question on Migrating from Flex to FlexJS

Check this out: https://github.com/SolidSoft-Lda/AIR-AutoUpdate
This AutoUpdate engine auto restart the Desktop App after the update 
(compatible with macOS, Win-32 and Win-64). 



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

Re: Question on Migrating from Flex to FlexJS

2018-11-06 Thread Carlos Rovira

Hi Hugo,

maybe you should post the like to your auto-update solution, so people
could check it.

thanks for you points, very valuable

Carlos



El mar., 6 nov. 2018 a las 12:30, hferreira ()
escribió:

> Hi,
>
> I will give you my input of this one:
> I have a large Flex project for many years now (more than 1.5 millions
> lines
> of code and growing).
> This project started for AIR because on that time was predicted that one
> day
> Flash on Web will end and HTML5 was just an ideia on that time (also there
> was the intention to use features directly from desktop that they are very
> difficult to get on the web space).
> Even so, this project have very complex features that it's not possible on
> the present with any web technology that I know !
>
> I already tested FlexJS (now Apache Royale) for about 2 years now and "for
> me" it was a pre-alpha quality product on that time.
> I believe that now it's more mature but even so without things like Flex
> TLF
> support I wouldn't even take a look and probably we will never get this
> kind
> of specific features.
>
> If I was you, I would take a look on Apache Royale and invest a few time to
> try to port the code (at least you will know if this is an option to
> consider or not).
>
> Than you have the AIR option that it's a guarantee low friction porting
> option, however it's a change of paradigma (desktop vs web).
> I strongly recommend a "click once"/"auto-update" or what ever you would
> like to call, option.
> For this, I designed mysef an auto-update mechanism compatible with Windows
> and macOS available on Github with MIT license.
>
>
>
> --
> Sent from: http://apache-flex-development.247.n4.nabble.com/
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Question on Migrating from Flex to FlexJS

Hi,

I will give you my input of this one:
I have a large Flex project for many years now (more than 1.5 millions lines
of code and growing).
This project started for AIR because on that time was predicted that one day
Flash on Web will end and HTML5 was just an ideia on that time (also there
was the intention to use features directly from desktop that they are very
difficult to get on the web space).
Even so, this project have very complex features that it's not possible on
the present with any web technology that I know !

I already tested FlexJS (now Apache Royale) for about 2 years now and "for
me" it was a pre-alpha quality product on that time.
I believe that now it's more mature but even so without things like Flex TLF
support I wouldn't even take a look and probably we will never get this kind
of specific features.

If I was you, I would take a look on Apache Royale and invest a few time to
try to port the code (at least you will know if this is an option to
consider or not).

Than you have the AIR option that it's a guarantee low friction porting
option, however it's a change of paradigma (desktop vs web).
I strongly recommend a "click once"/"auto-update" or what ever you would
like to call, option.
For this, I designed mysef an auto-update mechanism compatible with Windows
and macOS available on Github with MIT license.



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

Re: Question on Migrating from Flex to FlexJS

2018-11-04 Thread Carlos Rovira

Hi Michelle,

maybe one more thing that you should know is about the MX and SPARK
emulation effort. Alex and others and working in Royale in emulate the
MX/SPARK Apis and components, so people that wants to migrate from Flex to
Royale (before known as FlexJS) can do it more quickly

The work is still in progress, but many people could still compile his code
agains that code, although many of the components still doesn't show on
screen, and that will come hopefully soon. You (and others) are welcome to
contribute and help in that effort.

To know more about Apache Royale visit our webstite:
https://royale.apache.org, and follow us on twitter, facebook, linkedIn
and/our Google plus

thanks

Carlos





El jue., 1 nov. 2018 a las 19:36, Alex Harui ()
escribió:

> Hi Michelle,
>
> FlexJS became the Apache Royale project about a year ago.  I encourage you
> to find out more about FlexJS/Royale on the Royale mailing list (
> d...@royale.apache.org).
>
> It isn't just IE and Edge.  Just about every popular browser will turn off
> Flash by the end of 2020.  Of course, I'm biased towards Royale since
> that's what I spend my day working on, but I think the safest choice is to
> choose an open-source development environment like Royale.  That way you
> are free from corporate decisions about product futures.  No corporation
> controls Apache projects like Royale, and users are encouraged to become
> contributors so that you or other people like you can help cut releases,
> fix bugs, create new features, etc.  That way, you ensure that you have
> more control over the future.
>
> So far, I've heard the following options:
>
> 1) Apache Royale
> 2) Adobe AIR
> 3) Extended IE support
> 4) Custom Browser.
>
> Depending on resources and timeframes, Adobe AIR might make sense if you
> are ok changing your deployment model.  All future updates have to be
> "installed" or your AIR app has to be a "shell" that downloads the rest of
> the app.  Converting a Flash Browser app to AIR might be less work if there
> is a lot of Flash animation/timeline content.  Royale doesn't have any
> replacement for frame-based SWF animations.  If you know that browser video
> quality is insufficient, you might also choose AIR video.  You also need to
> be aware of subtle differences between AIR and Flash around security,
> ExternalInterface, and some other APIs.  On the other hand, having access
> to the file system might be a benefit.
>
> If you control what browser your users use, I've heard that IE will have
> extended support for Flash, but I think there is an end date for that
> eventually.
>
> I've also heard that some folks are trying to create browsers that will
> host the Flash plugin.
>
> Anyway, I hope to see you on the Royale lists.
>
> -Alex
>
> On 11/1/18, 3:00 AM, "michelle_s...@tzuchi.com.tw" <
> michelle_s...@tzuchi.com.tw> wrote:
>
> Hi, good day!
>
> We have a very large and complex healthcare information system
> where its front-end is written in Flex
> (the Flex SDK we are currently using is FlexSDK416).
>
> We are very concerned about the future of the browser support
> particularly Internet Explorer & Edge
> for our Flex applicaton.
>
> If Internet Explorer & Edge will not be supporting Flex anymore
> starting
> next year,
> how and to what technology should we migrate our Flex application?
> Should we use AIR, FlexJS or which one is appropriate?
> I would like to have your professional advise on this matter as you
> are
> the experts on Flex.
>
> I would greatly appreciate your response on this matter.
>
> Thanks and regards,
> Michelle
> Hualien, Taiwan
> Tzu Chi Medical Foundation
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Question on Migrating from Flex to FlexJS

2018-11-01 Thread Alex Harui

Hi Michelle,

FlexJS became the Apache Royale project about a year ago.  I encourage you to 
find out more about FlexJS/Royale on the Royale mailing list 
(d...@royale.apache.org).

It isn't just IE and Edge.  Just about every popular browser will turn off 
Flash by the end of 2020.  Of course, I'm biased towards Royale since that's 
what I spend my day working on, but I think the safest choice is to choose an 
open-source development environment like Royale.  That way you are free from 
corporate decisions about product futures.  No corporation controls Apache 
projects like Royale, and users are encouraged to become contributors so that 
you or other people like you can help cut releases, fix bugs, create new 
features, etc.  That way, you ensure that you have more control over the future.

So far, I've heard the following options:

1) Apache Royale
2) Adobe AIR
3) Extended IE support
4) Custom Browser.

Depending on resources and timeframes, Adobe AIR might make sense if you are ok 
changing your deployment model.  All future updates have to be "installed" or 
your AIR app has to be a "shell" that downloads the rest of the app.  
Converting a Flash Browser app to AIR might be less work if there is a lot of 
Flash animation/timeline content.  Royale doesn't have any replacement for 
frame-based SWF animations.  If you know that browser video quality is 
insufficient, you might also choose AIR video.  You also need to be aware of 
subtle differences between AIR and Flash around security, ExternalInterface, 
and some other APIs.  On the other hand, having access to the file system might 
be a benefit.

If you control what browser your users use, I've heard that IE will have 
extended support for Flash, but I think there is an end date for that 
eventually.

I've also heard that some folks are trying to create browsers that will host 
the Flash plugin.

Anyway, I hope to see you on the Royale lists.

-Alex

On 11/1/18, 3:00 AM, "michelle_s...@tzuchi.com.tw" 
 wrote:

Hi, good day!

We have a very large and complex healthcare information system 
where its front-end is written in Flex 
(the Flex SDK we are currently using is FlexSDK416).

We are very concerned about the future of the browser support 
particularly Internet Explorer & Edge 
for our Flex applicaton.

If Internet Explorer & Edge will not be supporting Flex anymore starting 
next year,
how and to what technology should we migrate our Flex application?
Should we use AIR, FlexJS or which one is appropriate?
I would like to have your professional advise on this matter as you are 
the experts on Flex.

I would greatly appreciate your response on this matter.

Thanks and regards,
Michelle
Hualien, Taiwan
Tzu Chi Medical Foundation

Question on Migrating from Flex to FlexJS

2018-11-01 Thread michelle_siao

Hi, good day!

We have a very large and complex healthcare information system 
where its front-end is written in Flex 
(the Flex SDK we are currently using is FlexSDK416).

We are very concerned about the future of the browser support 
particularly Internet Explorer & Edge 
for our Flex applicaton.

If Internet Explorer & Edge will not be supporting Flex anymore starting 
next year,
how and to what technology should we migrate our Flex application?
Should we use AIR, FlexJS or which one is appropriate?
I would like to have your professional advise on this matter as you are 
the experts on Flex.

I would greatly appreciate your response on this matter.

Thanks and regards,
Michelle
Hualien, Taiwan
Tzu Chi Medical Foundation

Apache Royale (old Apache FlexJS) website is released

2018-01-10 Thread Carlos Rovira

Hi,

just want to let you know about the new Apache Royale website (for those
that already don't know Apache Royale is the evolution of Apache FlexJS,
anyone that wants to track how is evolving should join us at Apache
Royale). More info in the new website:

http://royale.apache.org

You can follow the new twitter account:

http://twitter.com/ApacheRoyale

Or our facebook page:

https://www.facebook.com/Apache-Royale-249305752259661/

Hope you like it

Enjoy! :)


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Retiring Apache FlexJS section from Flex wiki

2018-01-08 Thread Alex Harui

I agree the FlexJS wiki might be causing confusion, but I'd prefer to not
remove any content for a bit longer until Royale has a better web presence.

Thanks,
-Alex

On 1/8/18, 12:59 PM, "Piotr Zarzycki"  wrote:

>Hi Tom,
>
>I wanted to move Intellij web page to Royale, but just didn't have time
>yet. Give me please or make some archive copy if it is possible.
>
>Thanks, Piotr
>
>2018-01-08 17:01 GMT+01:00 Tom Chiverton :
>
>> Pages like [1] are causing confusion for users that missed the move to
>> Apache Royale
>>
>> I'd like to replace the FlexJS page [2] with an explanation and link to
>>[3]
>>
>> Would this cause anyone a problem ?
>>
>> Tom
>>
>> [1] 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FUsing%2BFlexJ&data=02%7C01%7Caha
>>rui%40adobe.com%7C5631975ea5fb4884bc2108d556dac09a%7Cfa7b1b5a7b34438794ae
>>d2c178decee1%7C0%7C0%7C636510419989798645&sdata=r4%2FAOYwzNwWibE6M8DBTWdy
>>foXwdtj2QPi2QT%2FFZpl4%3D&reserved=0
>> S+with+IntelliJ+IDEA
>> [2] 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FFlexJS&data=02%7C01%7Caharui%40a
>>dobe.com%7C5631975ea5fb4884bc2108d556dac09a%7Cfa7b1b5a7b34438794aed2c178d
>>ecee1%7C0%7C0%7C636510419989798645&sdata=3%2FWdd3SqKsL5%2FCBRdTEp0zfDOCK4
>>rQ50WEWVrz9Wnck%3D&reserved=0
>> [3] 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-asjs%2Fwiki&data=02%7C01%7Caharui%40adobe.com%7C5631
>>975ea5fb4884bc2108d556dac09a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7
>>C636510419989798645&sdata=v82TtNjDUW1btfu5ENRRoKMBgtJrAsHQIWolLe5j%2FA4%3
>>D&reserved=0
>>
>>
>> On 02/01/18 13:32, matflavio wrote:
>>
>>> Estou seguindo esse tutorial do link
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.a
>>>pache.org%2Fconfluence%2Fdisplay%2FFLEX%2FUsing%2BFlexJ&data=02%7C01%7Ca
>>>harui%40adobe.com%7C5631975ea5fb4884bc2108d556dac09a%7Cfa7b1b5a7b3443879
>>>4aed2c178decee1%7C0%7C0%7C636510419989798645&sdata=r4%2FAOYwzNwWibE6M8DB
>>>TWdyfoXwdtj2QPi2QT%2FFZpl4%3D&reserved=0
>>> S+with+IntelliJ+IDEA
>>> porém estou com o seguinte erro no momento de executar You should be
>>>able
>>> to
>>> build your project now, click on Build -> Rebuild project. (Fix the
>>> eventual
>>> error the compiler found and use Build -> Make project).
>>>
>>> Error:[exemplo]: java.lang.NoSuchMethodException:
>>> org.apache.flex.compiler.clients.MXMLJSC.(org.apache.
>>> flex.compiler.driver.IBackend)
>>>
>>>
>>> O que pode ser?
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>lex-users.246.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C5
>>>631975ea5fb4884bc2108d556dac09a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7
>>>C0%7C636510419989798645&sdata=%2FrlQTvx38pkD%2B%2BevSMiD78PxSX8JJfQxVg%2
>>>BQqpfN8kg%3D&reserved=0
>>>
>>> __
>>> This email has been scanned by the Symantec Email Security.cloud
>>>service.
>>> For more information please visit
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.syma
>>>nteccloud.com&data=02%7C01%7Caharui%40adobe.com%7C5631975ea5fb4884bc2108
>>>d556dac09a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365104199897986
>>>45&sdata=iVjv832EFTV8fa3K6QQDJJuHg2WTz%2FSjjmBY3fSlTzc%3D&reserved=0
>>> __
>>>
>>>
>>
>
>
>-- 
>
>Piotr Zarzycki
>
>Patreon: 
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C5631975ea5fb48
>84bc2108d556dac09a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365104199
>89798645&sdata=v1i6832Hgv9midyP%2B4RMhZq8ntxwArTvKg0C3ztwaJA%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C5631975ea5fb48
>84bc2108d556dac09a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365104199
>89798645&sdata=v1i6832Hgv9midyP%2B4RMhZq8ntxwArTvKg0C3ztwaJA%3D&reserved=0
>>*

Re: Retiring Apache FlexJS section from Flex wiki

2018-01-08 Thread Piotr Zarzycki

Hi Tom,

I wanted to move Intellij web page to Royale, but just didn't have time
yet. Give me please or make some archive copy if it is possible.

Thanks, Piotr

2018-01-08 17:01 GMT+01:00 Tom Chiverton :

> Pages like [1] are causing confusion for users that missed the move to
> Apache Royale
>
> I'd like to replace the FlexJS page [2] with an explanation and link to [3]
>
> Would this cause anyone a problem ?
>
> Tom
>
> [1] https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJ
> S+with+IntelliJ+IDEA
> [2] https://cwiki.apache.org/confluence/display/FLEX/FlexJS
> [3] https://github.com/apache/royale-asjs/wiki
>
>
> On 02/01/18 13:32, matflavio wrote:
>
>> Estou seguindo esse tutorial do link
>> https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJ
>> S+with+IntelliJ+IDEA
>> porém estou com o seguinte erro no momento de executar You should be able
>> to
>> build your project now, click on Build -> Rebuild project. (Fix the
>> eventual
>> error the compiler found and use Build -> Make project).
>>
>> Error:[exemplo]: java.lang.NoSuchMethodException:
>> org.apache.flex.compiler.clients.MXMLJSC.(org.apache.
>> flex.compiler.driver.IBackend)
>>
>>
>> O que pode ser?
>>
>>
>>
>>
>>
>> --
>> Sent from: http://apache-flex-users.246.n4.nabble.com/
>>
>> __
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> __
>>
>>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Retiring Apache FlexJS section from Flex wiki

2018-01-08 Thread Tom Chiverton

Pages like [1] are causing confusion for users that missed the move to 
Apache Royale


I'd like to replace the FlexJS page [2] with an explanation and link to [3]

Would this cause anyone a problem ?

Tom

[1] 
https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+IntelliJ+IDEA

[2] https://cwiki.apache.org/confluence/display/FLEX/FlexJS
[3] https://github.com/apache/royale-asjs/wiki


On 02/01/18 13:32, matflavio wrote:

Estou seguindo esse tutorial do link
https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+IntelliJ+IDEA
porém estou com o seguinte erro no momento de executar You should be able to
build your project now, click on Build -> Rebuild project. (Fix the eventual
error the compiler found and use Build -> Make project).

Error:[exemplo]: java.lang.NoSuchMethodException:
org.apache.flex.compiler.clients.MXMLJSC.(org.apache.flex.compiler.driver.IBackend)


O que pode ser?





--
Sent from: http://apache-flex-users.246.n4.nabble.com/

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

[FLEXJS][ROYALE] Please subscribe to Royale Mailing Lists

2017-12-26 Thread Alex Harui

Hi,

Looks like a few folks may have missed that FlexJS discussions are now
going on over in the Apache Royale project..

Please subscribe to the d...@royale.apache.org by sending an email to

  dev-subscr...@royale.apache.org

This link might work: mailto:dev-subscr...@royale.apache.org
You will receive an email from the mailing list robot so be sure to check
your spam folder if you don't start receiving email after subscribing.
You can also follow the dev list and find old emails via

  https://lists.apache.org/list.html?d...@royale.apache.org

Or

  http://apache-royale-development.20373.n8.nabble.com
<http://apache-royale-development.20373.n8.nabble.com/>

Dev@ is where we discuss ongoing development of Royale.  There are several
other lists you are encouraged to subscribe to as well:

Users@ is the mailing list for folks using releases that have questions.
It is our support line.  Subscribe to it by sending an email to

  users-subscr...@royale.apache.org

This link might work: mailto:users-subscr...@royale.apache.org
And users@ is archived by both Apache and Nabble.

  https://lists.apache.org/list.html?us...@royale.apache.org
  http://apache-royale-users.20374.n8.nabble.com
<http://apache-royale-users.20374.n8.nabble.com/>

Then we also have two other lists:

Commits@ is where notice of every change to code and doc happens. Again,
to subscribe send an email to:

  commits-subscr...@royale.apache.org

This link might work: mailto:commits-subscr...@royale.apache.org
Archive is only on Apache:
  https://lists.apache.org/list.html?comm...@royale.apache.org

Issues@ will hopefully be where notification of new bug reports and
changes to bugs happen.  We haven't tried it yet because we only just now
got GitHub issues enabled for our repos.  Just like commits@, to
subscribe, send an email to:


  issues-subscr...@royale.apache.org

This link might work: mailto:issues-subscr...@royale.apache.org
Archive is only on Apache:
  https://lists.apache.org/list.html?iss...@royale.apache.org

We hope to close down all discussion of FlexJS and Royale
on the flex.apache.org mailing lists.  We'll keep watching and redirecting
folks for a while, but Royale is where the active discussions will be.

See you over at Royale,
-Alex

Re: Spark components in flexJS

2017-12-06 Thread pol2095

I just tried



but labelField not work, it display [object Object]



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

Re: Spark components in flexJS

2017-12-06 Thread pol2095

I just tried



but labelField not work, it display [object Object] 



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

Re: Spark components in flexJS

2017-12-06 Thread Piotr Zarzycki

Hi,

FlexJS development has been moved to separate project called Apache Royale.
You can shot with that question on "us...@royale.apache.org". There is no
short answer to your question. You will probably need to rewrite UI part of
your applications, cause Royale have very different architecture than Flex.

Additionally make more specific question - which component do you want to
recreate using Royale ?

Thanks, Piotr



2017-12-06 12:51 GMT+01:00 pol2095 :

> Hello,
>
> how to covert this code for flexJS
>
>
>
> Thanks
>
>
>
> --
> Sent from: http://apache-flex-development.247.n4.nabble.com/
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Spark components in flexJS

2017-12-06 Thread pol2095

Hello,

how to covert this code for flexJS



Thanks



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

Re: FlexJS element setter

2017-10-01 Thread Piotr Zarzycki

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.

I'm sorry for a long delay!

Thanks, Piotr


2017-09-26 21:01 GMT+02:00 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

[FLEXJS][ROYALE] Github Issues replacing Apache JIRA

2017-09-29 Thread Alex Harui

Hi,

It looks like GitHub Issues has been enabled on the new Royale repos.  The
Royale folks will no longer be watching Apache JIRA for issues related to
FlexJS and Royale.  Existing FlexJS JIRA issues will not be automatically
migrated to GitHub Issues.  If you have an open FlexJS issue in Apache
JIRA please open a new issue in Github Issues.

GitHub Issues for the royale-asjs repo is here [1]

[1] https://github.com/apache/royale-asjs/issues

Thanks,
-Alex

[FLEXJS][ROYALE] Royale Mailing Lists

2017-09-29 Thread Alex Harui

Hi,

Looks like the Royale mailing lists are up and being archived by Apache
and Nabble.

Please subscribe to the d...@royale.apache.org by sending an email to

  dev-subscr...@royale.apache.org

This link might work: mailto:dev-subscr...@royale.apache.org
You will receive an email from the mailing list robot so be sure to check
your spam folder if you don't start receiving email after subscribing.
You can also follow the dev list and find old emails via

  https://lists.apache.org/list.html?d...@royale.apache.org

Or

  http://apache-royale-development.20373.n8.nabble.com

Dev@ is where we discuss ongoing development of Royale.  There are several
other lists you are encouraged to subscribe to as well:

Users@ is the mailing list for folks using releases that have questions.
It is our support line.  Subscribe to it by sending an email to

  users-subscr...@royale.apache.org

This link might work: mailto:users-subscr...@royale.apache.org
And users@ is archived by both Apache and Nabble.

  https://lists.apache.org/list.html?us...@royale.apache.org
  http://apache-royale-users.20374.n8.nabble.com

Then we also have two other lists:

Commits@ is where notice of every change to code and doc happens. Again,
to subscribe send an email to:

  commits-subscr...@royale.apache.org

This link might work: mailto:commits-subscr...@royale.apache.org
Archive is only on Apache:
  https://lists.apache.org/list.html?comm...@royale.apache.org

Issues@ will hopefully be where notification of new bug reports and
changes to bugs happen.  We haven't tried it yet because we only just now
got GitHub issues enabled for our repos.  Just like commits@, to
subscribe, send an email to:


  issues-subscr...@royale.apache.org

This link might work: mailto:issues-subscr...@royale.apache.org
Archive is only on Apache:
  https://lists.apache.org/list.html?iss...@royale.apache.org

With this email, we hope to close down all discussion of FlexJS and Royale
on the flex.apache.org mailing lists.  We'll keep watching and redirecting
folks for a while, but Royale is where the active discussions will be.

See you over at Royale,
-Alex

Re: [DISCUSS} Fork FlexJS from Apache Flex

2017-09-28 Thread Lee29

Now I can open that link,
Thanks very much for your help!



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

Re: [FLEXJS] New Royale Repos available

2017-09-27 Thread Tom Chiverton

I was thinking we could make those repos read only once Royale has a fork? 
Did anyone have any other ideas, see any problems? 

On 27 September 2017 17:16:43 BST, Alex Harui  wrote:
>Hi Folks,
>
>Looks like the new Royale repos have been created, so I think we need
>to
>switch over to those repos and not make more commits to flex-asjs,
>flex-typedefs, and flex-falcon.
>
>Thanks,
>-Alex
>
>
>__
>This email has been scanned by the Symantec Email Security.cloud
>service.
>For more information please visit http://www.symanteccloud.com
>__

-- 
Tom Chiverton 
Sent from my phone. Please excuse my brevity.

Re: [FLEXJS] New Royale Repos available

2017-09-27 Thread Alex Harui

The new repos are available here:

https://github.com/apache/royale-compiler (was flex-falcon)
https://github.com/apache/royale-typedefs
https://github.com/apache/royale-asjs
https://github.com/apache/royale-tourjs

In addition, we will be building out our royale.apache.org website here:

https://github.com/apache/royale-website

Committers who use the command line and things like "git push" will need a
Personal Access Token [1] and use that as the password.

I was able to push a small change successfully.

HTH,
-Alex

[1] 
https://help.github.com/articles/creating-a-personal-access-token-for-the-c
ommand-line/

On 9/27/17, 9:16 AM, "Alex Harui"  wrote:

>Hi Folks,
>
>Looks like the new Royale repos have been created, so I think we need to
>switch over to those repos and not make more commits to flex-asjs,
>flex-typedefs, and flex-falcon.
>
>Thanks,
>-Alex
>

Re: [FLEXJS] New Royale Repos available

2017-09-27 Thread Dave Fisher

The Royale PMC members ought to subscribe to Private right away. I'm not babble 
dependent and will subscribe to all shortly.

Sent from my iPhone

> On Sep 27, 2017, at 9:37 AM, Alex Harui  wrote:
> 
> The mailing lists appear to be set up, but we may want to get Nabble
> hooked up to them before moving lots of conversations over there.
> 
> -Alex
> 
>> On 9/27/17, 9:28 AM, "Erik de Bruin"  wrote:
>> 
>> How about the mailing lists?
>> 
>> EdB
>> 
>> 
>> 
>> On Wed, Sep 27, 2017 at 6:16 PM, Alex Harui 
>> wrote:
>> 
>>> Hi Folks,
>>> 
>>> Looks like the new Royale repos have been created, so I think we need to
>>> switch over to those repos and not make more commits to flex-asjs,
>>> flex-typedefs, and flex-falcon.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> 
>> 
>> 
>> -- 
>> Ix Multimedia Software
>> 
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>> 
>> T. 06-51952295
>> I. 
>> https://na01.safelinks.protection.outlook.com/?url=www.ixsoftware.nl&data=
>> 02%7C01%7C%7Cabfb660f084b45a4923d08d505c4dbf1%7Cfa7b1b5a7b34438794aed2c178
>> decee1%7C0%7C0%7C636421265414260902&sdata=0tgOy8fgAKrVdHJTpsLvPKFFYBLP%2Br
>> 0Ts7OMlLKtfW4%3D&reserved=0
>

Re: [FLEXJS] New Royale Repos available

2017-09-27 Thread Alex Harui

The mailing lists appear to be set up, but we may want to get Nabble
hooked up to them before moving lots of conversations over there.

-Alex

On 9/27/17, 9:28 AM, "Erik de Bruin"  wrote:

>How about the mailing lists?
>
>EdB
>
>
>
>On Wed, Sep 27, 2017 at 6:16 PM, Alex Harui 
>wrote:
>
>> Hi Folks,
>>
>> Looks like the new Royale repos have been created, so I think we need to
>> switch over to those repos and not make more commits to flex-asjs,
>> flex-typedefs, and flex-falcon.
>>
>> Thanks,
>> -Alex
>>
>>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. 
>https://na01.safelinks.protection.outlook.com/?url=www.ixsoftware.nl&data=
>02%7C01%7C%7Cabfb660f084b45a4923d08d505c4dbf1%7Cfa7b1b5a7b34438794aed2c178
>decee1%7C0%7C0%7C636421265414260902&sdata=0tgOy8fgAKrVdHJTpsLvPKFFYBLP%2Br
>0Ts7OMlLKtfW4%3D&reserved=0

Re: [FLEXJS] New Royale Repos available

2017-09-27 Thread Erik de Bruin

How about the mailing lists?

EdB



On Wed, Sep 27, 2017 at 6:16 PM, Alex Harui 
wrote:

> Hi Folks,
>
> Looks like the new Royale repos have been created, so I think we need to
> switch over to those repos and not make more commits to flex-asjs,
> flex-typedefs, and flex-falcon.
>
> Thanks,
> -Alex
>
>


-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

[FLEXJS] New Royale Repos available

2017-09-27 Thread Alex Harui

Hi Folks,

Looks like the new Royale repos have been created, so I think we need to
switch over to those repos and not make more commits to flex-asjs,
flex-typedefs, and flex-falcon.

Thanks,
-Alex

Re: [DISCUSS} Fork FlexJS from Apache Flex

JS version is working again.

You'll see that it isn't very pretty.  Volunteers are welcome to make it
look better.

Thanks,
-Alex

On 9/26/17, 12:15 PM, "Alex Harui"  wrote:

>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-fl
>>e
>>x-development.247.n4.nabble.com%2F&data=02%7C01%7C%7C3d7199659a8e4262
>>6
>>c5508d504e63dad%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636420309285
>>4
>>80637&sdata=w8lzMqte0%2Bz1fUNI9ZRx0qCnxZSHljVekabpRnuKwmg%3D&reserved=0
>

Re: [DISCUSS} Fork FlexJS from Apache Flex

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&data=02%7C01%7C%7C3d7199659a8e42626
>c5508d504e63dad%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364203092854
>80637&sdata=w8lzMqte0%2Bz1fUNI9ZRx0qCnxZSHljVekabpRnuKwmg%3D&reserved=0

Re: FlexJS element setter

2017-09-26 Thread 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, Peter Ent 
>  wrote:
> 
>  The setter for element is in HTMLElementWrapper, the super class
> for
>  UIBase. The setter for flexes_wrapper is

Re: FlexJS element setter

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 this
 concern?
 
 Your question made me scan through these classes. Looking at this
 code
>>> now
 makes me think we can do a b

Re: FlexJS element setter

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

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

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

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

Re: FlexJS element setter

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

Re: FlexJS element setter

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

Re: FlexJS element setter

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

Re: FlexJS element setter

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 raising this
 concern?
 
 Your question made me scan through these classes. Looking at this
 code
>>> now
 makes me think we can do

Re: FlexJS element setter

2017-09-26 Thread 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
> >> it
> >> for Royale. After all, having code that can be quickly understood
> and
> >> modified is important.
> >>
> >> ‹

Re: FlexJS element setter

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?
>> 
>> 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. Inste

Re: FlexJS element setter

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?
> 
> 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.link
>>>e
>>>din.com%2Fpiotrzarzycki&data=02%7C01%7C%7C6716901213624a0e804708d504e203
>>>9
>>>f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63642029

Re: [DISCUSS} Fork FlexJS from Apache Flex

2017-09-26 Thread 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

@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&data=02%7C01%7C%7C6716901213624a0e804708d504e2039
>>f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636420291136295544&sdata=f
>>Q1CjLGkCpNKxSQBmZn%2BnKZEplQpGl25XACOqq0gO2o%3D&reserved=0
>> 
>>>edin.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%7C01%7C%7C6716901213624a0
>>e804708d504e2039f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364202911
>>36295544&sdata=LzIej2n6WVnm9AG1Hi4NqIZjOQS%2Byo4w%2BPYTX0Rq8Gc%3D&reserve
>>d=0>
>> 
>> GitHub: 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fpiotrzarzycki21&data=02%7C01%7C%7C6716901213624a0e804708d504e2039f%7
>>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636420291136295544&sdata=WeIl
>>LzVsJzRKniD1r9F2xb%2BwljhCLHnurBnl03kBM9E%3D&reserved=0
>

Re: FlexJS element setter

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

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 of RoyaleJS. If we have to make the SWF side pay a bit more,
then so be it. Again, my opinion.

So if cloneNode is more helpful, then do that.

—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

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

2017-09-26 Thread 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

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

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