royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <>
Subject Re: About Peter's Royale Foundation
Date Mon, 23 Apr 2018 12:20:48 GMT
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.


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

>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. *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
>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
>main focus, even in Jewel for me, but I don't want to loose the
>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
>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
>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
>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
>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
>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
>   - Make iFrames available as a component and somehow allow the loaded
>   to have access to the main app.
>Maybe that should be the foundation of modules??
>Carlos Rovira

View raw message