Hi, I tried to make a diagram that summarize all what was discussed before, making it more easy for others that already diconnect from the other threads, since we wrote a lot in the last few weeks.
I think we already discussed a lot about all this points. It's clear for all that changes are needed. I think we all agree in this point right?. So the following image shows all problems of the older setup. We are in our way to 1.0 and I think is very (very) important to solve all this problems, since as we get 1.0 then changes will need to be less about structuring and organization and more about bug fixing, improve all that we already have, bring new things under the same umbrella, but all under a well-stablished structure and organization. Here's the diagram that hope help you all to understand the problems and why the new structure should help to solve all off them: https://snag.gy/DbH4iG.jpg In this version we get: * The main idea here's : "*CSS in UI sets can link undesirable code and introduce both more size (Kbs) and unwanted behavior in our Final application*. *We should add a new Royale Framework design rule: CSS files should be always optionaly, and not imposed by framework*. Left it to our users choose what UI Set want to use and by choosing the UI Set they are choosing to use its CSS files and so compiling them into the application. Avoid obligation that an UI Set extend other and linkage of libraries make *all* Royale applications process CSS files in intermediate UI Sets that will introduce lots of problems." (Notice that CSS files here, in Royale, refer to both normal css rules, and configuration of beads via CSS) In this way people that wants to use Jewel don't need to deal with things considered in Basic, and viceversa. MDL and CreateJS are currently depending on Basic, and that could be continue as is or not, this is not a requirement right now, and a viable way supported in this change. Express is the only US Set that will need to depend from Basic since is an *aggregation* of Basic and does not have sense without Basic. Jewel will never use controls, components and CSS in Basic, so no need to make it depend from it, only from the common pieces that all UI Sets need. * Foundation library proposal that makes all shared beads and classes be available to all UI Sets (This is something already proposed by Harbs, so nothing new here), this means move this pieces from Basic and some that was moved to Core to this new library Foundation). * This all is based in the concept that all UI sets are equal and no one need the other since there's no obligation imposed by Royale as a framework. We don't want this obligation, since brings no benefits at all, the opposite is better since brings more flexibility and power to Royale and their users. * Despite the latest point, users can optionally use one or more UI Sets if they want. We left that to their chooice. * Proposed set up is more flexible for the future. When we'll plan a majo version, that will happen some day (v2.0, 3.0...), that include major changes and make actual code base be compromised, we can start a new UI Set that makes more easy the transition while making the current one to continue working as expected for current users. This is maybe the major point to discussed since I think we need to solve in order to go forward. We as well talked about making the final package name changes, that I think we are all synced here, so only mention since is part of the required changes to get 1.0: * Make sure packages and names are consisten all over Royale * beads namespaces are not consistent (some beads are in "models", while, views are directly in beads, and more...) * Remove "Bead" ending from beads to make it all less verbose. * take a look at final namespaces to be as well consistent all over Royale. I offer my time to make this happen. Thanks -- Carlos Rovira http://about.me/carlosrovira
