You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2018/04/23 07:56:23 UTC
About Peter's Royale Foundation
Hi,
I want to discuss some interesting things on Peter's Royale-foundation, or
things that make me thing about it:
1.- One important concept I think is important is that he wants is point 1:
1. *Make a framework independent of Basic and Express but based on the
Core project work.*
With Jewel I want to do the same, at the end people using Jewel should not
need to have "Basic" dependency.
That's why we talked about moving UIBase to Core, but I think we have more
things on Basic that right now are needed and we should take a look to what
things are.
For example: Layouts. I'm creating my own CSS Layouts (still in the works
since I want to use mainly flex box). But Maybe I should not bake Jewel
Layouts in Jewel, but make it a separate library, and that should happen
the same in Basic and have "BasicLayouts" library.
2.- For point 2 (focus on HTML/JS), I think is clear that right now is our
main focus, even in Jewel for me, but I don't want to loose the possibility
to create SWF, and I think that with time we can reach SWF and maybe other
native platforms and that indepence of platform will be amazing.
3.- Point 3 is important:
1. *Use MXML to create the DOM, use ActionScript to handle events, and
use CSS to make it look good and useful.*
I'd like to see how this resolves (still could not look at the code), but I
think that should apply to actual ASJS, even if we deal with SWF, that
should be the way things work for flash as for html.
4.- View Beads, I think this is important. In actual UI sets we have
"createElement" method that makes us to create the view (or at least the
main part of it). In Button we add the html button tag or in jewel slider,
the input range, and so on... this seems to me wrong since we have the
concept of View Beads. I think all of that should be delegated to the View
Bead and make possible for others to change the bead for another if they
want/need. For example in themes, I was able to exchange view beads
successfully and even in flex times I always designed the "visuals" in
separate SWC that has the flex skins, code and css while in normal app
libraries we had controllers, models, and app business logic.
So could be enforce to instead of use "createElement" use a ViewBead? I
think maybe at least in Jewel, since is an UI set very focused on visuals,
and maybe Basic should not?...
5.- for CSS and className point, need to see the code to see how much it
shares with the actual way to handle that in Jewel.
6.- In List the concept of having each data to be represented with
different item renderers seems useful, I found that need some years ago in
a couple of scenarios, if we don't support it in current List, we should
7.- Panel. this flex component never was very needed for me, and I think is
mainly to the way it enforce the layout in flex and the visuals. I'll be
looking at it when I reach that in Jewel. I was thinking in using something
more like an MDL Card, that seems to be what people needs nowadays and can
replace the panel.
Like the concept of interact with content. I think is the way to go. Panel
is only a shell or chrome to layout and present contents.
Don't like the concept of "leftItems" and "rightItems" since that's what a
good sete of layouts should abstract for us without the need of the
component to bake so closely to the component.
8.- Date components are for me a very special component since in desktop
apps and mobile apps it works very different. I think that point is crucial
and at I'll want to make it possible in Jewel, and support easy ways to
enter dates with masks. if input type date is the way to go in HTML, I'll
try that way and look how is done in Basic and foundation to get started.
Maybe if is still not in all browsers we should make it though a polyfill.
Like in MDL and Jewel Alert that uses dialog polyfill, I plan in Jewel to
use more of this like datelist that will bring us nicely possibilities at
least in HTML, that will hard to replicate in SWF but as always doable in
the future.
9.- SVG still needs to come to SWF in some way to make it more usable in
code. For me right now is only usable in CSS
10.-
- Make iFrames available as a component and somehow allow the loaded app
to have access to the main app.
Maybe that should be the foundation of modules??
thanks
--
Carlos Rovira
http://about.me/carlosrovira
Re: About Peter's Royale Foundation
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Maybe, but I would think that almost all complex views are putting children inside a DIV and UIBase's createElement creates that DIV for you, and early enough for it to be parented in addedToParent. The View shouldn't really have to be created early in the lifecycle. The initial setting of properties should populate the model and then the view can be constructed "later" and pull data from the model. Views are currently created after parenting in addedToParent.
So I would expect that the current code is fine the way it is and we should try to live with it for now. I really wish we weren't spending all of this time now trying to re-do things that work. I’m not getting any time to work on emulation. All I'm doing these days is trying to fix builds, and optimize stuff that isn't really making a huge difference to Alina and other migrators.
My 2 cents,
-Alex
On 4/24/18, 1:14 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
Hi Alex,
I'm thinking about this and suppose that the way to overcome it, with the
actual code, is simply to left "createElement()" empty and make all things
in the View. That will end with the same right?
thanks
Carlos
2018-04-23 19:44 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> IMO, consistency is the killer of performance in many cases. Consistency
> is important in learning how something operates, so every car should have a
> steering wheel and a gas pedal to the right of the brake pedal in the US.
> And I sure wish cars could put the headlight switch in the same place.
>
> But not every car needs the same engine. Most people don't need to know
> what is going on under the hood. In Royale, there are going to be a bunch
> of components that simply wrap an HTMLElement. No need to add the
> instantiation of a view bead there for consistency. As soon as that
> becomes a performance problem, we'd optimize it right back to being the way
> it is now.
>
> For those who do need view beads, there might be better/faster ways of
> doing it than the current code. But it needs to be PAYG. And I think the
> way it works now is good enough. IMO, we are spending way too much time
> worrying about stuff that isn't nearly as important as getting emulation
> components running on the code we have now. Unless you are sure that folks
> will not be tempted to port Flex apps to Royale because they will care
> about whether all of our components have view beads, we should focus on
> creating the emulation components to prove that Alina can get an app
> migrated in 6 months. I think that will really attract folks. And that
> will help convince my management team that it is worthwhile to continue to
> contribute to Apache Flex and Apache Royale.
>
> My 2 cents,
> -Alex
>
> On 4/23/18, 10:33 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
>
> Hi Peter,
>
> 2018-04-23 14:20 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
>
> > Thanks for this analysis, Carlos! I'll address just a couple of
> things:
> >
> > First, can you not see the code because of some issue with Github
> (did I
> > forget to make it public) or is it just because you are too busy?
> >
>
> I can see it, I just comment that I couldn't still dive into it due to
> my
> work schedule today...I'll take a look as I get time :)
>
>
> >
> > Secondly - view beads. I love the idea of separating them and I
> found it
> > frustrating that a component might have a SWF view bead but not a JS
> view
> > bead. And I originally wrote down in my notes that I would want
> everything
> > to have view beads. But as I started to compose this, and overrode
> > createElement() and made an input, then a button, then a span, it
> just
> > seemed like making a view bead for the sake of making it. Plus there
> are
> > issues of when to really know the right time to construct the parts.
> I
> > don't think view beads are unnecessary; I think the concept needs
> tighter
> > integration into the life cycle. Perhaps the strand loads the view
> bead
> > and instead of relying on events, does viewBead.createElement() and
> calls
> > on IBeadView API instead.
> >
>
> I like viewBead.createElement() you propose. The main class component
> should never create anything of the view.
> Let's see what Alex thinks about this
>
>
> >
> > Panel was something traditional from Flex. I think it might just
> > old-fashioned now, but I also wanted to show how you could achieve
> the
> > look of a Panel without having to proxy the content area. And as for
> > left-items and right-items, I borrowed that concept from mobile apps
> that
> > have navigation bars.
> >
> > Date controls - I think a polyfill is a good way to go. Just didn't
> look
> > into writing one yet.
> >
>
> I'll be creating date controls soon in Jewel, and if I need polyfill
> I'll
> do the same as we do in Alert-Dialog
>
>
> >
> > SVG: I wrote the SVG components mainly as a way to lay the
> groundwork for
> > charts. But maybe the real way to do that is simply with the charts
> > producing the bars and wedges and what-not and draw them using SVG
> > specified in CSS. So many different possibilities!
> >
>
> since in Royale we'll need to deal with SWF, to handle good SVG we will
> need AS3SVGREnderer library,
> but that's difficult since I tried to put in contact with people I the
> project and I didn't succeed but for the main contributor (Lucas)
>
>
> >
> > Again, thanks for taking the time to look at this.
> >
> >
> Thanks you Peter for making this work. and again, hope you'll stay
> with us
> as much as possible! :))
>
> Carlos
>
>
> > ‹peter
> >
> >
> >
> > On 4/23/18, 3:56 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
> >
> > >Hi,
> > >
> > >I want to discuss some interesting things on Peter's
> Royale-foundation, or
> > >things that make me thing about it:
> > >
> > >1.- One important concept I think is important is that he wants is
> point
> > >1:
> > >
> > >
> > >
> > > 1. *Make a framework independent of Basic and Express but based
> on the
> > > Core project work.*
> > >
> > >
> > >With Jewel I want to do the same, at the end people using Jewel
> should not
> > >need to have "Basic" dependency.
> > >That's why we talked about moving UIBase to Core, but I think we
> have more
> > >things on Basic that right now are needed and we should take a look
> to
> > >what
> > >things are.
> > >
> > >For example: Layouts. I'm creating my own CSS Layouts (still in the
> works
> > >since I want to use mainly flex box). But Maybe I should not bake
> Jewel
> > >Layouts in Jewel, but make it a separate library, and that should
> happen
> > >the same in Basic and have "BasicLayouts" library.
> > >
> > >
> > > 2.- For point 2 (focus on HTML/JS), I think is clear that right
> now is
> > >our
> > >main focus, even in Jewel for me, but I don't want to loose the
> > >possibility
> > >to create SWF, and I think that with time we can reach SWF and
> maybe other
> > >native platforms and that indepence of platform will be amazing.
> > >
> > >3.- Point 3 is important:
> > >
> > >
> > > 1. *Use MXML to create the DOM, use ActionScript to handle
> events, and
> > > use CSS to make it look good and useful.*
> > >
> > >I'd like to see how this resolves (still could not look at the
> code), but
> > >I
> > >think that should apply to actual ASJS, even if we deal with SWF,
> that
> > >should be the way things work for flash as for html.
> > >
> > >4.- View Beads, I think this is important. In actual UI sets we have
> > >"createElement" method that makes us to create the view (or at
> least the
> > >main part of it). In Button we add the html button tag or in jewel
> slider,
> > >the input range, and so on... this seems to me wrong since we have
> the
> > >concept of View Beads. I think all of that should be delegated to
> the View
> > >Bead and make possible for others to change the bead for another if
> they
> > >want/need. For example in themes, I was able to exchange view beads
> > >successfully and even in flex times I always designed the "visuals"
> in
> > >separate SWC that has the flex skins, code and css while in normal
> app
> > >libraries we had controllers, models, and app business logic.
> > >
> > >So could be enforce to instead of use "createElement" use a
> ViewBead? I
> > >think maybe at least in Jewel, since is an UI set very focused on
> visuals,
> > >and maybe Basic should not?...
> > >
> > >5.- for CSS and className point, need to see the code to see how
> much it
> > >shares with the actual way to handle that in Jewel.
> > >
> > >6.- In List the concept of having each data to be represented with
> > >different item renderers seems useful, I found that need some years
> ago in
> > >a couple of scenarios, if we don't support it in current List, we
> should
> > >
> > >7.- Panel. this flex component never was very needed for me, and I
> think
> > >is
> > >mainly to the way it enforce the layout in flex and the visuals.
> I'll be
> > >looking at it when I reach that in Jewel. I was thinking in using
> > >something
> > >more like an MDL Card, that seems to be what people needs nowadays
> and can
> > >replace the panel.
> > >
> > >Like the concept of interact with content. I think is the way to
> go. Panel
> > >is only a shell or chrome to layout and present contents.
> > >
> > >Don't like the concept of "leftItems" and "rightItems" since
> that's what
> > >a
> > >good sete of layouts should abstract for us without the need of the
> > >component to bake so closely to the component.
> > >
> > >8.- Date components are for me a very special component since in
> desktop
> > >apps and mobile apps it works very different. I think that point is
> > >crucial
> > >and at I'll want to make it possible in Jewel, and support easy
> ways to
> > >enter dates with masks. if input type date is the way to go in
> HTML, I'll
> > >try that way and look how is done in Basic and foundation to get
> started.
> > >Maybe if is still not in all browsers we should make it though a
> polyfill.
> > >Like in MDL and Jewel Alert that uses dialog polyfill, I plan in
> Jewel to
> > >use more of this like datelist that will bring us nicely
> possibilities at
> > >least in HTML, that will hard to replicate in SWF but as always
> doable in
> > >the future.
> > >
> > >9.- SVG still needs to come to SWF in some way to make it more
> usable in
> > >code. For me right now is only usable in CSS
> > >
> > >10.-
> > >
> > >
> > > - Make iFrames available as a component and somehow allow the
> loaded
> > >app
> > > to have access to the main app.
> > >
> > >
> > >
> > >Maybe that should be the foundation of modules??
> > >
> > >thanks
> > >
> > >
> > >
> > >
> > >--
> > >Carlos Rovira
> > >https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2
> > >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%
> > 7C504edc1f08664b84e96908d5a8
> > >efc7bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636600670158429860&sda
> > >ta=LwPBszdlzs23fvMaKGMVS1QcAlbArkN8lF4cLTlMV6o%3D&reserved=0
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7Cdc4f05bda11046a080cc08d5a9403d83%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636601015820603557&sdata=wIpwZLChBR%2BVN%2F3%
> 2FZd4rbYdnwbFi%2B%2Fy0J6BuB9uMicA%3D&reserved=0
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9e9b4be0ea9f44f45f2008d5a9bb6963%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636601544809855030&sdata=x83MxD5SRoBedfZvh7cDItge6ymU6kc%2FQT2GJn70uYk%3D&reserved=0
Re: About Peter's Royale Foundation
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I'm thinking about this and suppose that the way to overcome it, with the
actual code, is simply to left "createElement()" empty and make all things
in the View. That will end with the same right?
thanks
Carlos
2018-04-23 19:44 GMT+02:00 Alex Harui <ah...@adobe.com.invalid>:
> IMO, consistency is the killer of performance in many cases. Consistency
> is important in learning how something operates, so every car should have a
> steering wheel and a gas pedal to the right of the brake pedal in the US.
> And I sure wish cars could put the headlight switch in the same place.
>
> But not every car needs the same engine. Most people don't need to know
> what is going on under the hood. In Royale, there are going to be a bunch
> of components that simply wrap an HTMLElement. No need to add the
> instantiation of a view bead there for consistency. As soon as that
> becomes a performance problem, we'd optimize it right back to being the way
> it is now.
>
> For those who do need view beads, there might be better/faster ways of
> doing it than the current code. But it needs to be PAYG. And I think the
> way it works now is good enough. IMO, we are spending way too much time
> worrying about stuff that isn't nearly as important as getting emulation
> components running on the code we have now. Unless you are sure that folks
> will not be tempted to port Flex apps to Royale because they will care
> about whether all of our components have view beads, we should focus on
> creating the emulation components to prove that Alina can get an app
> migrated in 6 months. I think that will really attract folks. And that
> will help convince my management team that it is worthwhile to continue to
> contribute to Apache Flex and Apache Royale.
>
> My 2 cents,
> -Alex
>
> On 4/23/18, 10:33 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
>
> Hi Peter,
>
> 2018-04-23 14:20 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
>
> > Thanks for this analysis, Carlos! I'll address just a couple of
> things:
> >
> > First, can you not see the code because of some issue with Github
> (did I
> > forget to make it public) or is it just because you are too busy?
> >
>
> I can see it, I just comment that I couldn't still dive into it due to
> my
> work schedule today...I'll take a look as I get time :)
>
>
> >
> > Secondly - view beads. I love the idea of separating them and I
> found it
> > frustrating that a component might have a SWF view bead but not a JS
> view
> > bead. And I originally wrote down in my notes that I would want
> everything
> > to have view beads. But as I started to compose this, and overrode
> > createElement() and made an input, then a button, then a span, it
> just
> > seemed like making a view bead for the sake of making it. Plus there
> are
> > issues of when to really know the right time to construct the parts.
> I
> > don't think view beads are unnecessary; I think the concept needs
> tighter
> > integration into the life cycle. Perhaps the strand loads the view
> bead
> > and instead of relying on events, does viewBead.createElement() and
> calls
> > on IBeadView API instead.
> >
>
> I like viewBead.createElement() you propose. The main class component
> should never create anything of the view.
> Let's see what Alex thinks about this
>
>
> >
> > Panel was something traditional from Flex. I think it might just
> > old-fashioned now, but I also wanted to show how you could achieve
> the
> > look of a Panel without having to proxy the content area. And as for
> > left-items and right-items, I borrowed that concept from mobile apps
> that
> > have navigation bars.
> >
> > Date controls - I think a polyfill is a good way to go. Just didn't
> look
> > into writing one yet.
> >
>
> I'll be creating date controls soon in Jewel, and if I need polyfill
> I'll
> do the same as we do in Alert-Dialog
>
>
> >
> > SVG: I wrote the SVG components mainly as a way to lay the
> groundwork for
> > charts. But maybe the real way to do that is simply with the charts
> > producing the bars and wedges and what-not and draw them using SVG
> > specified in CSS. So many different possibilities!
> >
>
> since in Royale we'll need to deal with SWF, to handle good SVG we will
> need AS3SVGREnderer library,
> but that's difficult since I tried to put in contact with people I the
> project and I didn't succeed but for the main contributor (Lucas)
>
>
> >
> > Again, thanks for taking the time to look at this.
> >
> >
> Thanks you Peter for making this work. and again, hope you'll stay
> with us
> as much as possible! :))
>
> Carlos
>
>
> > ‹peter
> >
> >
> >
> > On 4/23/18, 3:56 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
> >
> > >Hi,
> > >
> > >I want to discuss some interesting things on Peter's
> Royale-foundation, or
> > >things that make me thing about it:
> > >
> > >1.- One important concept I think is important is that he wants is
> point
> > >1:
> > >
> > >
> > >
> > > 1. *Make a framework independent of Basic and Express but based
> on the
> > > Core project work.*
> > >
> > >
> > >With Jewel I want to do the same, at the end people using Jewel
> should not
> > >need to have "Basic" dependency.
> > >That's why we talked about moving UIBase to Core, but I think we
> have more
> > >things on Basic that right now are needed and we should take a look
> to
> > >what
> > >things are.
> > >
> > >For example: Layouts. I'm creating my own CSS Layouts (still in the
> works
> > >since I want to use mainly flex box). But Maybe I should not bake
> Jewel
> > >Layouts in Jewel, but make it a separate library, and that should
> happen
> > >the same in Basic and have "BasicLayouts" library.
> > >
> > >
> > > 2.- For point 2 (focus on HTML/JS), I think is clear that right
> now is
> > >our
> > >main focus, even in Jewel for me, but I don't want to loose the
> > >possibility
> > >to create SWF, and I think that with time we can reach SWF and
> maybe other
> > >native platforms and that indepence of platform will be amazing.
> > >
> > >3.- Point 3 is important:
> > >
> > >
> > > 1. *Use MXML to create the DOM, use ActionScript to handle
> events, and
> > > use CSS to make it look good and useful.*
> > >
> > >I'd like to see how this resolves (still could not look at the
> code), but
> > >I
> > >think that should apply to actual ASJS, even if we deal with SWF,
> that
> > >should be the way things work for flash as for html.
> > >
> > >4.- View Beads, I think this is important. In actual UI sets we have
> > >"createElement" method that makes us to create the view (or at
> least the
> > >main part of it). In Button we add the html button tag or in jewel
> slider,
> > >the input range, and so on... this seems to me wrong since we have
> the
> > >concept of View Beads. I think all of that should be delegated to
> the View
> > >Bead and make possible for others to change the bead for another if
> they
> > >want/need. For example in themes, I was able to exchange view beads
> > >successfully and even in flex times I always designed the "visuals"
> in
> > >separate SWC that has the flex skins, code and css while in normal
> app
> > >libraries we had controllers, models, and app business logic.
> > >
> > >So could be enforce to instead of use "createElement" use a
> ViewBead? I
> > >think maybe at least in Jewel, since is an UI set very focused on
> visuals,
> > >and maybe Basic should not?...
> > >
> > >5.- for CSS and className point, need to see the code to see how
> much it
> > >shares with the actual way to handle that in Jewel.
> > >
> > >6.- In List the concept of having each data to be represented with
> > >different item renderers seems useful, I found that need some years
> ago in
> > >a couple of scenarios, if we don't support it in current List, we
> should
> > >
> > >7.- Panel. this flex component never was very needed for me, and I
> think
> > >is
> > >mainly to the way it enforce the layout in flex and the visuals.
> I'll be
> > >looking at it when I reach that in Jewel. I was thinking in using
> > >something
> > >more like an MDL Card, that seems to be what people needs nowadays
> and can
> > >replace the panel.
> > >
> > >Like the concept of interact with content. I think is the way to
> go. Panel
> > >is only a shell or chrome to layout and present contents.
> > >
> > >Don't like the concept of "leftItems" and "rightItems" since
> that's what
> > >a
> > >good sete of layouts should abstract for us without the need of the
> > >component to bake so closely to the component.
> > >
> > >8.- Date components are for me a very special component since in
> desktop
> > >apps and mobile apps it works very different. I think that point is
> > >crucial
> > >and at I'll want to make it possible in Jewel, and support easy
> ways to
> > >enter dates with masks. if input type date is the way to go in
> HTML, I'll
> > >try that way and look how is done in Basic and foundation to get
> started.
> > >Maybe if is still not in all browsers we should make it though a
> polyfill.
> > >Like in MDL and Jewel Alert that uses dialog polyfill, I plan in
> Jewel to
> > >use more of this like datelist that will bring us nicely
> possibilities at
> > >least in HTML, that will hard to replicate in SWF but as always
> doable in
> > >the future.
> > >
> > >9.- SVG still needs to come to SWF in some way to make it more
> usable in
> > >code. For me right now is only usable in CSS
> > >
> > >10.-
> > >
> > >
> > > - Make iFrames available as a component and somehow allow the
> loaded
> > >app
> > > to have access to the main app.
> > >
> > >
> > >
> > >Maybe that should be the foundation of modules??
> > >
> > >thanks
> > >
> > >
> > >
> > >
> > >--
> > >Carlos Rovira
> > >https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2
> > >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%
> > 7C504edc1f08664b84e96908d5a8
> > >efc7bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636600670158429860&sda
> > >ta=LwPBszdlzs23fvMaKGMVS1QcAlbArkN8lF4cLTlMV6o%3D&reserved=0
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7Cdc4f05bda11046a080cc08d5a9403d83%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636601015820603557&sdata=wIpwZLChBR%2BVN%2F3%
> 2FZd4rbYdnwbFi%2B%2Fy0J6BuB9uMicA%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About Peter's Royale Foundation
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, consistency is the killer of performance in many cases. Consistency is important in learning how something operates, so every car should have a steering wheel and a gas pedal to the right of the brake pedal in the US. And I sure wish cars could put the headlight switch in the same place.
But not every car needs the same engine. Most people don't need to know what is going on under the hood. In Royale, there are going to be a bunch of components that simply wrap an HTMLElement. No need to add the instantiation of a view bead there for consistency. As soon as that becomes a performance problem, we'd optimize it right back to being the way it is now.
For those who do need view beads, there might be better/faster ways of doing it than the current code. But it needs to be PAYG. And I think the way it works now is good enough. IMO, we are spending way too much time worrying about stuff that isn't nearly as important as getting emulation components running on the code we have now. Unless you are sure that folks will not be tempted to port Flex apps to Royale because they will care about whether all of our components have view beads, we should focus on creating the emulation components to prove that Alina can get an app migrated in 6 months. I think that will really attract folks. And that will help convince my management team that it is worthwhile to continue to contribute to Apache Flex and Apache Royale.
My 2 cents,
-Alex
On 4/23/18, 10:33 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
Hi Peter,
2018-04-23 14:20 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
> Thanks for this analysis, Carlos! I'll address just a couple of things:
>
> First, can you not see the code because of some issue with Github (did I
> forget to make it public) or is it just because you are too busy?
>
I can see it, I just comment that I couldn't still dive into it due to my
work schedule today...I'll take a look as I get time :)
>
> Secondly - view beads. I love the idea of separating them and I found it
> frustrating that a component might have a SWF view bead but not a JS view
> bead. And I originally wrote down in my notes that I would want everything
> to have view beads. But as I started to compose this, and overrode
> createElement() and made an input, then a button, then a span, it just
> seemed like making a view bead for the sake of making it. Plus there are
> issues of when to really know the right time to construct the parts. I
> don't think view beads are unnecessary; I think the concept needs tighter
> integration into the life cycle. Perhaps the strand loads the view bead
> and instead of relying on events, does viewBead.createElement() and calls
> on IBeadView API instead.
>
I like viewBead.createElement() you propose. The main class component
should never create anything of the view.
Let's see what Alex thinks about this
>
> Panel was something traditional from Flex. I think it might just
> old-fashioned now, but I also wanted to show how you could achieve the
> look of a Panel without having to proxy the content area. And as for
> left-items and right-items, I borrowed that concept from mobile apps that
> have navigation bars.
>
> Date controls - I think a polyfill is a good way to go. Just didn't look
> into writing one yet.
>
I'll be creating date controls soon in Jewel, and if I need polyfill I'll
do the same as we do in Alert-Dialog
>
> SVG: I wrote the SVG components mainly as a way to lay the groundwork for
> charts. But maybe the real way to do that is simply with the charts
> producing the bars and wedges and what-not and draw them using SVG
> specified in CSS. So many different possibilities!
>
since in Royale we'll need to deal with SWF, to handle good SVG we will
need AS3SVGREnderer library,
but that's difficult since I tried to put in contact with people I the
project and I didn't succeed but for the main contributor (Lucas)
>
> Again, thanks for taking the time to look at this.
>
>
Thanks you Peter for making this work. and again, hope you'll stay with us
as much as possible! :))
Carlos
> ‹peter
>
>
>
> On 4/23/18, 3:56 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi,
> >
> >I want to discuss some interesting things on Peter's Royale-foundation, or
> >things that make me thing about it:
> >
> >1.- One important concept I think is important is that he wants is point
> >1:
> >
> >
> >
> > 1. *Make a framework independent of Basic and Express but based on the
> > Core project work.*
> >
> >
> >With Jewel I want to do the same, at the end people using Jewel should not
> >need to have "Basic" dependency.
> >That's why we talked about moving UIBase to Core, but I think we have more
> >things on Basic that right now are needed and we should take a look to
> >what
> >things are.
> >
> >For example: Layouts. I'm creating my own CSS Layouts (still in the works
> >since I want to use mainly flex box). But Maybe I should not bake Jewel
> >Layouts in Jewel, but make it a separate library, and that should happen
> >the same in Basic and have "BasicLayouts" library.
> >
> >
> > 2.- For point 2 (focus on HTML/JS), I think is clear that right now is
> >our
> >main focus, even in Jewel for me, but I don't want to loose the
> >possibility
> >to create SWF, and I think that with time we can reach SWF and maybe other
> >native platforms and that indepence of platform will be amazing.
> >
> >3.- Point 3 is important:
> >
> >
> > 1. *Use MXML to create the DOM, use ActionScript to handle events, and
> > use CSS to make it look good and useful.*
> >
> >I'd like to see how this resolves (still could not look at the code), but
> >I
> >think that should apply to actual ASJS, even if we deal with SWF, that
> >should be the way things work for flash as for html.
> >
> >4.- View Beads, I think this is important. In actual UI sets we have
> >"createElement" method that makes us to create the view (or at least the
> >main part of it). In Button we add the html button tag or in jewel slider,
> >the input range, and so on... this seems to me wrong since we have the
> >concept of View Beads. I think all of that should be delegated to the View
> >Bead and make possible for others to change the bead for another if they
> >want/need. For example in themes, I was able to exchange view beads
> >successfully and even in flex times I always designed the "visuals" in
> >separate SWC that has the flex skins, code and css while in normal app
> >libraries we had controllers, models, and app business logic.
> >
> >So could be enforce to instead of use "createElement" use a ViewBead? I
> >think maybe at least in Jewel, since is an UI set very focused on visuals,
> >and maybe Basic should not?...
> >
> >5.- for CSS and className point, need to see the code to see how much it
> >shares with the actual way to handle that in Jewel.
> >
> >6.- In List the concept of having each data to be represented with
> >different item renderers seems useful, I found that need some years ago in
> >a couple of scenarios, if we don't support it in current List, we should
> >
> >7.- Panel. this flex component never was very needed for me, and I think
> >is
> >mainly to the way it enforce the layout in flex and the visuals. I'll be
> >looking at it when I reach that in Jewel. I was thinking in using
> >something
> >more like an MDL Card, that seems to be what people needs nowadays and can
> >replace the panel.
> >
> >Like the concept of interact with content. I think is the way to go. Panel
> >is only a shell or chrome to layout and present contents.
> >
> >Don't like the concept of "leftItems" and "rightItems" since that's what
> >a
> >good sete of layouts should abstract for us without the need of the
> >component to bake so closely to the component.
> >
> >8.- Date components are for me a very special component since in desktop
> >apps and mobile apps it works very different. I think that point is
> >crucial
> >and at I'll want to make it possible in Jewel, and support easy ways to
> >enter dates with masks. if input type date is the way to go in HTML, I'll
> >try that way and look how is done in Basic and foundation to get started.
> >Maybe if is still not in all browsers we should make it though a polyfill.
> >Like in MDL and Jewel Alert that uses dialog polyfill, I plan in Jewel to
> >use more of this like datelist that will bring us nicely possibilities at
> >least in HTML, that will hard to replicate in SWF but as always doable in
> >the future.
> >
> >9.- SVG still needs to come to SWF in some way to make it more usable in
> >code. For me right now is only usable in CSS
> >
> >10.-
> >
> >
> > - Make iFrames available as a component and somehow allow the loaded
> >app
> > to have access to the main app.
> >
> >
> >
> >Maybe that should be the foundation of modules??
> >
> >thanks
> >
> >
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%
> 7C504edc1f08664b84e96908d5a8
> >efc7bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636600670158429860&sda
> >ta=LwPBszdlzs23fvMaKGMVS1QcAlbArkN8lF4cLTlMV6o%3D&reserved=0
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdc4f05bda11046a080cc08d5a9403d83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636601015820603557&sdata=wIpwZLChBR%2BVN%2F3%2FZd4rbYdnwbFi%2B%2Fy0J6BuB9uMicA%3D&reserved=0
Re: About Peter's Royale Foundation
Posted by Carlos Rovira <ca...@apache.org>.
Hi Peter,
2018-04-23 14:20 GMT+02:00 Peter Ent <pe...@adobe.com.invalid>:
> Thanks for this analysis, Carlos! I'll address just a couple of things:
>
> First, can you not see the code because of some issue with Github (did I
> forget to make it public) or is it just because you are too busy?
>
I can see it, I just comment that I couldn't still dive into it due to my
work schedule today...I'll take a look as I get time :)
>
> Secondly - view beads. I love the idea of separating them and I found it
> frustrating that a component might have a SWF view bead but not a JS view
> bead. And I originally wrote down in my notes that I would want everything
> to have view beads. But as I started to compose this, and overrode
> createElement() and made an input, then a button, then a span, it just
> seemed like making a view bead for the sake of making it. Plus there are
> issues of when to really know the right time to construct the parts. I
> don't think view beads are unnecessary; I think the concept needs tighter
> integration into the life cycle. Perhaps the strand loads the view bead
> and instead of relying on events, does viewBead.createElement() and calls
> on IBeadView API instead.
>
I like viewBead.createElement() you propose. The main class component
should never create anything of the view.
Let's see what Alex thinks about this
>
> Panel was something traditional from Flex. I think it might just
> old-fashioned now, but I also wanted to show how you could achieve the
> look of a Panel without having to proxy the content area. And as for
> left-items and right-items, I borrowed that concept from mobile apps that
> have navigation bars.
>
> Date controls - I think a polyfill is a good way to go. Just didn't look
> into writing one yet.
>
I'll be creating date controls soon in Jewel, and if I need polyfill I'll
do the same as we do in Alert-Dialog
>
> SVG: I wrote the SVG components mainly as a way to lay the groundwork for
> charts. But maybe the real way to do that is simply with the charts
> producing the bars and wedges and what-not and draw them using SVG
> specified in CSS. So many different possibilities!
>
since in Royale we'll need to deal with SWF, to handle good SVG we will
need AS3SVGREnderer library,
but that's difficult since I tried to put in contact with people I the
project and I didn't succeed but for the main contributor (Lucas)
>
> Again, thanks for taking the time to look at this.
>
>
Thanks you Peter for making this work. and again, hope you'll stay with us
as much as possible! :))
Carlos
> ‹peter
>
>
>
> On 4/23/18, 3:56 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi,
> >
> >I want to discuss some interesting things on Peter's Royale-foundation, or
> >things that make me thing about it:
> >
> >1.- One important concept I think is important is that he wants is point
> >1:
> >
> >
> >
> > 1. *Make a framework independent of Basic and Express but based on the
> > Core project work.*
> >
> >
> >With Jewel I want to do the same, at the end people using Jewel should not
> >need to have "Basic" dependency.
> >That's why we talked about moving UIBase to Core, but I think we have more
> >things on Basic that right now are needed and we should take a look to
> >what
> >things are.
> >
> >For example: Layouts. I'm creating my own CSS Layouts (still in the works
> >since I want to use mainly flex box). But Maybe I should not bake Jewel
> >Layouts in Jewel, but make it a separate library, and that should happen
> >the same in Basic and have "BasicLayouts" library.
> >
> >
> > 2.- For point 2 (focus on HTML/JS), I think is clear that right now is
> >our
> >main focus, even in Jewel for me, but I don't want to loose the
> >possibility
> >to create SWF, and I think that with time we can reach SWF and maybe other
> >native platforms and that indepence of platform will be amazing.
> >
> >3.- Point 3 is important:
> >
> >
> > 1. *Use MXML to create the DOM, use ActionScript to handle events, and
> > use CSS to make it look good and useful.*
> >
> >I'd like to see how this resolves (still could not look at the code), but
> >I
> >think that should apply to actual ASJS, even if we deal with SWF, that
> >should be the way things work for flash as for html.
> >
> >4.- View Beads, I think this is important. In actual UI sets we have
> >"createElement" method that makes us to create the view (or at least the
> >main part of it). In Button we add the html button tag or in jewel slider,
> >the input range, and so on... this seems to me wrong since we have the
> >concept of View Beads. I think all of that should be delegated to the View
> >Bead and make possible for others to change the bead for another if they
> >want/need. For example in themes, I was able to exchange view beads
> >successfully and even in flex times I always designed the "visuals" in
> >separate SWC that has the flex skins, code and css while in normal app
> >libraries we had controllers, models, and app business logic.
> >
> >So could be enforce to instead of use "createElement" use a ViewBead? I
> >think maybe at least in Jewel, since is an UI set very focused on visuals,
> >and maybe Basic should not?...
> >
> >5.- for CSS and className point, need to see the code to see how much it
> >shares with the actual way to handle that in Jewel.
> >
> >6.- In List the concept of having each data to be represented with
> >different item renderers seems useful, I found that need some years ago in
> >a couple of scenarios, if we don't support it in current List, we should
> >
> >7.- Panel. this flex component never was very needed for me, and I think
> >is
> >mainly to the way it enforce the layout in flex and the visuals. I'll be
> >looking at it when I reach that in Jewel. I was thinking in using
> >something
> >more like an MDL Card, that seems to be what people needs nowadays and can
> >replace the panel.
> >
> >Like the concept of interact with content. I think is the way to go. Panel
> >is only a shell or chrome to layout and present contents.
> >
> >Don't like the concept of "leftItems" and "rightItems" since that's what
> >a
> >good sete of layouts should abstract for us without the need of the
> >component to bake so closely to the component.
> >
> >8.- Date components are for me a very special component since in desktop
> >apps and mobile apps it works very different. I think that point is
> >crucial
> >and at I'll want to make it possible in Jewel, and support easy ways to
> >enter dates with masks. if input type date is the way to go in HTML, I'll
> >try that way and look how is done in Basic and foundation to get started.
> >Maybe if is still not in all browsers we should make it though a polyfill.
> >Like in MDL and Jewel Alert that uses dialog polyfill, I plan in Jewel to
> >use more of this like datelist that will bring us nicely possibilities at
> >least in HTML, that will hard to replicate in SWF but as always doable in
> >the future.
> >
> >9.- SVG still needs to come to SWF in some way to make it more usable in
> >code. For me right now is only usable in CSS
> >
> >10.-
> >
> >
> > - Make iFrames available as a component and somehow allow the loaded
> >app
> > to have access to the main app.
> >
> >
> >
> >Maybe that should be the foundation of modules??
> >
> >thanks
> >
> >
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%
> 7C504edc1f08664b84e96908d5a8
> >efc7bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636600670158429860&sda
> >ta=LwPBszdlzs23fvMaKGMVS1QcAlbArkN8lF4cLTlMV6o%3D&reserved=0
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About Peter's Royale Foundation
Posted by Peter Ent <pe...@adobe.com.INVALID>.
Thanks for this analysis, Carlos! I'll address just a couple of things:
First, can you not see the code because of some issue with Github (did I
forget to make it public) or is it just because you are too busy?
Secondly - view beads. I love the idea of separating them and I found it
frustrating that a component might have a SWF view bead but not a JS view
bead. And I originally wrote down in my notes that I would want everything
to have view beads. But as I started to compose this, and overrode
createElement() and made an input, then a button, then a span, it just
seemed like making a view bead for the sake of making it. Plus there are
issues of when to really know the right time to construct the parts. I
don't think view beads are unnecessary; I think the concept needs tighter
integration into the life cycle. Perhaps the strand loads the view bead
and instead of relying on events, does viewBead.createElement() and calls
on IBeadView API instead.
Panel was something traditional from Flex. I think it might just
old-fashioned now, but I also wanted to show how you could achieve the
look of a Panel without having to proxy the content area. And as for
left-items and right-items, I borrowed that concept from mobile apps that
have navigation bars.
Date controls - I think a polyfill is a good way to go. Just didn't look
into writing one yet.
SVG: I wrote the SVG components mainly as a way to lay the groundwork for
charts. But maybe the real way to do that is simply with the charts
producing the bars and wedges and what-not and draw them using SVG
specified in CSS. So many different possibilities!
Again, thanks for taking the time to look at this.
‹peter
On 4/23/18, 3:56 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi,
>
>I want to discuss some interesting things on Peter's Royale-foundation, or
>things that make me thing about it:
>
>1.- One important concept I think is important is that he wants is point
>1:
>
>
>
> 1. *Make a framework independent of Basic and Express but based on the
> Core project work.*
>
>
>With Jewel I want to do the same, at the end people using Jewel should not
>need to have "Basic" dependency.
>That's why we talked about moving UIBase to Core, but I think we have more
>things on Basic that right now are needed and we should take a look to
>what
>things are.
>
>For example: Layouts. I'm creating my own CSS Layouts (still in the works
>since I want to use mainly flex box). But Maybe I should not bake Jewel
>Layouts in Jewel, but make it a separate library, and that should happen
>the same in Basic and have "BasicLayouts" library.
>
>
> 2.- For point 2 (focus on HTML/JS), I think is clear that right now is
>our
>main focus, even in Jewel for me, but I don't want to loose the
>possibility
>to create SWF, and I think that with time we can reach SWF and maybe other
>native platforms and that indepence of platform will be amazing.
>
>3.- Point 3 is important:
>
>
> 1. *Use MXML to create the DOM, use ActionScript to handle events, and
> use CSS to make it look good and useful.*
>
>I'd like to see how this resolves (still could not look at the code), but
>I
>think that should apply to actual ASJS, even if we deal with SWF, that
>should be the way things work for flash as for html.
>
>4.- View Beads, I think this is important. In actual UI sets we have
>"createElement" method that makes us to create the view (or at least the
>main part of it). In Button we add the html button tag or in jewel slider,
>the input range, and so on... this seems to me wrong since we have the
>concept of View Beads. I think all of that should be delegated to the View
>Bead and make possible for others to change the bead for another if they
>want/need. For example in themes, I was able to exchange view beads
>successfully and even in flex times I always designed the "visuals" in
>separate SWC that has the flex skins, code and css while in normal app
>libraries we had controllers, models, and app business logic.
>
>So could be enforce to instead of use "createElement" use a ViewBead? I
>think maybe at least in Jewel, since is an UI set very focused on visuals,
>and maybe Basic should not?...
>
>5.- for CSS and className point, need to see the code to see how much it
>shares with the actual way to handle that in Jewel.
>
>6.- In List the concept of having each data to be represented with
>different item renderers seems useful, I found that need some years ago in
>a couple of scenarios, if we don't support it in current List, we should
>
>7.- Panel. this flex component never was very needed for me, and I think
>is
>mainly to the way it enforce the layout in flex and the visuals. I'll be
>looking at it when I reach that in Jewel. I was thinking in using
>something
>more like an MDL Card, that seems to be what people needs nowadays and can
>replace the panel.
>
>Like the concept of interact with content. I think is the way to go. Panel
>is only a shell or chrome to layout and present contents.
>
>Don't like the concept of "leftItems" and "rightItems" since that's what
>a
>good sete of layouts should abstract for us without the need of the
>component to bake so closely to the component.
>
>8.- Date components are for me a very special component since in desktop
>apps and mobile apps it works very different. I think that point is
>crucial
>and at I'll want to make it possible in Jewel, and support easy ways to
>enter dates with masks. if input type date is the way to go in HTML, I'll
>try that way and look how is done in Basic and foundation to get started.
>Maybe if is still not in all browsers we should make it though a polyfill.
>Like in MDL and Jewel Alert that uses dialog polyfill, I plan in Jewel to
>use more of this like datelist that will bring us nicely possibilities at
>least in HTML, that will hard to replicate in SWF but as always doable in
>the future.
>
>9.- SVG still needs to come to SWF in some way to make it more usable in
>code. For me right now is only usable in CSS
>
>10.-
>
>
> - Make iFrames available as a component and somehow allow the loaded
>app
> to have access to the main app.
>
>
>
>Maybe that should be the foundation of modules??
>
>thanks
>
>
>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com%7C504edc1f08664b84e96908d5a8
>efc7bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636600670158429860&sda
>ta=LwPBszdlzs23fvMaKGMVS1QcAlbArkN8lF4cLTlMV6o%3D&reserved=0