Hi, Just respond to that part.
"Moreover, in the IDE if you hit CTRL+SPACE, when using Jewel, do you want to see 5-6 Button references off all linked UI sets? I don't think so I want the IDE to be quick, and to show only what I chooses, the Jewel Button, an not lots of options that I don't choose." You will always see all Buttons in IDE VSCode and Moonshine because you are pointing whole SDK. You won't avoid that part. No matter whether you have Basic or not in Jewel. However we will have in VSCode and Moonshine prefixes j:Button, js:Button. Thanks, Piotr On Wed, May 30, 2018, 1:32 PM Carlos Rovira <carlosrov...@apache.org> wrote: > Hi Harbs, > > 2018-05-30 11:49 GMT+02:00 Harbs <harbs.li...@gmail.com>: > > > 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. > > > > Right, that should go to Foundation, not Basic, for all the models to > share, others are now copies, but not in the future. Take into account that > right now I did some copies just to put in place things, but this > disscussion makes me stop my development flow. > > > > 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. > > > > Right > > > > 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. > > > > Right...so you see know the problem, don't understand why you want we pass > all through Basic...you're describing the problem in your own words :? > > > > 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. > > > > ok , you're proposing another different direction that is not the old one > nor the current one. It could be valid, but I already discussed this with > Alex about 1-2 months ago. > For example, components has a createElement that is part of the main > component class, then we have a view. For Alex, the createElement use to be > sufficient in Basic and most of time if creates (in HTML) a tag. In Jewel > we use to need some html tags to create the desired visuals. So, what you > propose is another valid way: Not have component sets, but only one and > then "decorate" it with different view beads. So a CheckBox in basic will > use a simple input while in jewel the view will be composed of about three > tags. > > In that case, with only one set, and here's a key point, we need the CSS as > well not to be in the component set (the CSS that wires all beads) but in > an optional library for this to work. So people that wants Jewel visuals > will take the library that has that CSS and people that want Basic will > choose a different library. > > Take into account that both ways always will requiere not to have a > madatory CSS for beads in the dependency. > > > > > > > > > >> 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. > > > > If Basic is the shared lib, it can't have the CSS that wires beads. I put > this in many places and mails. *CSS can't go in a mandatory shared > library*. > So since CSS must to be stripped out, I think a better naming is to left > Basic to have CSS and extract the foundation part to Foundation, since the > name "Foundation" seems > to me far accurate for code that you can reuse and Basic seems very > accurate for a component set that do the most basic representation. > > But again the key point here is that CSS of Basic should never be > mandatory. > > > > > > >> > > >> 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. > > > > Even if you get bugs fixed, you are making all royale application to > process a useless CSS...why? This doesn't have sense at all. > But as I said *if you fix the bugs*...since you are introducing the > possibility to introduce unwanted behaviors or size and things difficult to > debug...and all this for free. > There's no reason at all, technically spoken to impose that obligation, I > only see problems in that setup. > > > > > > > 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. > > > I think this is responded in my latest paragraph: although we fix bugs, it > makes no sense the compiler to pass over a not required CSS, that is > totally useless and there's no point in that. > > > > > 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. > > > > Right, but this is in fact how is designed. Or at least after go the other > route (that was what I choose like you at first glance), my experience says > that is better the current one > > > > > > > 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. > > > > > right > > > > 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. > > > > > So not having all UI Sets linked, that are not used is better right? > > Moreover, in the IDE if you hit CTRL+SPACE, when using Jewel, do you want > to see 5-6 Button references off all linked UI sets? I don't think so > I want the IDE to be quick, and to show only what I chooses, the Jewel > Button, an not lots of options that I don't choose. > > So this is, less error prone, IDEs work faster, you work faster since don't > have options you'll never use. > > But as well you have the option to link a new UI Set if you want at that > cost... so clearly more flexible. > > > > > > > 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. > > > > Is just what I responded in the last few sentences. > > > > > > > 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. > > > > When I work with other technologies, I don't link all libraries available, > only what I use. In Royale is the same, if you don't want to use Binding, > you don't link it...so why I need to link Basic if I don't want to use it? > > > > > > > 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. > > > > Right, The problem is that Basic mixed until now the reusable pieces and > the pieces that make Basic an UI Set and that has replacement in other UI > Sets, so +1 to reuse (maybe about 70-80% of Basic, but -1 to the obligation > to link unwanted controls (Button, Slider,...) from basic and its CSS. I > repeat that Jewel will not use it, and try to make this mandatory seems to > me not the best way to go. Think that the proposed way makes all your needs > possible, the old way, makes an obligation that I think has many problems > as I stated clearly and through lots of emails and explications. > > > > > > > 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? > > > > To make you understand, I'll try to make an example with Flex: As Flex > grows from flash mx to 2004 to Flex 1.0 to 1.5 it was sharing the same > principles and then for 2.0 all changed (new player...)...then comes 3.0, > 3.5 and finaly 4.0. So finaly we have MX and SPARK. It was a point where > was impossible to make more changes to MX base and a new set of components > was created with spark. So, I think Royale will evolve with what we have > for some years, and then new needs or technological improvements will come > Maybe incoming webasm? don't know, What I tried to say is that is more easy > to create a nee UI Set library as a sibling of Basic, Jewel, ... lets call > it "Future" UI Set for example and build with the reusable parts in Core > and Foundation but knowing that no Basic CSS nor classes are linking things > and that you *can't* remove or change since people are using it. So is more > intelligent that "Future" is just a sibiling so people continue using Basic > or Jewel or MDL (think about MX) and new ones start to use the so called > "Future" (or Royale v2.0, think here about SPARK). Understand now what I > mean? > > > > > > > 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. > > > > If you get to fix the current bugs, as you are processing unnecessary CSS > files I think you are introducing longer compiler times for nothing, and > worst, maybe you can fix the bugs of todays, but you can get new ones > tomorrow, and some of them maybe could be hidden or difficult to catch, and > all of this for free. Have this any sense? > > > > > > 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. > > > > Here you and Alex think differently. I put UIBase in Core since was what > Alex suggested. Finaly I think we all think almost the same, but is > impossible to agree in 100% of things. > What we need to do is to move forward and continue build. We need to think > about what is important for each one so we can get the best of us (not > 100%). I for example was more for Core - Jewel, then you proposed > Foundation (not me, it was you, remember? I only put a name that seems > appropriate to me), so for me is ok. > > What I'll never be in agreement is in having CSS that is processing bead > linking as a mandatory dependency for all the technical reasons exposed > > I think that is not in opposite of the rest of things you want, only for > one of them, make all UI sets extend Basic classes, but I have a design > rule in Jewel that is not extend Basic classes, so how we deal with that? > Should I continue as Piotr proposed in a fork and abandone Royale as others > did? Or can we go forward and take the best of what all think? > I remember that I still want to discuss about community things that I think > are as well important for the project, but as I stated, I don't want to mix > and prefer to talk about this as we end this discussion...if we can... > > Thanks > > -- > Carlos Rovira > http://about.me/carlosrovira >
