I’m responding to this email because it has the most points I want to respond to.
I’m pulling out the particular quotes that I think are most relevant to the discussion. > >> 2. A “base” component set to use (or partially use) for composition. >> > > Take into account that Jewel does not subclass any component in Basic. MDL > should not do it, since extend a control from basic really does not bring > it nothing. I did in that way since at that time I was young in creating UI > sets, but I never was completely happy of that way. But, again, both models > make possible to extend a set and create a new one from that point, but > yours make that mandatory, so for me less flexible. I don’t understand what you mean by less flexible. I think it’s more so. You say that Jewel is not using Basic, but I don’t see that. I work much better with concrete examples, so let me try: 1. Jewel currently has 8 model classes which are copies from Basic. Models should be component set agnostic and if we need to copy them from one component set to another, we’re doing something wrong. These models should be either in Basic or some other “Foundation” lib. 2. Controllers. I think you copied controllers as well. Controllers might also be in a “foundation” lib, but that “feels” like less of a good fit. 3. Beads. Right now, the only bead I see is TextPrompt. I don’t see any reason to copy that. It’s also dependent on the implementation of the component set, so putting that in “foundation” does not feel right. 4. Right now, Jewel does not have many composite components, so there’s very little in terms of components that it can use from Basic. However, as that is built out, I think it will make more sense to use Basic components. Most of the Basic components are built with separate views. This is very important for the more complex ones. I’m going to focus on a few specific components to try and make my point. a. List. Even a component such as List seems like it would make more sense to use the Basic one. The only reason I can see to use a different class is to prevent basic List css and to set the correct typeNames. The actual appearance of the list is handled by the view which should likely be different in Jewel. How can we use a Basic List? Possibly we will be able to improve the compiler to be smarter about how it pulls in CSS. Possibly we should have a ListBase which contains almost all the code and the List in each component set subclasses that. b. ComboBox. Right now combobox is a bit broken architecturally. I’m working on fixing it, but it’s conceptually a composite component containing a button, a component which displays the selected item and possibly take input, and a List for the dropdown. Ideally, different component sets should use the ComboBox component as-is, and specify different components for the pieces of the view. c. DataGrid. Rebuilding the entire DataGrid hierarchy for separate component sets seems very wasteful and error-prone. The visuals of the data grid should just be declared and reuse existing pieces of the (Jewel) component set. To me, the primary problem with creating a “Foundation” lib is that it’s going to be very difficult to decide what goes in there. It feels like it will lead to less organization instead of more. It’s also a lot of work and I don’t see any gain. > >> 3. A logical place to put shared beads. >> > > This is resolved with "Foundation" library. Finaly we'll be doing the same, > using a common library that reuse beads. Agreed. But I’m trying to understand what the advantage of a new library is over just keeping Basic. I’m still not understanding you on this point. >> >> What is gained by removing that dependency? >> > > Well, while both versions brings the same benefits, as I tried to respond > in the responses to that 3 points, I think separate beads and coming code > in Foundation makes Royale more flexible. I talk about this several times, > and I think advantages are clearly shown in the schema image, but I'll try > to summarize it again: > > What improvements we get? (I'm supposing we have Foundation library with > beads and common code previously in Basic, and some now in Core, and think > that Basic ui set for me is only the controls and components and the css, > not the beads and code that will be in Foundation) We already finished discussing the CSS issues. I thought we all agreed that there are bugs there that need to be fixed. I completely agree with you that Jewel should not suffer inflation because of Basic. If we fix the bugs in Basic I don’t think it will. > 1.- Without Basic, or any mandatory UI sets, we remove the processing of > the CSS beads file that is part of every UI set. This is critical, since > far beyond compiler bugs, we don't want our app to process a file that wire > a lots of beads, since the right bead file to process is only the UI Set > the user wants to use. > 1.a-If you want to use Jewel, but declare first Jewel and then Basic, > Basic setup wins over Jewel, and this shows clearly that this is nothing > good. > 1.b- This introduces, unwanted content, increase size, and is a hole of > possible problems that we are creating for free. This one solely is huge > one. > 2.- We as well remove the processing of CSS html rules, that are equally a > generator of free problems. These three are all bugs. I agree that we need to fix this, but I don’t think it’s an argument to change the lib structure. > 3.- Something that comes clearly as you think more in it... why make Jewel > dependent of Basic if Jewel don't extend any Basic component? As I explained above, I don’t think this is (or should be) true. > 3.a- If we continue thinking in that, why we are separating in libraries > if we finaly link all? If we link all, then we should join Core, Basic, > Jewel, Binding, Network, and so on… Good question. For me, the primary reason to have separate projects is compilation speed while working on the framework. The larger the code base gets, the longer it takes to compile and the heavier it is on IDEs. By breaking the framework into smaller projects, that allows for partial compilation and only opening a single smaller project in an IDE at a time. > 4.- Separation is good since this make framework developers try to use the > logical pieces they have. In the current way, we'll tend to mess things > since we have lots of pieces available and can take the easy way. I don’t understand what you mean here. > 5.- The new dependencies is more flexible: we can use Jewel, and at a time, > use Basic if we want, is up to the user to choose it, and that's more > powerful that make them link a Basic UI Set that maybe he doesn't want use > never I keep hearing more flexible, but I don’t understand how and why. No one is forced to use any specific part of Basic. It’s there to take what's needed and ignore the rest. > 6.- Why make an UI Set principal over the others? what have Basic over > Jewel, or the opposite? Those are the same, but we have more than one since > are designed with different goals in mind, so there's no point on make one > link another (and again more over when the new one doesn't use any single > class from the parent). That's for me clearly useless. No. Basic is a “base” component set designed to have its pieces used by other component sets or directly by application developers. You don’t need to use *all* of Basic, but you are almost guaranteed to use *some* of Basic. Jewel is/was already doing that before you tried to separate pieces out. If we implemented things right, there should be no tax by making Basic a dependency. > 7.- Future major versions: Some time in the future we'll want to create > v2.0. As happen with many other projects (think for example in Flex with > v1.0, 2.0, 3.0, 4.0) each major release implies dramatic changes. If you > change from Java 5 to 6, 7, 8, 9...or Spring framework from 2.0, 3.0, > 4.0...you know what I'm talking about. So for Royale this dependency design > makes us more flexible and capable to make a 2.0, 3.0, and so on without > affect 1.0 in a hard way, so our users will be less affected and will be > able to upgrade in a more easy way. I completely lost you here. What is the difference whether you call the dependency Foundation or Basic? > 8.-Because as I said before, we have the same benefits than before, but now > we have many more. While in the other way we are less flexible, more rigid > and that's worse for Royale. > > I think this is the major point of discussion we have, and hope that all > points exposed will be sufficient to show the benefits and advantages of > the dependencies. For me the major point > is that we should not have any library in the tree of dependencies that has > a CSS wiring beads, and that library is mandatory in all Royale > applications. I think that's the main point of problems > and we should fix it. that should be a rule "Mandatory libraries in a > royale application can't have a CSS that wire code (beads)", for that > reason, that part of Basic (controls, components and CSS should be in > their own library Basic.swc, and the reusable code be in a common library > that the rest can use (i.e: Foundation.swc) It seems that your main point comes back to CSS. If we can’t fix the bugs related to the CSS, then I completely agree with you. We can’t have Basic CSS causing lots of classes and CSS to be included in apps for no good reason. However, I think those bugs are very fixable. I’d also like to comment on this: >> - As Harbs is saying, and I said earlier, Core is intended to be >> implementation-agnostic and identify the parts/roles in the framework. >> Basic beads, especially the Container beads, are a specific implementation, >> knowing that SWF and JS are the outputs. Who knows what will be required >> in the implementation of component sets for other outputs. >> > > I'm as well aligned with this. This is ok with the new dependency of > libraries I think we have a disconnect here. Let’s take UIBase for example. UIBase has a lot of opinions on how things should be implemented. It gets its children from HTML nodes. It assumes that layout parents are not necessarily the immediate ones. It makes assumptions on what events need to be dispatched. etc. I don’t think that UIBase and friends belong in Core. In fact not every IUIBase even currently in the app are UIBase subclasses. IUIBase belongs in Core because it defines the function of a IUIBase. UIBase does not because it makes implementation assumptions. Thanks, Harbs
