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
