Hi Carlos, Comments inline.
> > 4. Methodology: Royale should not impose linking of libraries, other that > Language, Test and Core. I think yes. Alex and you think no. We both agree that Jewel should have a dependency on “Foundation” or “Basic”. The only question is TLCs. What practical difference does this point have? > >> >> I’d like to propose the following way forward. >> >> 1. Both Basic (Foundation) pieces and Basic TLCs should have the same >> package paths and namespaces. >> > > Don't think so. If you want to promote reusable pieces, the refactor of > names should make them go to a different package other than Basic. It's > like to propose to put on a jewel package would be a bad decision. In the > refactor I was for "core", since the common pieces was in Core. So I think > it will depend on the name of the library to choose. For me Basic is a good > name for Basic UI Set since clearly states what all the code there do. I > still think Foundation is a good name, but if you don't like, I think you > should propose other one that seems more appropriate. I really don’t care very much what the project name is. “Base” “Basic” and “Foundation” are all good. To me they all mean the same thing. I’d prefer to stick with Basic because I don’t see a gain in renaming it. Foundation is a “long” name. I don’t see a reason to make the name longer. I feel very strongly that the TLCs should have the same paths and namespaces as the rest of Basic. I consider Basic TLCs a part of the Basic concept. Even if Jewel doesn’t end up using it, other component sets likely will. Creating a new package path and namespace serves no function and makes things more difficult. Why go there? > >> 2. By doing this, it will be very painless to pull Basic TLCs out of Basic >> into a separate project or merge it back in. (i.e. BasicComponents) (Either >> now, or in the future.) >> > > I think we must be doing it moving little by little and ensuring after a > little refactor all continues working. Moving what? I don’t think moving the entire list of TLCs (i.e. what is used in the Basic CSS) is more than a few hours of work. > >> 3. Give Alex and me an opportunity to fix all issues and demonstrate that >> there will be no tax by making Basic TLCs a dependency. >> > > Here we have a problem. I think we need to fix things and that should make > many problems are gone. But although the problems are gone, we have a > different approach in how to build Jewel components for you Jewel Button > extends Basic Button, for me Jewel Button extends UIBase... how can we > overcome it? > For me your option is less flexible than mine, and I give you many > arguments, while I don't see any arguments in favor of making Jewel extend > Basic TLCs > I think that's the problem here. I think I understand your arguments, but it does not feel like you understand mine. I think that by actually doing the work, the arguments will become clearer. Again: I’m *not* proposing that Jewel should extend *all* of Basic TLCs. I’m suggesting that it’s appropriate for it to extend *some* of them. I think time will show whether I’m right or wrong. What is the harm in letting time tell who’s right? > >> 4. Let’s complete Jewel and see wether there is a reason to use the >> TLCs/CSS. >> > > But, in my previous email I said that If I want to continue working in > Jewel components I need to continue moving things to a library shared. Basic *is* that shared library. To prevent linking to Basic (TLCs), we can move the Basic TLCs out of Basic *at any time*. I don’t see why we need to *do anything* right now (except get everything working for a release). Jewel apps might be slightly larger for a month or two until we get this sorted out, but what’s the rush? > So to complete since I don't consider the option of linking Basic how can I > perform the completion? Coming code to Jewel? Is not an option for any of us > Moving to Core? I think we are still discussing what to do. I only can > create Foundation lib and move there, while keeping the same in Basic > temporarily and link Foundation > to Jewel. > > If you have some additional way to do this that not implies link Basic let > me know. Just consider Basic “Foundation” and ignore all the TLCs for the time being. If it’s the right thing to move the TLCs out, we can do that later. > >> 5. Let’s do research on whether CSS processing during compilation is an >> issue and try and figure out our options if it is. >> > > Imagine you get to fix bugs and fix current CSS so you get rid of all the > current problems....Then you prefer to continue in the same way that > already was clearly problematic, and will bring more problems later? don't > understand why...when you have a simpler and better way that is removing > the dependency and it's the most easy and quick way and will preserver the > integrity always in the future. Because I don’t think that removing the dependency is the right thing to do. Again, whether I’m right or wrong will become clearer as Jewel gets completed. If I’m wrong, I’ll be happy to pull out the Basic TLCs myself. > >> 6. If we can’t make all the pieces of Basic truly optional, I’ll help you >> pull the Basic TLCs and CSS out into a separate project. >> >> > Ok, my only concern here is how to do this plan, since I see many problems > that only can be making just what I can avoid. What problems do you envision that are stopping the 0.9.3 release? Can we get things working for the release and then take it from there? I’m working on getting rid of all the class selectors which are bringing Basic pieces into Jewel. Please give me a chance to finish this work. Thanks, Harbs
