Perfect. I think we did a great job on the css part of this discussion. Let’s see if we ca come to a meeting of the minds on the rest. :-)
Let’s try and figure out what we all agree and don’t agree on. The important pieces I see are: 1. How do we define what is “Core"? 2. Should package names match the project names? 3. Do we care to try and make package names shorter (i..e limit the level of folders)? 4. What are the advantages and disadvantages of making Basic a dependency for other component sets? 5. A question which might follow the ones above are whether we should add a new package. I’d rather wait to discuss this until we have some clarity on the ones above. Can you think of any other questions we should be asking ourselves? Thanks, Harbs > On May 29, 2018, at 4:41 PM, Carlos Rovira <carlosrov...@apache.org> wrote: > > Hi, > > completely. > > two things: > > 1. I propose in the new Discussion thread to make that work myself, but we > can do together. I think the best way is to rename and move things in > chunks so we make this in various steps, testing builds not break, and so > on....this will take some days to reach a good shape. > 2. I already said my work was totally incomplete. But as we need this > discussion I didn't do more but fixing build. > > > 2018-05-29 15:13 GMT+02:00 Harbs <harbs.li...@gmail.com>: >> >>> 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%7Cfa7b1b5a7b34438794aed2c178de >> cee1%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%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W% >> 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0> >> > > > > -- > Carlos Rovira > http://about.me/carlosrovira
