I'll be opening a [Vote] thread on Monday so we can decide upon this if we must to revert changes.
Thanks 2018-05-12 10:09 GMT+02:00 Carlos Rovira <[email protected]>: > Hi, > > I'm trying here to explain with more tools the problems we had until now > and the solution I did he past Friday. > > Disclaimer: This solution doesn't intend to end in the current state, and > we can evolve to get other shape more convenient for others in this > project. I'm sure Alex or Harbs can add up to enhance what I did greatly as > always do. > > So let's go: > > Until now we had this kind of relation between libraries : > > https://snag.gy/JqO2ZI.jpg > > In this schema. Basic is needed always to construct an Application. That > causes that all applications will end aggregating the used styles of the > CSS in basic and all the classes that are linked in that way plus the tree > of dependent classes. > > Until now that wasn't a problem, since we didn't care of it. That extra > size all applications incorporated was not in out target since we only had > Basic to construct applications. A side case was MDL but as is a "wrapper" > around an external library, again we didn't care too much about this. > > Now with the new Jewel UI set, we have another UI set that although is > based in the work in Basic is a first citizen, so for example, a Button in > Jewel extends UIBase and not basic Button like before. So changes in Button > or in other Basic infrastructure classes not affect Jewel at all. So > final/leaf components are dependent of UIBase (in Core) and not anything we > have in Basic. The same happens with Jewel TextInput, Jewel Slider, and > more. > For example Jewel Slider is based on input range, while Basic Slider is > build with two buttons. So even ISlider interfaces are different in Basic > than in Jewel. > So key point here: final implementations should not depend one from > another since any changes in the code of the parent will affect the > children. > > As you can see in the schema, we have various libraries that are top > level, some of them are optional, and for this reason are separated in > library units (Network, Binding, Collections, and more), but Core is not > optional, must be in all Royale Applications. > > Basic until now although it was a concrete final implementation of an UI > set, was in fact needed in all Royale Applications, and that cause that > always its CSS and its classes was baked into the final App. Only if you > don't use visual elements you'll get rid of basic need, but that in a front > end app is very strange right? > > This design caused from the begging lots of problems that started to rise > when I first started MDL library. We have styles and behaviours that was > not required due to the presence of unwanted CSS and classes from Basic. > > So for this reason a key point is that we need to bake into final app the > resources we really need to avoid unwanted content that is not required and > only increases size and the presence of potential bugs and not wanted > behaviors. > > With the refactor we get to the following graph > > <https://snag.gy/JqO2ZI.jpg>https://snag.gy/KW36yn.jpg > > Now in the final picture, we don't have the presence of all the things > that comes with Basic when we create a Jewel application, the final > developer don't need to be worried of any unwanted behavior that comes from > Basic since Jewel no more requies it. > > But this is completely compatible with the older scenarios. People using > Basic, will use it I the same way and get exactly the same. So this > refactor doesn't break existing applications. > > Since I moved classes from Basic to Core to be as DRY as possible, but I > changed from package (from "html" to "core") to improve organization, that > change can make final applications need to update those namespace, like I > had to do in all the examples we have. This is something that should not > make a huge task more than a few minutes, but something normal when a > refactor is done. There's few refactors that does not implies changes in > final applications. This change of packages really is not needed, but I > think is convenient to get a better organization. Now we have still core > packages in Basic and html packages in Core, what makes things a bit messy > and shows that still we need some API changes and cleaning. Normal since we > are on 0.9.3 version. > > A special case is HTML, where is the only real code change I introduced > (99% was only move code from Basic to Core to allow get rid of Basic). > I changed NodeElementBase to extend UIBase, due to Harbs proposal. Then > Yishay saw that it wasn't allowing nesting, so I changed again to extend > Group. And to get this Group needs to be in Core. In other way HTML will > depend on Basic and anytime we'll create a Jewel application that uses > HTML, this library will bring Basic with all known problems (CSS and > Classes not wanted). > > All this changes, make the build broke and show some deficiencies . Some > HTML was linking Basic, Basic was a inherited dependency that was not > declared in many examples pom. So now we have all poms fixed with the real > dependencies, if the example uses Basic, it will have Basic, if not, it > will be not present at all. > > Some others classes were copied "temporaly" to Jewel. For example > MultilineLabel, was copied from Basic to Jewel. The final step is to remove > that component since in Jewel I don't want a MultilineLabel, but a bead > that makes Jewel Label to be multiline. So this that is not DRY in some > days it will be since I'll be removing that temporal control. I only copied > there to allow all examples build right. As many refactors things doesn't > end at the beginning it then requires more steps to be done. The important > thing was to left all the code building ok at that time, then start to use > things in this new way for Jewel, since Basic is all the same > > Finaly all this changes, not only make the app developer not worried about > how to not collide with Basic styles and functions, but makes Jewel Royale > Applications 40% less sized than before. > > I think I cover all points, If I remember something I didn't tell you > here, I'll be adding more email. > > At this point, you can see that technically is very important due to avoid > unwanted code in final apps, unwanted behavior, reduce size, and avoid > final developers to be confused by other similar structures present that > they don't need (CTRL+SPACE will only throw one kind of Button now instead > different implementations). > > As well the current refactor still makes posible to mix libraries if the > developer wants to do it. He can add Basic dependency to a Jewel > Application if the still needs something and want to pay all the extra size > and behaviors of the basic linked code. > > Things that we can do to improve more this scenario: > > 1.- extract GroupBase functionality to Core so Group (in Basic) and > NodeElementBase (in HTML) can compose t > (this will improve DRY) > > 2.- I think we have a good organization regarding libraries now (Core - > Network - Binding, and then UI Sets, Basic, MDL, Jewel,...) > But maybe folks would be feel better with other organization. > For me the only thing I need is that whatever solution we want doesn't > force people to link Basic as if it was a Core library since it's not, is > only a final implementation of controls and components) > > 3.- I think if we find more Core functionality in Basic we could pass it > to Core, I think we still have Core things in Basic. As is normal since I > suppose people made things to make it work, but maybe is time now to "clean > the house" a bit after all this time and see where things should go. The > fact that we have core package in Basic and html package in Core is a clue > that things are not still in right positions. > > > We must separate *needed* things from *architectural* things. For me > *needed* is : > > 1) not need Basic dependency since Jewel really doesn't need it!, and > don't want users to link things that only generate problems linking styles > and classes that make final developers to fight with fonts, or colors, that > they don't know how are appearing and why. And don't want extra classes > linked that could bring errors very difficult to find and solve. And > finaly, don't want extra size in apps since that extra size comes with only > undesirable effects in the final application. > > just that > > Some of the points I expose are not needed, but would enhance the quality > of the code and people trying to use it. Now we have still a bit messy set > of packages. We can move things so all people here would have things set up > as they want. > > Some of you can propose other ways to get to the same, but I'm afraid that > in essence it will be mostly the same. But I'm totally open to bring more > ideas and to change things, since I'm sure my solution is not 100% > infallible, and there's many ways to do things. > > My proposal is that since I solved many structural things in how projects > and examples build, fixing poms that where not having Basic declared and > more things that were arising during the refactor, I think is better to > make the refactors other will propose from the actual point. And that would > be more easy to follow. > > Hope that now all is more clear thanks to new explanation and graphs and > that you consider that we really have real problems to solve and that now > are solved, although maybe not in the best way but in a valid way and that > I'm open to change things while taking into account that we at least > maintain the same improvements I get with this changes. > > Thanks in advance. > > > -- > Carlos Rovira > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
