royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: About Peter's Royale Foundation
Date Tue, 24 Apr 2018 15:38:29 GMT
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 <aharui@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 <pent@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
    

Mime
View raw message