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 >>> http://about.me/carlosrovira >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira
