From dev-return-4557-archive-asf-public=cust-asf.ponee.io@royale.apache.org Mon May 14 16:27:32 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6B261180627 for ; Mon, 14 May 2018 16:27:30 +0200 (CEST) Received: (qmail 7349 invoked by uid 500); 14 May 2018 14:27:29 -0000 Mailing-List: contact dev-help@royale.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@royale.apache.org Delivered-To: mailing list dev@royale.apache.org Received: (qmail 7315 invoked by uid 99); 14 May 2018 14:27:28 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 May 2018 14:27:28 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 1F0691802E5 for ; Mon, 14 May 2018 14:27:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.979 X-Spam-Level: ** X-Spam-Status: No, score=2.979 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=2, KAM_INFOUSMEBIZ=0.75, KAM_SHORT=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id e-TvD_ugWuqx for ; Mon, 14 May 2018 14:27:14 +0000 (UTC) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 5907C5F2A9 for ; Mon, 14 May 2018 14:27:13 +0000 (UTC) Received: by mail-ot0-f175.google.com with SMTP id t1-v6so14470675ott.13 for ; Mon, 14 May 2018 07:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=T00UYNDwlB7IkfNMyka7weQe5WrR5zvnZbgHvbQatA0=; b=qhEwZc9lDut1Udu0J3qpIx3ox6znZ0HTnk/rVncdOriSfGEss55DlcUO6xOH9+ng6P xG50sPD2sDX+8SF2ZNJF0Oepbz10HpPWssa4YAkUtHv9va5vhoAeU/HLiE9hE02qYh0F SW7cuWErRk0CmKt19oMI3pQ8v3e/lKJIJbuCf7FfyT0ydj6VdQhbEOWAn1ylCYug86sl tP2faJA3pMfVX04ZUQhAQYWf9VRZvwcoW04i5mtvp0fuo7mdmviNV+RSihXHMR5IpINg TyxFbXyfVqZIT3zAbwPbsflGbxEbfcLchFLbvB3xoqt0DfNFLwIbfErpD0u2p6MgT4pg ymIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=T00UYNDwlB7IkfNMyka7weQe5WrR5zvnZbgHvbQatA0=; b=YRygZ9p/1V6NIpZ7eSxTY9x+cF/ntBVF7Y8/pM0ucwRlhtrY1wxgo1mQYmHDMrb1Xe /ucVltRD/dQ3QpSuQi/YHGrY9rGNOLWZl97hku/I/HlOKiKHFt1yjynu613BTsIzc4oJ UeWv7aTN6fqecfEr9uFUqgrN7RgEvXNykss60Joi5nYNkgy4uHFu8CKxb7c2nsfkZSeT kwqs5H/bjthAhcYbNKq3IcRnTD6KNOTtqL5FxGHN6+NrKtzaLsg8WPar+F9izgVQBA2c ghEreOKQeyD6qJULeADweDGlbNhq2XzNATm6Gg27YBo485qkdHQjsWIUXzjuXVz2ndv5 WG1w== X-Gm-Message-State: ALKqPwcRHj5FXhQ+ZrFh0zQ3BIZQriEhuqGzNBMjoDLtebWtmBbzmSmq h6Rzcj6A1qkqq+eKXIohP4KAwJtjg25yeu/q75/GfxQw X-Google-Smtp-Source: AB8JxZq9Z2R2MMXUgVvifyO20Hm1rJDolRtCy03cSIzklEPlUKTrfXD/ZcLDPx5klxBUoLDxNR21tUSwdbiB20V6h6I= X-Received: by 2002:a9d:4494:: with SMTP id v20-v6mr7096333ote.278.1526308031511; Mon, 14 May 2018 07:27:11 -0700 (PDT) MIME-Version: 1.0 Sender: carlos.rovira@gmail.com Received: by 2002:a9d:12b:0:0:0:0:0 with HTTP; Mon, 14 May 2018 07:26:50 -0700 (PDT) In-Reply-To: <396DC57D-78A9-42DB-B204-A10D9E97A002@gmail.com> References: <345A0107-9A16-4C38-944D-A68C81182493@gmail.com> <396DC57D-78A9-42DB-B204-A10D9E97A002@gmail.com> From: Carlos Rovira Date: Mon, 14 May 2018 16:26:50 +0200 X-Google-Sender-Auth: q1sNltsgVmJXDpP28HGNiexj4RU Message-ID: Subject: Re: [DISCUSS] Explanation of the changes To: dev@royale.apache.org Content-Type: multipart/alternative; boundary="000000000000093f5c056c2b48cf" --000000000000093f5c056c2b48cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-05-14 15:25 GMT+02:00 Harbs : > > ok, is very difficult to separate things in this case, > > > Yes. I agree. Thanks for bearing with me. :-) > > We might come around to your solutions in the end, but without discussing > it, we are closing off other options which might (or might not) be better= . > > FYI, I have not spent much time until recently looking at Jewel. (I=E2=80= =99m sure > you understand that my life has been very hectic lately=E2=80=A6) ;-) Totally, I feel bad that you have to loose all this time dealing with all this discussion when you have now better thing to do with your family Hope we get to it soon! :) > However, I spent some time looking at what you did to make sure I=E2=80= =99m up to > speed so I could discuss this all as intelligently as I could. I must say > that I am very impressed by what you have done, and I don=E2=80=99t want = this > discussion to detract from that in any way. > > As I mentioned below, I assume you agree that typename conflicts are a > problem. As I understand it, you have solved the problems by a) giving > Jewel components a typename of =E2=80=9Cjewel {component}=E2=80=9D rather= than a typename > of {Component} In this way, even if (for whatever reason) the Basic CSS i= s > imported into an app, the component css (i.e. .Button) does not conflict > with the Jewel component. Additionally, you want to ensure that the Basic > CSS is not included at all and you accomplished that by not having Jewel > depend on Basic. We have two solutions to two problems. =E2=80=9Cjewel bu= tton=E2=80=9D > instead of =E2=80=9CButton=E2=80=9D and: org.apache.royale.jewel.Button e= xtends UIBase > instead of Basic Button. > > So far so good? > right > > Note: We don=E2=80=99t need to ensure that Jewel as a whole does not use = Basic for > this solution to be valid. We just need to ensure that Jewel Button does > not subclass Basic Button. (And the same for other components. Basic Bead= s > could still be used without issue.) > right, always in the bead is still compatible between the counterpart components of the two different sets. Think that this is not happening some time and other not. > Additional note: If we fix the bug of 1b and 1c, the only CSS we are > concerned about importing is the HTML CSS. No extra classes would be > imported by subclassing Basic Button. > > The way I see it, this is a valid solution to the problem, but it has two > downsides: > > 1. To prevent bringing in the Basic Button CSS we cannot subclass Basic > Button (if we otherwise want to). > right > 2. Client code cannot declare default CSS in their app for all Jewel > components of a specific type. In other words j:Button{background-color:b= lue} > will not work because a Jewel Button does not have a =E2=80=9CButton=E2= =80=9D class name. > No. That would work. You can check in Jewel "sass" folder where all components define the css that links beads and classes. In that case we don't have anything for Button at this time, but most of the rest have declarations like j|{Component} and beans assigned. Then mostly all html styles are in themes in the styles that are as you already notice "jewel {component}" > > The first downside is not a big deal as far as I=E2=80=99m concerned. Som= e > possible code duplication for a good reason is ok. > I think even is a better way since you are dealing with "final" code and from there you will want : a) aggregate (i.e:ButtonWithSteroids) b) specialize (TextArea from TextInput? maybe not a real example...) but don't want to create a component with a very different nature, right? > The second downside is a bigger issue in my book because it removes some > of the core functionality that Royale offers. Setting global css requires > either knowing the default classnames that Jewel uses or assigning a cust= om > classname to every component in the app > Ok, that would be really bad if happens, but as I stated that's not working as you think. As I described before all components are using j|{Component} and that affects all the all jewel components of that type, but even you can as well use "jewel {component}" to override in your app html css things without problem. > > If there is no better option, than =E2=80=9Cso be it=E2=80=9D, but before= we decide that, > I=E2=80=99d like to see if there are other options that might be a more c= omplete > solution. > > Does this make sense? > I think this clears more about what things what supposed to happen :) Carlos > > Harbs > > > On May 14, 2018, at 3:40 PM, Carlos Rovira > wrote: > > > > Hi Harbs, > > > > 2018-05-14 14:23 GMT+02:00 Harbs : > > > >> I think I still did not make myself clear. > >> > >> I=E2=80=99m not talking about someone only using Jewel. I am talking a= bout an > >> application which uses BOTH a Jewel Panel *AND* a Basic Panel (or > Button, > >> TextInput, etc.). The problem I=E2=80=99m discussing has nothing to do= with > whether > >> Jewel extends Basic or not. I=E2=80=99m trying to come to an understan= ding > whether > >> we can agree that the potential of conflicts when a component of the > same > >> name from two different component sets in the same app is a problem. > >> > >> I=E2=80=99m working under the assumption that component sets are not n= ecessarily > >> mutually exclusive and users might use components of the same name in > their > >> apps from two different component sets. I=E2=80=99m assuming that conf= licts when > >> two component sets are used is a concern. > >> > >> Do we agree that this is a problem? > >> > >> I assume you do agree with this problem considering you gave Jewel > Button > >> a typename of =E2=80=9Cjewel button=E2=80=9D instead of =E2=80=9CButto= n=E2=80=9D. It=E2=80=99s possible that the > >> correct solution is that any component set which does not want to > inherit > >> from Basic must specify a different typename. (Like what you did.) > Again: > >> I=E2=80=99m not trying to pin down solutions yet. I=E2=80=99m first tr= ying to pin down > the > >> problems. > >> > > > > ok, is very difficult to separate things in this case, but I try to > follow > > you and see what we reach. Let's continue to analyze. > > > > Thanks > > > > Carlos > > > > > >> > >> Thanks, > >> Harbs > >> > >>> On May 14, 2018, at 1:47 PM, Carlos Rovira > >> wrote: > >>> > >>> Hi Harbs, > >>> > >>> 2018-05-14 10:14 GMT+02:00 Harbs >> harbs.lists@gmail.com>>: > >>> > >>>> Hi Carlos, > >>>> > >>>> I=E2=80=99d like to work on getting this discussion as focused as po= ssible. > Once > >>>> we=E2=80=99re clear on the problems, it=E2=80=99s much easier to fin= d a solution which > >> is > >>>> acceptable to everyone. I think part of the miscommunication until n= ow > >> was > >>>> that the discussion focused on solutions rather than problems. I=E2= =80=99m > >> going to > >>>> try and nail down what we agree on and what we disagree on (I think = we > >>>> agree more than we disagree) and then take it from there. > >>>> > >>>> Sounds like a plan? > >>>> > >>>> I=E2=80=99d also like to avoid lengthy emails as much as possible to= make > >>>> everything easier to digest. I=E2=80=99m going to leave out anything= I don=E2=80=99t > >> think > >>>> is core to the discussion. > >>>> > >>>> First of all, I think we can take 1b and 1c out of the discussion. I= f > I > >>>> understand correctly, we both agree that these are bugs which should > be > >>>> fixed. If the bugs are fixed, those two issues are taken care of. > >>>> > >>>> That leaves us with 1a, 2a and 2b to discuss. I also need to clarify > my > >>>> points better. Agreed? > >>>> > >>>> Long emails with lots of points make for difficult discussion. I pla= n > on > >>>> discussing all the points, but I think it would be easiest to resolv= e > >>>> issues one at a time. I=E2=80=99ll start with what I believe to be t= he one > we=E2=80=99re > >>>> closest to agreeing on. > >>>> > >>> > >>> I think is ok, we'll go with 1a in this email: > >>> > >>> > >>>> > >>>> Re. 1a: > >>>>> Namespaces already solve this so a js|Button is separated from > j|Button > >>>> and > >>>>> from mdl|Button, if no namespace was declared last wins > >>>> > >>>> I obviously was not clear. I was discussing compiled html CSS and no= t > >>>> Royale CSS. > >>> > >>> > >>> ok we can go just with html, but left in mind that both problems are > >>> equally important, since both makes the concept of extend a final ui > set > >>> not the best way to go. > >>> Let's go: > >>> > >>> > >>>> Let me use a concrete example: > >>>> > >>>> Imagine a user uses the following css: > >>>> j|Panel{ > >>>> border: none; > >>>> } > >>>> js|Panel{ > >>>> border : 1px solid #333333; > >>>> } > >>>> > >>>> This will produce the following css: > >>>> .Panel{ > >>>> border: none; > >>>> } > >>>> .Panel{ > >>>> border : 1px solid #333333; > >>>> } > >>>> > >>>> Both a basic Panel and a Jewel Panel (assuming one exists) will both > >> have > >>>> the typename of =E2=80=9CPanel=E2=80=9D, and there=E2=80=99s no way = to differentiate between > >> them > >>>> so `j|Panel` css has no effect. I believe this is a problem which > needs > >> a > >>>> solution. > >>>> > >>>> One solution might be to produce css which looks like this: > >>>> .jewelPanel{ > >>>> border: none; > >>>> } > >>>> .basicPanel{ > >>>> border : 1px solid #333333; > >>>> } > >>>> > >>> > >>> I have to deal with this all the time in MDL and Jewel and was really > >>> cumbersome, what indicates that's not the best way to go at early > time, > >>> but I prefer to follow and continue trying until I reach that the bes= t > >> way > >>> was separation since there was no need of one final ui set depends on > >> other > >>> fine ui set. > >>> And the same you find with html css can be applied to the assignation > of > >>> beads troth css. If you don't want a current one you need to splicitl= y > >> code > >>> an override. > >>> Extending a final component brings all that is defined with him, so i= f > >> you > >>> are creating a different set (and you'll do that regarding some major > >>> motivation and difference with the other set) you find trying to make > new > >>> one work as expected is difficult and can introduce problems if we at > >>> royale don't invest many time looking to side cases like this and > fixing > >>> them. So this left things overrided in your browser in "latency" sinc= e > if > >>> you remove the current you'll get what is below. My opinion is that w= e > >>> should have nothing below. > >>> > >>> One latest important things to consider: If we have a j|Panel and you > >>> should want to use only that why we should have two styles I our css > one > >>> unused? > >>> > >>> .jewelPanel{ > >>> border: none; > >>> } > >>> .basicPanel{ > >>> border : 1px solid #333333; > >>> } > >>> > >>> you're in jewel you have your css bloated with extra size and unused > >>> things. Hope you can see now the big problem this means > >>> > >>> > >>>> > >>>> That would require Basic typenames to have a =E2=80=9Cbasic" prefix = and Jewel > >>>> typenames to have a =E2=80=9Cjewel" prefix. If that solution is used= , then > >> problem > >>>> 1a goes away. There might be other solutions which don=E2=80=99t sol= ve 1a. I > >> don=E2=80=99t > >>>> know. I do think that this problem needs to be discussed. Depending = on > >> the > >>>> outcome of that discussion, there might or might not be an argument = to > >>>> separate Jewel because of problem 1a. I have more to say on this > topic, > >> but > >>>> I don=E2=80=99t want to interject my thoughts before discussion is s= tarted on > >> it. > >>>> > >>>> > >>> I must say that Jewel already have different classes. While Basic is > >>> "Button" in jewel we're using a namespace inspired in both MDL and > >> Semantic > >>> and is "jewel button". > >>> But if you still extend Basic Button then you are getting things work > by > >>> wasting lines of code overriding here and there both in code and > looking > >>> for tricks like this to diverge from the parent component. > >>> > >>> Harbs, you can make the things you proposed. MDL is like that, Jewel > was > >>> until the refactor. We would not be more natural and optimal that > instead > >>> have to deal with overrides or how to separate things we just make bo= th > >> not > >>> depend on it? I was getting to that conclusion after some months to > deal > >>> with this kind of things. And I must say I was in the same way of > >> thinking > >>> that you. But after lot of experience in that field that makes me try > the > >>> current one, and wow! that finaly engaged me. > >>> > >>> Try to think in controls and components like "final" and how you can > >> change > >>> something that with that character, you see that is not the same that= a > >>> core class, and until now we want Basic to be "framework" as well as > >> final > >>> controls. > >>> > >>> > >>> > >>>> Can we agree on this problem and try to find the right solution to i= t? > >>>> > >>> > >>> I think that's the problem. But for this current one I doubt you find= a > >>> better solution. Think that both are solutions already (like I expose= d > >> just > >>> before), we have many ways to reach the same. But IMHO, I'm mostly li= ke > >>> more the separation. > >>> > >>> Sorry if I finaly write more that you expect, I'll try to reduce, but > is > >>> difficult when I have so many points to expose. > >>> > >>> thanks! > >>> > >>> > >>>> > >>>> Thanks, > >>>> Harbs > >>>> > >>>>> On May 13, 2018, at 10:02 PM, Carlos Rovira > > >>>> wrote: > >>>>> > >>>>> Hi Harbs, > >>>>> > >>>>> 2018-05-13 10:40 GMT+02:00 Harbs : > >>>>> > >>>>>> I specifically waited to respond to this until some of the heat > cooled > >>>>>> off. I have no question that there is a bit of a language barrier > here > >>>> and > >>>>>> both sides are not making themselves completely understood. > >>>>>> > >>>>> > >>>>> I could in the previous hours get some information that's important= , > >> but > >>>> I > >>>>> prefer to not mix things here, so hope to share as I can, so avoidi= ng > >> to > >>>>> introduce more noise. > >>>>> > >>>>> > >>>>>> > >>>>>> I=E2=80=99m a bit disappointed that we=E2=80=99re moving towards a= vote before I > >> believe > >>>>>> we=E2=80=99ve gotten to the bottom of the technical motivations. I= was > hoping > >> we > >>>>>> could get to the point where we understand each other and make a > vote > >>>>>> unnecessary. > >>>>>> > >>>>>> > >>>>> I said about to make a vote thread, since I was not hearing many > things > >>>> in > >>>>> favor of my work, but reading your email, Om, and other feedback, I > >> think > >>>>> we are moving to a really different scenario. This is more a > community > >>>>> discussion, with a really different tone, so if you (and others) > >> finally > >>>>> doesn't want to vote, for me will be ok. I was only doing since see= ms > >>>> what > >>>>> all of you demand at that point. > >>>>> > >>>>> > >>>>>> Let me try and summarize the technical reasons as I see them for a= nd > >>>>>> against a refactor: > >>>>>> > >>>>>> Reasons for the refactor: > >>>>>> 1. As it stands, referencing Basic brings in all of the Basic CSS. > >> This > >>>>>> causes a number of issues: > >>>>>> a. Another component set (i.e. Jewel) needs to override any CSS > >>>>>> specified in the Basic CSS. > >>>>>> b. The CSS which is compiled from the Basic CSS adds unnecessary > bulk > >>>>>> to the final application if Basic components are not being used. > >>>>>> c. Although this point was not clear (to me) from the previous > >>>>>> discussion, all classes referenced in Basic CSS are actually > imported > >>>> into > >>>>>> the final application. For example: DateControlsExample does not u= se > >>>>>> ButtonBar, but ButtonBar and all related classes are included in t= he > >>>> final > >>>>>> application. By not relying on Basic, these classes are not > imported. > >>>>>> > >>>>>> 2. Basic and Jewel are separate component sets, and as such should > not > >>>>>> rely on each other. Any part of Basic which Jewel needs is not > >> =E2=80=9Cbasic=E2=80=9D, > >>>> but > >>>>>> =E2=80=9Ccore=E2=80=9D and should be moved to the Core project. Do= ing so has the > >>>> following > >>>>>> benefits: > >>>>>> a. There=E2=80=99s a clear separation of dependencies. > >>>>>> b. Someone working on Jewel does not need to be concerned with the > >>>>>> architecture of Basic. > >>>>>> > >>>>>> I=E2=80=99m not aware of any other arguments which are not variati= ons on the > >>>>>> above. Please correct me if there are more reasons. > >>>>>> > >>>>> > >>>>> I think is mostly the technical reasons. I exposed many of the > >> collateral > >>>>> damages of all of this, but I think is basically the problem. Great > to > >>>> see > >>>>> finaly I could make it understand :) > >>>>> > >>>>> > >>>>>> > >>>>>> Reasons against the refactor: > >>>>>> 1. Royale favors composition. As such, it was designed so > >> functionality > >>>>>> can be pieced together. Much of this functionality was created in > the > >>>> Basic > >>>>>> project and as such, it=E2=80=99s natural for component sets to bo= rrow > pieces > >>>> from > >>>>>> each other. This reduces code duplication. > >>>>>> > >>>>> > >>>>> Right. But IMHO, this should be chosen for user users. If he wants > >>>>> functionality, he can "optionally" take it, and not "obligated" to. > >>>>> In the other hand think about functionality that is not exactly the > >> same. > >>>>> If I have a bead that in Jewel put a className and in Basic the > >>>>> implementation puts an attribute on the tag. The user will find bot= h > >> with > >>>>> CTRL+SPACE (code hintting feature), or using a Button will find > >>>> obligatory > >>>>> more than a Button, that will comes to confussion. What is the righ= t > >>>> Bead? > >>>>> the right control?...If he optionally wants to add functionality, i= s > up > >>>> to > >>>>> him to use one or another. > >>>>> > >>>>> > >>>>>> 2. Moving pieces of Basic to Core does not scale. We need to defin= e > >> what > >>>>>> Core is, and claiming that something is required by a component se= t > >>>> makes > >>>>>> it Core is not a good definition. For example, Collections is not > >> Core, > >>>> but > >>>>>> it is required by component sets. As it stands, Core defines the > core > >>>>>> architecture of a Royale application, but says very little about > >>>>>> implementation details. That=E2=80=99s why there are lots of inter= faces, but > >>>> not so > >>>>>> many implementation classes. It=E2=80=99s possible that little bit= s of Basic > >>>> might > >>>>>> make sense to be in Core instead (and vice versa), but I think the > >>>> general > >>>>>> difference between Core and Basic is well defined (although possib= ly > >> not > >>>>>> well understood). > >>>>>> > >>>>> > >>>>> I must say that don't see why moving pieces to Core will not scale. > The > >>>>> pieces are the same, the extensions are the same. There's a change = of > >>>>> location for some classes to get a better decoupling. One thing to > >> notice > >>>>> is that we are dealing with *final implementations* or *leaf > >>>>> implementations*: this means the same like when we mark a method in > >> java > >>>>> like final...this seems we expect a final use. A button, for exampl= e, > >> can > >>>>> be aggregate in a "ButtonWithDisableBead", but this works more like= a > >>>>> "macro" than an extension. So AFAICT, subclass other's UI Set > controls > >> or > >>>>> beads, seems to be not desirable in a huge percentage of cases, at > >> least > >>>> in > >>>>> my experience with MDL and Jewel (and I think that's a huge > >> experience). > >>>>> MDL was done subclassing, but I found many problems going in that > path. > >>>>> Jewel started equally but I then did this refactor and now I'm very > >> happy > >>>>> since I see all more well crafted. I'd like that the theory you > expose > >>>> will > >>>>> be real, but the practice tell me the opposite. Or said in another > >> way, I > >>>>> was aligned with you but as I followed the path, I end embracing th= is > >>>> other > >>>>> path as to be better, more flexible, with less errors, and > problems... > >>>> and > >>>>> the price is really no one, since all things we want in a Royale > >>>> Appication > >>>>> are still there. > >>>>> > >>>>> > >>>>> > >>>>>> 3. Not every class in Basic *can* be moved to Core. For example, > >>>>>> DataItemRendererFactoryForArrayList has a dependency on > Collections. > >>>> Core > >>>>>> was designed to have no dependencies on any other projects other > than > >>>>>> Language, so that class cannot belong to Core. I would imagine tha= t > >>>> other > >>>>>> component sets other than Basic might need ItemRendererFactories. > >>>>>> > >>>>>> > >>>>> This is where from the beginning I ask for help. I did one way. Is > >> like a > >>>>> Zero day. We can get it much better moving other things and I think > >> you, > >>>>> Alex, Peter, knows perfectly and maybe better than me how to > reorganize > >>>>> things you think. For example instead to move a class to Core extra= ct > >>>> code > >>>>> to be implemented in Basic and Jewel. Or like the example I already > >>>> exposed > >>>>> that was problematic, extract Group states and mxml nesting and add > it > >> to > >>>>> Group and HTML's NodeElementBase... I think there's lots of things = to > >> do > >>>>> here. We only must to take into account to left Basic - Jewel > >> separated, > >>>>> but options are lots. > >>>>> > >>>>> > >>>>>> > >>>>>> Possibly the strongest argument against the refactor is that I > believe > >>>> the > >>>>>> refactor doesn=E2=80=99t actually solve the problems it=E2=80=99s = meant to solve. > >> Please > >>>>>> allow me to explain: > >>>>>> > >>>>>> 1b and 1c are actually bugs. I=E2=80=99m glad Carlos brought them = to light, > >>>>>> because they need to be fixed. These problems have nothing to do > with > >>>> the > >>>>>> fact that one component set relies on another. Even if a single > >>>> component > >>>>>> set is used, all the css and classes mentioned in the css file are > >>>>>> imported. That should not happen. If the compiler does a better jo= b > of > >>>> only > >>>>>> using the css and classes where are *actually* used, these two iss= ue > >> go > >>>>>> away. > >>>>>> > >>>>> > >>>>> I think there's a problem, that's right, but the problem should not > >> mask > >>>>> the flexibility that we now with the current separation. Remember, > >> what's > >>>>> the point if we have the problem fixed and we link again Basic to > >> Jewel, > >>>> if > >>>>> Jewel will never use Basic? > >>>>> > >>>>> > >>>>>> > >>>>>> I think the refactor really masks 1a and does not solve that one > >> either. > >>>>>> There=E2=80=99s actually a fourth problem related to CSS. What hap= pens if a > >>>> single > >>>>>> app uses a Basic Button, an MDL Button and a Jewel Button? (As to > why > >>>> that > >>>>>> might happen =E2=80=94 components can be used within other compone= nts and > not > >>>> all > >>>>>> component sets might be as complete as others.) What will each of > the > >>>>>> buttons look like? As it stands the typenames will conflict with > each > >>>> other > >>>>>> and the CSS will step on each other. I=E2=80=99m not even sure whi= ch CSS > will > >>>> win. > >>>>>> It seems to me that typenames really should be qualified to preven= t > >>>>>> namespace conflicts. I=E2=80=99m not sure how to best solve this, = but I > think > >> it > >>>>>> deserves discussion. > >>>>>> > >>>>> > >>>>> Namespaces already solve this so a js|Button is separated from > j|Button > >>>> and > >>>>> from mdl|Button, if no namespace was declared last wins, so at that > >>>> level I > >>>>> think things are ok, but what is happening is since an mdl|Button i= s > >>>>> extending a js|Button, then you get all CSS from both of them, mdl > wins > >>>> and > >>>>> must override things in Basic. IMHO, that's not good from an > >> architecture > >>>>> design point of view and more... for an override, since those are > >> *final* > >>>>> or *leaf* controls, and more...we can get other classes in the > >>>> inheritance > >>>>> chain that we never want to use, so extra space is added. Then > there's > >>>> the > >>>>> pure CSS styles, but that's the nightmare I (as the UI set develope= r) > >> use > >>>>> to fight each day when design a new control for MDL or Jewel, and I= f > I > >> do > >>>>> my work ok, you should not see any conflicts, but at the cost of > >> override > >>>>> *all* predefined styles (extra space again in place). > >>>>> > >>>>> I think that the need to override styles before the refactor in Jew= el > >> is > >>>>> not PAYG nor DRY. Or said in another way: If Jewel doesn't use a > >> control > >>>> or > >>>>> component in some part of the defined style, and maybe doesn't need > to > >>>> use > >>>>> a Bead, but it still needs to override it?. I think that's not > >> scalable. > >>>>> And the best solution I can propose is to disconnect final/leaf > >>>>> implementations one from another. > >>>>> > >>>>> > >>>>>> > >>>>>> As far as 2a and 2b go: Here=E2=80=99s my thoughts: I don=E2=80=99= t see 2a as a goal > >> for > >>>>>> Royale. I think functionality sharing across component sets is an > >>>> advantage > >>>>>> to Royale and not an architectural problem. > >>>>> > >>>>> > >>>>> I think so, but always for not final/leaf implementations, and the > key > >>>>> always, optionally and not obligation imposed by the framework that > >> makes > >>>>> it more powerful and flexible. That's great for some functionality > that > >>>> you > >>>>> need to implement in various UI sets, beads that are very/really > >>>>> generalist. Not at all for beads that are very near on concrete nee= ds > >> in > >>>>> implementation UI Set, since you'll never be able to use it. > >>>>> > >>>>> > >>>>>> Regarding 2b: complete separation from Basic seems to me like it > only > >>>>>> helps splinter the community and puts everyone into their own litt= le > >>>>>> isolated corner. As difficult as it might be to deal with others= =E2=80=99 > >>>> opinions > >>>>>> and it causes things to drag on longer than it otherwise might, I > >> think > >>>>>> it=E2=80=99s ultimately the better path. I really do recognize the > frustration > >>>> of > >>>>>> trying to do something and have the brakes put on you by others. I > >> don=E2=80=99t > >>>>>> know how to put that empathy into an email. It=E2=80=99s a poor me= dium for > >> that. > >>>>>> Ultimately, the more we rely on each other, the better the quality > of > >>>> the > >>>>>> end product will be =E2=80=94 even if it takes us longer to get th= ere=E2=80=A6 ;-) > >>>>>> > >>>>> > >>>>> Well, as I said to Yishay, I think separation brings flexibility an= d > >>>> makes > >>>>> the whole framework even more prepared to future aggressive changes > (a > >>>> v2.0 > >>>>> and next versions) since from the beginning you didn't make it depe= nd > >> on > >>>>> Basic, so you can start another effort in parallel as a sibling. I > >> think > >>>>> that concept is very powerful don't you think? > >>>>> > >>>>> Jewel borns from the work in Basic, it could not be at all without > >> Basic. > >>>>> But Basic has a purpose to be very well decided, so it will always > >>>> collide > >>>>> with Jewel that has very difference purpose. And I think we always > >> talked > >>>>> about people coming and creating new UI sets as needed, but those > >> coming > >>>>> will find the same problems that I found if they are obligated to > deal > >>>> with > >>>>> other final UI set like Basic. > >>>>> > >>>>> In the other hand, we need to grow to have more people interested i= n > >>>>> different parts, and wanting to get involved in those parts, so we > can > >>>> act > >>>>> more as a community. I must to say that I don't mind to discuss mor= e, > >>>> but I > >>>>> think I always think in the value of what others have to say. When > >> Alex, > >>>>> Peter, you and other use to expose things I use to engage with the > >>>>> solutions and if I have something to say use to be to propose ways = to > >>>>> improve an already good solution by default. When I expose changes,= I > >> use > >>>>> to want people that comes to improve it, making it better than only > >> with > >>>> my > >>>>> solely participation. I think that's what we need to get here. Sinc= e > >>>> people > >>>>> here are very good by default, I suppose nearly 100% of proposals > >> should > >>>> be > >>>>> good, and debate/discussion should go in tone of "And what if you > >>>> incorpore > >>>>> this?", "I think doing this could be event better", and so... that > >> would > >>>>> make a good difference. And I think is something to comment a part > >> since > >>>>> this community deserver this kind of good health. > >>>>> > >>>>> > >>>>>> > >>>>>> I hope this makes my position clearer and I look forward to other > >>>> thoughts. > >>>>>> > >>>>> > >>>>> Really, I think this is completely different way of managing things > >> and I > >>>>> appreciate really. It's more constructive, friendly and at last we > are > >>>>> talking about real things than asking us things lots of times in an > >>>>> infinite loop. I think is a real community discussion. > >>>>> > >>>>> Thanks for take the time and your efforts reviewing this :) > >>>>> > >>>>> Carlos > >>>>> > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Harbs > >>>>>> > >>>>>>> On May 12, 2018, at 11:09 AM, Carlos Rovira < > carlosrovira@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 th= is > >>>>>>> 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 Applicatio= n. > >>>> 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 althou= gh > >> 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 Slide= r, > >> 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 fr= om > >>>>>> 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 o= f > an > >>>> UI > >>>>>>> set, was in fact needed in all Royale Applications, and that caus= e > >> 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/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. Peopl= e > >>>> using > >>>>>>> Basic, will use it I the same way and get exactly the same. So th= is > >>>>>>> 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 sti= ll > >>>> 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. Norma= l > >>>> 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 HT= ML > >>>> 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 i= n > >> 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 sta= rt > >> 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 Jew= el > >>>>>> 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 prese= nt > >>>> that > >>>>>>> they don't need (CTRL+SPACE will only throw one kind of Button no= w > >>>>>> 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) a= nd > >>>>>>> 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 > >>>> > >>>> > >>> > >>> > >>> -- > >>> Carlos Rovira > >>> http://about.me/carlosrovira > >> > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > --=20 Carlos Rovira http://about.me/carlosrovira --000000000000093f5c056c2b48cf--