I agree, the namespaces can remain. The packaging is more for logic/organization to make it easier to get into the code. Right now I scroll through several projects trying to find something in the .html package and it could be in several places. So if have something in DragDrop project, it probably should be in the org.apache.royale.dragDrop package somewhere. That can still make to the basic namespace or we can move the code into the Basic project but into the dragDrop package.
―peter On 11/1/17, 10:02 AM, "Harbs" <[email protected]> wrote: >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: >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linke >>din.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cb2624dd11e1149b9cd4708d5213128e >>4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636451417380641991&sdata=B >>t%2FEus3HN2Ha6CRup%2FiWatRATp2K6MvjnpTjBkcfyu0%3D&reserved=0 >> >><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl.link >>edin.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%7C01%7C%7Cb2624dd11e1149b >>9cd4708d5213128e4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364514173 >>80641991&sdata=YzxdiDa2zZ8etKJcCRV25u0IM29zNhokvGMNbbGVciI%3D&reserved=0> >> >> GitHub: >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c >>om%2Fpiotrzarzycki21&data=02%7C01%7C%7Cb2624dd11e1149b9cd4708d5213128e4%7 >>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636451417380641991&sdata=fDTE >>jLi5G2KNubKsEUe%2FK7S1ZgODVXV5Qs8LfuzAYuo%3D&reserved=0 >
