I think the namespaces would probably stay the same. We currently have the following namespaces and I don’t see a need to change them:
library://ns.apache.org/royale/basic library://ns.apache.org/royale/svg library://ns.apache.org/royale/express library://ns.apache.org/royale/flat library://ns.apache.org/royale/mdl library://ns.apache.org/royale/cordova library://ns.apache.org/royale/google library://ns.apache.org/royale/createjs Harbs > On Nov 1, 2017, at 3:56 PM, Piotr Zarzycki <[email protected]> wrote: > > Hi Guys, > > Just quick question if I will have this package: "royale.basic.beads" - > What will be the namespace for it ? If I would like to add from that > package some components ? > > Piotr > > > 2017-11-01 14:42 GMT+01:00 Harbs <[email protected]>: > >> 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 >>> >> >> > > > -- > > Piotr Zarzycki > > mobile: +48 880 859 557 > skype: zarzycki10 > > LinkedIn: http://www.linkedin.com/piotrzarzycki > <https://pl.linkedin.com/in/piotr-zarzycki-92a53552> > > GitHub: https://github.com/piotrzarzycki21
