I find I very often have to open the entire asjs repo so I can search for a specific class.
> On Nov 1, 2017, at 4:55 PM, Peter Ent <[email protected]> wrote: > > 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] > <mailto:[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 >>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linke> >>> din.com >>> <http://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 >>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl.link> >>> edin.com >>> <http://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 >>> <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
