Sorry for my delayed response to all of this. I’ve been kind of out of it…
Can we try and get clear on the problems? I’d really like to figure out what we agree on before we try to nail down a solution. I’d like to start with Alex’s list: > First, the hopefully easy things we can agree on: > -I have no objection to dropping "Bead" off of bead class names > -I have no objection to moving all views into a view subfolder as long as > nobody else is concerned about the size and performance issues. > -I have no objection to moving classes in Basic that are > org.apache.royale.html to org.apache.royale.basic. > -I have no objection to doing a massive rename and long as it isn't me doing > the work. > -Whatever is in Core and Basic now or before Carlos's started moving things > around is not perfect. I agree with this completely. Carlos, do you agree as well? (I would be willing to help out with a rename, but I want to make sure it doesn't cause too much disruption. Thanks, Harbs > On May 23, 2018, at 12:43 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > Hi Carlos, > > I guess I don't understand why separating beads from TLCs is better. How > will that make things better for users or other component set developers? > That would effectively double the number of SWCs and each TLC SWC will need > its bead SWC. That doesn't sound like a good thing to me, but if that's what > other folks want to do, that's fine with me. > > I was just looking through the classes in Jewel. It looks like JeweL doesn't > have a DataGrid yet.. When it does, I would think you will want to use the > DataGridModel from Express as it handles both Arrays and ICollectionViews. > We will probably create a similar model bead that takes both ICollectionViews > and Arrays for Lists and put that in Express as well. Then we might decide > that is better for Jewel to use that model instead. Or maybe we'll decide to > create a JewelExpress set that has those more general models that don't > require as much configuration. Anyway, I hope you agree that at some point, > these more general models will be used by Express and some flavor of Jewel. > I don't think this general model should go in Core, or Basic (or some new > category called Foundation). And at that point, Jewel or JewelExpress is > going to re-use that code in Express. > > Component sets are encouraged to re-use existing code from any other SWC > since I think we've agreed that re-use is important. > > My 2 cents, > -Alex > > On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com > <mailto:carlos.rov...@gmail.com> on behalf of Carlos Rovira" > <carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com> on behalf of > carlosrov...@apache.org <mailto:carlosrov...@apache.org>> wrote: > > Hi Alex > > what do you think about separating the part in Basic that is inherently the > same as in Jewel (Button, CheckBox, TextInput, List, ...) along with CSS > that wire the beads for Basic UI set, and left the fundamental building > blocks as something that is not Core but can be reused by Basic and Jewel > (Let's call this "Foundation" Lib, I even like this name for this library). > > I mean that having "Foundation" lib and "Basic" lib, will be more clear, > since we can expect what is in Basic will be never reused to build other UI > Sets (MDL, or others can still hang from there or if someone wants to take > the time refactor it). > > Foundation will not have any CSS wiring beads. We can return classes from > Core to Foundation. > > Basic will have its own CSS wiring beads, the same for Jewel. Both will > requiere Core and Foundation. > > I assume this will make all of us happy. > > We can as well do the package name changes to ensure consistency along all > code and libraries. > > Let me know what do you think > > thanks > > Carlos > > > 2018-05-21 19:38 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > >> I understand this isn't the latest post on this thread, but it is the >> easiest one for me to reply to: >> >> First, the hopefully easy things we can agree on: >> -I have no objection to dropping "Bead" off of bead class names >> -I have no objection to moving all views into a view subfolder as long as >> nobody else is concerned about the size and performance issues. >> -I have no objection to moving classes in Basic that are >> org.apache.royale.html to org.apache.royale.basic. >> -I have no objection to doing a massive rename and long as it isn't me >> doing the work. >> -Whatever is in Core and Basic now or before Carlos's started moving >> things around is not perfect. >> >> Now for the less easy. Regarding Core vs Basic, I see it this way: Basic >> is the simplest implementation of the constructs/concepts in Royale. It is >> intended to be extended and enhanced by other component sets via our PAYG >> principles. Core is intended to identify the constructs/concepts and their >> fundamental contracts. >> >> Think of it this way: When you open any class in Royale, you will want to >> know what kind of class it is. It is a TLC, a Bead? And what kind of TLC >> or Bead? Is it View, Model, Controller? An ItemRenderer? These are the >> categories of classes we had, even in Flex. I've probably left out a few >> categories. It is the interfaces for these categories that go in Core. >> And maybe some classes we think are universal implementations of those >> categories. And some beads that are component set agnostic, like >> BrowserResizeHandler, although we could move those to another SWC and say >> that Core should not have any MXML components except maybe State. >> >> After any rename/refactor we decide on, Basic should still have some >> interfaces because those interfaces describe the contract required for the >> simplest implementation. I get that it can be a fine line between >> "fundamental" and "simplest", but where many classes that were in Basic get >> away from "fundamental" is mainly around Containers. The way we handle >> Containers in Basic really seems like an opinion instead of a universal, >> "everyone must implement Containers this way" sort of thing. So it does >> not seem right that lots of Container-related things were moved to Core. >> >> I thought we had agreement on the Terminology and Concepts thread that >> re-usable pieces would be organized into multiple SWCs like Apache or AS3 >> Commons. Any component set designer gets to choose what SWCs to borrow >> from. The emulation SWCs may borrow from Express because they want to >> re-use multi-purpose beads and aren't interested in the smallest, fastest, >> implementation. Assuming we fix any issues with accidentally dragging in >> classes that aren't used, if you can re-use code from some other group of >> classes in another SWC, just do it. But do it because you "want to". >> There is no "need to". The implementers should "want" to re-use code when >> possible. >> >> In the end, many component sets will re-use Basic beads. Maybe even >> transitively because they re-use Express which re-uses Basic. That should >> be ok. That doesn't make it Core. It just that lots of component sets >> will start from simple implementations and add more complex functionality. >> The goal is to minimize code size and maximize performance by re-using >> code. And as I thought we had agreed upon in Terminology and Concepts, we >> should not be afraid to re-use code. We are asking our users to do exactly >> the same. We must create testing infrastructure and have review periods >> and other processes so we don't break downstream component sets or our >> users applications. >> >> One related tidbit: IMO, the way folks will know what beads work with >> what components will be done by identifying what interfaces the beads >> implement, but also, I expected that we would use ASDoc as well. If you >> rummage through the source, you'll see that I annotated a few classes with >> @viewbead and @toplevel. We could add more. And because our ASDoc is an >> app, we can then apply smarter filtering that help folks narrow down what >> their choices are, similar to many of the online shopping filters I see. >> >> My 2 cents, >> -Alex >> >> >> On 5/21/18, 3:53 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >> Thank you for this. >> >> There’s two groups of files that were changed: Interfaces and and >> Classes. >> >> In general, I would be more inclined to move interfaces than classes, >> but there are some things to consider: >> >> 1. There are still 17 interfaces in Basic. If the 5 that were moved >> belong in Core, what about the remaining 17? >> 2. I don’t think we’ve come to an agreement on what belongs in Core >> and what belongs in Basic. >> 3. I’d like to some to an agreement on a package name pattern. What >> defines something belonging to a “core” path as opposed to an “html” path? >> Some classes are in supportClasses and some had that removed from the path. >> What’s the logic? etc. >> 4. How should different pieces (such as different bead types) be >> defined in paths? (I don’t think we’re completely consistent today.) >> >> I think we are coming to a conclusion on the CSS issues that Jewel >> brought up. I think the CSS problems can be solved no matter whether we >> move things between packages and no matter wether we change package paths. >> I think the question on reorganization needs to be discussed on its own >> right. Do you agree with that? >> >> First organization of packages: >> To me, there are two primary questions related to Core vs. Basic: >> 1. What is the defining criteria for something to belong in Core as >> opposed to Basic? >> 2. Is there an issue with one component set (i.e. Jewel) to rely on >> another (i.e. Basic). >> >> To be clear: I do believe that there is likely some reorganization >> appropriate, but I’m not clear on exactly what and how. >> >> Depending on the answers to these questions, we can have a number of >> different courses of action. We might keep things very similar to how they >> are. We might move things from Basic to Core. We might split Basic into two >> packages. Other options? >> >> Regarding package paths: I don’t think there’s a single “right” answer >> to that, but we do need to agree on a pattern that we all stick to. >> Currently (even before any refactor) package paths feel like many are >> haphazard, and I often have difficulty guessing what the path is for a >> specific class. I also sometimes have difficulty guessing which package a >> specific class belongs to. >> >> These are the high-level questions I have. >> >> Please allow me to focus on question #2. I find it easiest to discuss >> concrete examples, so I’m taking TextPrompt, but it’s just an example. >> Basic has a TextPromptBead. Jewel has TextPrompt. The code of the two >> classes are identical. I’m assuming TextPrompt was copied because >> TextPromptBead does not belong in Core (something I agree with), and you >> did not want Jewel to have a dependency on Basic. So my question is >> (assuming CSS and classes not used are not copied), what is wrong with >> Jewel using the TextPromptBead in Basic? To me the advantage of using the >> Basic bead is that there’s no code duplication and that helps from a >> development perspective (i.e. only a single place to fix bugs) and from a >> perspective of code size in the resulting application (in case both classes >> are used somewhere). >> >> Harbs >> >>> On May 21, 2018, at 11:29 AM, Carlos Rovira <carlosrov...@apache.org> >> wrote: >>> >>> Hi, >>> >>> as we talked I take the time to make a list of package name changes. >>> Finally 20 classes were changed from package. >>> Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e879811 (in >> red the >>> changes to better following) >>> >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/MXMLBeadView.as >>> >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html >>> /MXMLBeadView.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/views/ContainerView.as >>> frameworks/projects/Basic/src/ >> main/royale/org/apache/royale/html/beads/ContainerView.as. >>> (1) >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/views/DataContainerView.as >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ >> html >>> /beads/DataContainerView.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/GroupView.as >>> >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html >>> /beads/GroupView.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/IBackgroundBead.as >>> frameworks/projects/Basic/src/ >> main/royale/org/apache/royale/ >>> html/beads/IBackgroundBead.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/IBorderBead.as >>> >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html >>> /beads/IBorderBead.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/IDropDownListView.as >>> frameworks/projects/Basic/src/ >> main/royale/org/apache/royale/html >>> /beads/IDropDownListView.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/IListView.as >>> >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ >> html/beads/IListView.as. >>> (2) >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/ITextFieldView.as >>> frameworks/projects/Basic/src/ >> main/royale/org/apache/royale/ >>> html/beads/ITextFieldView.as (2) >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/TextFieldViewBase.as >>> frameworks/projects/Basic/src/ >> main/royale/org/apache/royale/html/beads/TextFieldViewBase.as >>> (2) >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/layouts/LayoutChangeNotifier.as >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html >>> /beads/layouts/LayoutChangeNotifier.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/models/ArraySelectionModel.as >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html >>> /beads/models/ArraySelectionModel.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/beads/models/ViewportModel.as >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ >> html >>> /beads/models/ViewportModel.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/supportClasses/Border.as >>> frameworks/projects/Basic/src/ >> main/royale/org/apache/royale/ >>> html/supportClasses/Border.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/supportClasses/ContainerContentArea.as >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ >> html/supportClasses/ContainerContentArea.as. >>> (2) >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/supportClasses/DataGroup.as >>> frameworks/projects/Basic/src/ >> main/royale/org/apache/royale/html/supportClasses/DataGroup.as >>> >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/DataItemRenderer.as >>> >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ >>> supportClasses/DataItemRenderer.as (3) >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/MXMLItemRenderer.as >>> >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ >>> supportClasses/MXMLItemRenderer.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/UIItemRendererBase.as >>> >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ >>> supportClasses/UIItemRendererBase.as >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/supportClasses/Viewport.as >>> frameworks/projects/Basic/src/ >> main/royale/org/apache/royale/html >>> /supportClasses/Viewport.as >>> >>> Some comments: >>> >>> (1) "views" should follow the same package structure we have with >> other >>> beads 8"models", "controllers"...) to be consistent. >>> (2) should go to "core/beads/views" as well >>> (3) item renderers that should normaly be used by final users could >> go some >>> kind of "itemRenderers" package, while base item redeemer classes >> could go >>> again to supportClasses. >>> >>> As Harbs said, if we agree in the change of packages, we should do >> this >>> well and perform some other changes that make all more consistent >> though >>> libraries. >>> >>> Thanks >>> >>> Carlos >>> >>> >>> >>> >>> 2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com>: >>> >>>> Definitely a plan. >>>> >>>> My guess is that if we agree on changing package paths, there will >> likely >>>> be other classes that should be considered. >>>> >>>> My preference would be to have this discussion after we finish the >> project >>>> refactor discussion because I think it’s going to be related to the >> outcome >>>> of that. >>>> >>>> Either way, I don’t think discussion should hold up the 0.9.3 >> release. >>>> We’re already past due for a release. We want to “release early and >> release >>>> often”… ;-) >>>> >>>> Thanks, >>>> Harbs >>>> >>>>> On May 17, 2018, at 12:07 PM, Carlos Rovira < >> carlosrov...@apache.org> >>>> wrote: >>>>> >>>>> Ok, >>>>> >>>>> what if: >>>>> >>>>> * I take the time to generate a list of classes with package name >> changes >>>>> * Make a thread with the list to expose it >>>>> * Let's see from there if people can live with it (We'll call >> people to >>>>> express about this changes and could see if are or not dramatic to >> them) >>>>> >>>>> Sounds this like a plan? >>>>> >>>>> Thanks >>>>> >>>>> >>>>> >>>>> 2018-05-17 10:58 GMT+02:00 Harbs <harbs.li...@gmail.com>: >>>>> >>>>>> Sure. Same here. >>>>>> >>>>>> But things are much more stable now. As we move closer to “1.0”, >> I think >>>>>> we should be more careful about breaking changes and documenting >> them >>>> when >>>>>> we decide they are necessary. >>>>>> >>>>>> As far as these specific changes go: We haven’t even come to a >>>> conclusion >>>>>> on what (if any) package names should change yet, and including >> those >>>>>> changes in a release is premature. If we do change package names, >> I’m of >>>>>> the opinion that they should be decided on and all happen at once >> to >>>>>> minimize impact on end-users. >>>>>> >>>>>> Does that help clarify things? >>>>>> >>>>>> Thanks, >>>>>> Harbs >>>>>> >>>>>>> On May 17, 2018, at 11:49 AM, Justin Mclean < >> jus...@classsoftware.com> >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> We are at the point where people are using Royale in >> production. While >>>>>> we can make breaking changes if they are warranted, they should >> be kept >>>> to >>>>>> an absolute minimum and be carefully considered and well >> documented if >>>> we >>>>>> do. >>>>>>> >>>>>>> There has been many previous breaking changes that broke the >>>> application >>>>>> I was working on and some more major than this and cost me a lot >> of >>>> time to >>>>>> fix. Until you make it version 1.0 I think people will expect >> that some >>>>>> things may break with a new version. So why should this be an >> exception >>>> to >>>>>> what has happened before? Saying that however, what would be good >> to >>>> see is >>>>>> to provide guidance to what users need to change so their app >> works with >>>>>> any changes / backward compatibility issues. >>>>>>> >>>>>>> Thanks, >>>>>>> Justin >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Carlos Rovira >>>>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636624967805497091&sdata=bdXVzZzjutIIwP9lWwAjosfP3JsQDt >> rkTp%2FcrETCLE4%3D&reserved=0 >>>> >>>> >>> >>> >>> -- >>> Carlos Rovira >>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636624967805497091&sdata=bdXVzZzjutIIwP9lWwAjosfP3JsQDt >> rkTp%2FcrETCLE4%3D&reserved=0 >> >> >> >> > > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W%2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0 > > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W%2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0>
