This makes a lot of sense to me. I think that if we’re going to do this, the time to do so is now.
I’m willing to help with this reorganization. Harbs > On Nov 1, 2017, at 3:33 PM, Peter Ent <[email protected]> wrote: > > I'm glad you brought this up. I've been giving some thought to refactoring > Royale into more logical components. We've done this before, but I think > some refinement is in order before we could have a 1.0 release that would > make sense to the general public. I think streaming and moving things > around will make it easier for people to find things. I've flattened out > the package structure a bit, opting for more packages than a deeper tree. > I'm also just concentrating on a few a the projects and packages; for the > most part the others seem ok to me with minor clean-up. > > There's a saying that goes, "it is easier to criticize than create" so I > put this up for your thoughts and suggestions. > > Here's what I'm thinking (these are package paths, not frameworks/projects > directories): > > royale.core: contains only interfaces and maybe a handful of concrete > classes. This package would be the interfaces common across all > frameworks/projects like IBeadModel. It would also contain the "engine" > that builds the structure but that could be in its own package as well. > > royale.events, royale.utils, etc found in the current Core project would > remain almost as-is unless some clean up is needed. > > royale.html: contains only classes that correspond to HTML DOM elements. > This is the HTML project right now. > > royale.html5: contains only classes that correspond to the HTML5 DOM > elements. These are in the HTML5 project right now. > > royale.basic: contains the foundation for the user interface frameworks > and can be used in its own right. The components here provide minimal, > common functions and can be extended with a set of beads and models. > > royale.basic.models: contains the models used by royale.basic components. > > royale.basic.views: contains the views used by royale.basic components. > > royale.basic.controllers: contains the controllers used by royale.basic > components. > > royale.basic.layouts: contains the layouts used by royale.basic components. > > royale.basic.beads: contains the non-visual/non-model beads used by the > components. These would include the dataProvider beads, the accessor > beads, etc. > > royale.basic.supportClasses: contains additional components used by the > main components, such as itemRenderers and data groups. > > I thought that having the deeper nesting of models, etc. was too heavy. > > royale.composite: (new) contains "more than basic" components such as > DataGrid, Accordion, and some others that are composed of basic elements > and not necessarily used in every application and they have more complex > code structures. It would lighten the basic package as well. This > royale.composite package would have sub-packages similar to basic: > royale.composite.models, royale.composite.views, etc. > > > Food for thought, > Peter > > > > On 11/1/17, 4:13 AM, "Harbs" <[email protected]> wrote: > >> Right now the vast majority of Royale classes are under >> org.apache.royale.html. >> >> It seems odd to me that the default package path for basic components are >> under html. It feels like html should really be reserved for classes >> which really belong in html (such as HTML elements and the like). >> >> I¹m not sure it¹s worth the effort of changing it even if it *is* weird, >> but I wanted to bring it up. >> >> Additionally, I don¹t think there¹s enough clarity on which classes >> belong to org.apache.royale.core and which ones belong to >> org.apache.royale.html. >> >> Harbs >
