royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: About Peter's Royale Foundation
Date Mon, 23 Apr 2018 17:44:44 GMT
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

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,

On 4/23/18, 10:33 AM, " on behalf of Carlos Rovira" <
on behalf of> wrote:

    Hi Peter,
    2018-04-23 14:20 GMT+02:00 Peter Ent <>:
    > 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! :))
    > ‹peter
    > On 4/23/18, 3:56 AM, " on behalf of Carlos Rovira"
    > < on behalf of> 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
    > >
    > >Fcarlosrovira&
    > 7C504edc1f08664b84e96908d5a8
    > >efc7bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
    > 7C636600670158429860&sda
    > >ta=LwPBszdlzs23fvMaKGMVS1QcAlbArkN8lF4cLTlMV6o%3D&reserved=0
    Carlos Rovira

View raw message