Hi Om, 2018-05-13 9:11 GMT+02:00 OmPrakash Muppirala <bigosma...@gmail.com>:
> It took a while for me to catch up on the series of threads on this topic. > From what I see, on a high level, https://snag.gy/KW36yn.jpg seems to be a > better setup than https://snag.gy/JqO2ZI.jpg. That is , Jewel must extend > from Core and not extend Basic. > > Ideally we would follow these sets of principles: > > 1. Backwards compatibility is important. > Even though Royale is very early in its development cycle, there are apps > using Royale in the wild. If Basic component set is refactored, the > expectation should be that current apps should not break. There is a > reason we use Semver. An upgrade from 0.9.2 to 0.9.3 should NOT break > existing contracts and APIs. > > That's essential, and for this reason I put many hours to get Basic doesn't be affected since in that case the problem would be huge and clearly not an option. If I change for example how Basic Button works, that would be unacceptable. The only thing that really caused problems was that some classes changed package, and this means update imports in every application using that classes. I thought that is acceptable if we want to better organize APIs. I said previously that seems confusing to have core packages in Basic and html packages in Core. For me even now, after refactor, the package structure seems confusing. But for me this part is not essential at all, since is something we can live on. Although I think people here should be predisposed to this "package location changes" in our path to 1.0. After 1.0, I consider we can't do this, so this should be something very convenient to schedule. > 2. Royale should be more flexible. > I understand the strong viewpoints some folks have about Royale. But what > good is an SDK with which we cannot easily build component sets. Carlos > has been involved in building two completely different component sets (MDL, > Jewel) along with other things. If he is raising concerns about the > framework, we all need to listen to him. It doesn't matter if no one else > agrees with him. I think he has earned enough credit here to voice his > opinion however unpopular it may be. > > That's essentially the issue. I'm doing a work that almost no others do, so one thing is theory and other put in practice. The later is failing in some points since the beginning and should be more easy for me or for others to address the issues without making such noise. > 3. DRY is not that important. > Again, given where we are with Royale's maturity, we must expect more of > such complex changes. Insisting that we always need to be DRY leads to > more rigidity while building up the SDK. Let folks like Carlos who are > trying out new things some leeway. Once the main goal is achieved we can > go back and figure out the best way to keep things DRY. > I think what's important is PAYG. I as well think that I'm supporting DRY since if I copy a file is since I want to modify it, or is an implementation of a Core functionality (is the same that "Application" class in all UI Set libraries. But what we can extract from Om point is far more important that the actual case: At this point we have a real good foundation, but we need to get it as real and usable as possible, or will have the less used better technology in the world. If we put so many brakes, we are making people abandoning and going Angular (for example). There's lots of things to improve in Royale, and we can't loose the time in some particular thing, if people working does his work right and is careful in no breaking things. If that's not the case, instead of a solution is a problem. Thanks for you thought Om, very appreciate. Carlos > > Thanks, > Om > > > > On Sat, May 12, 2018 at 1:09 AM, Carlos Rovira <carlosrov...@apache.org> > wrote: > > > 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
