Hi Alex, great document. I read it all and think it's very clear and of great help. Some points I notice:
* In Subclassing when you talk about "final". I think like you, and maybe you talk about that so I mentioned. a TLC can be extended but use to be for aggregation of specialization purposes. What I use to refer with "final" is that it would be strange to subclass a component of a TLC to get one similar from other TLC, due to different natures, but this can still be done. * Exploded Component:This should be really great, but I think in components and I think is difficult for most of them. Think in a TextButton, if you exploded in UIBase and its beads, you'll not have text or html properties. About your email, mostly agreed. In point 2), less dependencies is not a major goal, is completely ok, and the example of "commons" is perfect to our case. I think aligned to most of what you said here. Thanks 2018-05-15 8:29 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > Hi, > > I'm finding this thread to be hard to follow. It seems to be focusing a > lot on mixing what I call "top-level components" from more than one > component set, which is a valid scenario, and exposes some valid bugs, but > I'm not sure how often it will be used. I also think there is some > leftover "Flex" thinking going on and some terms are being used that I'm > not clear what they are. > > It occurred to me that could be because we don't really have a good > document on what the key terms and concepts are for Royale framework > development, so I tried to write up such a document in the wiki. Our new > contributors could probably use such a document regardless of this issue. > The link is here [1]. Consider it a draft, and not final. But if we're > lucky it may help settle this debate. The key takeaway: > Top-Level-Components (TLCs) are different from other classes in the SWCs. > They are almost like examples. This is different from Flex. Components in > one component set have no obligation to subclass TLCs from other component > sets. > > A few other comments: > 1) I'm pretty sure we could require that typenames are fully qualified > names. I'm pretty sure the CSS generator knows the package name. I would > recommend doing that to allow mixing of TLCs from different component sets > since that is guaranteed to be unique and is known to the tooling. It does > mean longer strings in the CSS output though. > 2) Fewer dependencies still doesn't seem like it should be a major goal so > it isn't in the document I wrote. Code reuse is usually the higher goal. > When I think about the projects I've worked on, the focus has always been > on code reuse. That's why Apache Commons and even AS3Commons are popular. > Most folks choose to use those libraries instead of writing their own > version of what those libraries do. Fewer dependencies comes into play > when you have choices. If there are two libraries that implement, say a > Sort algorithm you want to use and you are already using one of those > libraries for other things, you'd probably choose to use the Sort from the > library you already have. > 3) Similarly, Apache Commons and AS3 Commons aren't delivered as one giant > JAR or SWC. Our beads should be organized into different SWCs as well. > 4) Concerns about breakage by subclassing ancestor classes is a valid > concern, but that generally doesn't keep people from subclassing. Instead, > we use testing to verify changes to the ancestor classes. Really, probably > all of us on this mailing list made the same bet about breakage by using > the Flex framework. In any next version of Flex or even Flash, something > could change and break your app. That's why we have tests and preview > periods. > > In short, think of many of our SWCs (Core, Binding, Collections, Basic) > like Apache Commons or AS3Commons. > > I'm pretty much done for tonight. I'll see if I made things better or > worse when I start my day tomorrow. > > HTH, > -Alex > > [1] https://github.com/apache/royale-asjs/wiki/Terminology-and-Concepts > > On 5/14/18, 10:35 PM, "carlos.rov...@gmail.com on behalf of Carlos > Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> > wrote: > > Hi Harbs, > > 2018-05-14 23:37 GMT+02:00 Harbs <harbs.li...@gmail.com>: > > > So, we are saying the same thing. > > > > This will not work: > > j|Button > > { > > border: 5px solid black; > > } > > > > But this will: > > .jewel.button > > { > > border: 5px solid black; > > } > > > > That’s what I meant when I said the user must know the default > classnames > > that Jewel uses. > > > > I consider this to be a problem. (Not a catastrophic one, but one > I’d like > > to avoid if possible.) > > > > One of the features of Royale is that qualified CSS can be used to > > describe application defaults for types. This applies to beads as > well as > > styling. With the Jewel (and MDL) architecture, beads are described > using > > namespaced classes, while HTML css is described using whatever > (different) > > classnames are defined. One of the features of namespaced classes in > CSS is > > that it’s checked by the compiler and tooling can take advantage of > that. > > By using custom class names, we lose that. > > > > I understand why this compromise was reached, but can we agree that > it’s a > > compromise and not the ideal way to solve the problem? If we could > make > > j|Button{} work, wouldn’t that be better? > > > > > Right, but take two considerations: > > a) UI sets like MDL (BootStrap, Semantic,...) will never could be > done in > that way, since you must to follow the way that external library > works. Or > in other words you must to adapt to the given css unless you want to > rework > the external CSS (s). > > b) Depending on solution, that could be very verbose, so that should be > considered. > > on the other hand that would be good solution to avoid styles reach > final > App if the user doesn't use a concrete component, then the compiler > should > not bring it to the final CSS from the theme CSS > > Carlos > > > > > > Thanks, > > Harbs > > > > > On May 14, 2018, at 7:25 PM, Carlos Rovira < > carlosrov...@apache.org> > > wrote: > > > > > > I'll give you working examples that I tried for this so you can > test > > > yourself if you want: > > > > > > To affect all buttons with *html css*, you do this (for example in > main > > > App.mxml file (you can try this in JewelExample): > > > > > > <fx:Style> > > > @namespace j "library://ns.apache.org/royale/jewel > <library:// > > ns.apache.org/royale/jewel>"; > > > > > > .jewel.button > > > { > > > border: 5px solid black; > > > } > > > </fx:Style> > > > > > > > > > <j:Button text="hi!"/> > > > > > > you'll see all buttons with a black border of 5 pixels. overriding > the > > > normal Jewel Button border. > > > > > > Instead if you want to change something at "bead level" you must > use the > > > component name. For example: > > > > > > j|TitleBar { > > > IBeadLayout: ClassReference( > > > "org.apache.royale.jewel.beads.layouts.VerticalLayout"); > > > } > > > > > > will make *Alert* display things in tittle vertical instead of > > horizontal. > > > (notice that to see the effect you need to add something more to > > > AlertTitleBarBiew like this: > > > > > > <j:Label text="hi"/> > > > > > > Since by default there's only a label so you will not see the real > > effect. > > > > > > and must comment in AlertView this line (130) > > > titleBar.addBead(new HorizontalLayoutSpaceBetween()); > > > that override the concrete behavior of the standard TitleBar for > Alert > > and > > > expose the one in css for general TitleBar. > > > > > > Why this happens? Is simply how compiler works. I see it a lot > natural > > and > > > for that reason styles in Jewel are organized in the actual way: > beads > > are > > > in the Jewel library since it wire the default behavior and html > css > > styles > > > are in themes since the things we want to change mostly. > > > > > > Other themes could mix both, and as I tried and exposed, override > beads > > in > > > themes is supported that seems a very powerful feature to explore > in the > > > future. > > > > > > I worked a lot on organization, I think where you put things > (library), > > > packaging and naming is all important, even method signatures are > vey > > > important since is what users will be using finaly, so making this > as > > > simple as possible but flexible is our main focus. > > > > > > Hope this clears all better :) > > > > > > > > > 2018-05-14 17:43 GMT+02:00 Harbs <harbs.li...@gmail.com <mailto: > > harbs.li...@gmail.com>>: > > > > > >> I think we have zeroed in on the point of 1a. Great! :-) > > >> > > >> I don’t understand what you mean here. I don’t understand how > component > > >> styles could be assigned. > > >> > > >> To be clear I mean something like this: > > >> > > >> <js:Application xmlns:fx="https://na01. > safelinks.protection.outlook.com/?url=http%3A%2F%2Fns. > adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=FxFpEVp00FvoeV5tN% > 2Fw05Ufr3I8Is0piFEs6FxojJvU%3D&reserved=0 < > > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=FxFpEVp00FvoeV5tN% > 2Fw05Ufr3I8Is0piFEs6FxojJvU%3D&reserved=0> < > > >> https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=FxFpEVp00FvoeV5tN% > 2Fw05Ufr3I8Is0piFEs6FxojJvU%3D&reserved=0 <https://na01.safelinks. > protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com% > 2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=FxFpEVp00FvoeV5tN% > 2Fw05Ufr3I8Is0piFEs6FxojJvU%3D&reserved=0>>" > > xmlns:js="library://ns.apache <library://ns.apache>. > > >> org/royale/basic <library://ns.apache.org/royale/basic > <library:// > > ns.apache.org/royale/basic>>" > > >> xmlns:j="library://ns.apache > > <library://ns.apache>. > > >> org/royale/jewel <library://ns.apache.org/royale/jewel > <library:// > > ns.apache.org/royale/jewel>>"> > > >> <fx:Style> > > >> @namespace "https://na01.safelinks. > protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org% > 2F1999%2Fxhtml&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=KxkNtF6nXu7nBjr1V5fhCQtl% > 2FJVKA6iGyeczEgp1pMw%3D&reserved=0 < > > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=KxkNtF6nXu7nBjr1V5fhCQtl% > 2FJVKA6iGyeczEgp1pMw%3D&reserved=0> < > > >> https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=KxkNtF6nXu7nBjr1V5fhCQtl% > 2FJVKA6iGyeczEgp1pMw%3D&reserved=0 <https://na01.safelinks. > protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org% > 2F1999%2Fxhtml&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=KxkNtF6nXu7nBjr1V5fhCQtl% > 2FJVKA6iGyeczEgp1pMw%3D&reserved=0>>"; > > >> @namespace svg "library://ns.apache.org/royale/svg > > <library://ns.apache.org/royale/svg> > > >> <library://ns.apache.org/royale/svg <library://ns.apache.org/ > royale/svg > > >>"; > > >> @namespace j "library://ns.apache.org/royale/jewel > > <library://ns.apache.org/royale/jewel> > > >> <library://ns.apache.org/royale/jewel <library://ns.apache.org/ > > royale/jewel>>"; > > >> > > >> j|TextButton > > >> { > > >> padding-top:10px; > > >> } > > >> </fx:Style> > > >> </js:Application> > > >> > > >> Are you saying that this will work? If yes, please explain how. > > >> > > >> Thanks, > > >> Harbs > > >> > > >>> On May 14, 2018, at 5:26 PM, Carlos Rovira < > carlosrov...@apache.org > > <mailto:carlosrov...@apache.org> > > >> <mailto:carlosrov...@apache.org <mailto:carlosrov...@apache.org > >>> > > wrote: > > >>> > > >>>> > > >>>> 2. Client code cannot declare default CSS in their app for all > Jewel > > >>>> components of a specific type. In other words > > j:Button{background-color: > > >> blue} > > >>>> will not work because a Jewel Button does not have a “Button” > class > > >> name. > > >>>> > > >>> > > >>> No. That would work. You can check in Jewel "sass" folder where > all > > >>> components define the css that links beads and classes. > > >>> In that case we don't have anything for Button at this time, but > most > > of > > >>> the rest have declarations like j|{Component} and beans assigned. > > >>> Then mostly all html styles are in themes in the styles that are > as you > > >>> already notice "jewel {component}" > > >> > > >> > > > > > > > > > -- > > > Carlos Rovira > > > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=h8Gaodrdvy1hwXtjbVv1IYArPKYiH4 > ypZqQZPdL%2BcGs%3D&reserved=0 <https://na01.safelinks. > protection.outlook.com/?url=http%3A%2F%2Fabout.me% > 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=h8Gaodrdvy1hwXtjbVv1IYArPKYiH4 > ypZqQZPdL%2BcGs%3D&reserved=0> > > > > > > -- > Carlos Rovira > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C79bedd805d964128efaf08d5ba259c06%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636619593058778449&sdata=h8Gaodrdvy1hwXtjbVv1IYArPKYiH4 > ypZqQZPdL%2BcGs%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
