From dev-return-4766-archive-asf-public=cust-asf.ponee.io@royale.apache.org Tue May 29 16:35:05 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 593DA180648 for ; Tue, 29 May 2018 16:35:04 +0200 (CEST) Received: (qmail 70853 invoked by uid 500); 29 May 2018 14:35:03 -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 70634 invoked by uid 99); 29 May 2018 14:35:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2018 14:35:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 2326EC9776 for ; Tue, 29 May 2018 14:35:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.86 X-Spam-Level: **** X-Spam-Status: No, score=4.86 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=2, HTML_OBFUSCATE_05_10=0.001, HTTP_ESCAPED_HOST=1.621, KAM_INFOUSMEBIZ=0.75, KAM_LOTSOFHASH=0.25, KAM_SHORT=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd1-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 (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id Er920ffipjyE for ; Tue, 29 May 2018 14:34:57 +0000 (UTC) Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 71A795F24C for ; Tue, 29 May 2018 14:34:56 +0000 (UTC) Received: by mail-ot0-f178.google.com with SMTP id n3-v6so17193513ota.5 for ; Tue, 29 May 2018 07:34:56 -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=u/DEoLtZf6cyxhr5L21tDifJ1nlw1UltNETjw84+MGo=; b=WGOPG4JVMhVFZEd/Pjo7q2NSuiPKsOAksK8GX6go42nFgee2laV6yBiW/ZruiZflp1 k0fOrc4U6qIuUr7KVfu4aVFt6PZJJmWpJTVhq4FKBJAwQEeiHi65cm9WuwKl8ONkbpaA rsZ3GmK/SKR/rgKRD9n5KG19SatTLMe3QJ++ZFQNqZ5KyGA2icWPu9cb7jAe9FLEydpH 8CP6EPT7yPrl27Z7rT/sgTOXkk3YH4uxPSnyZr0IzpTYOqhcKH/4fz6QqjAKD5j2QcGi bTri9N0IgJmE5c1WNBQsY9f3h+gSHckHuRf9LDy98CnHmGhk5IIKc8A1qhuFApNfLQMR bc3w== 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=u/DEoLtZf6cyxhr5L21tDifJ1nlw1UltNETjw84+MGo=; b=n7NoFhH2/AqFPrJM79OnbhFiR1k/xIzyKUhZbp5/GdHEFlrsmgG3gAN1uW1ed/oYL7 rgCImvPArFAmVt9/JfmZGvzAkT9Ffm03uxmkXazDykkKN+YYP86cwyPKQKAPFW0il5cs 8dfpG2RTvg/S/UaKogxKXzinYRF8UK41paaozvYPoVwn7wPmLz6qc1ABbRgOtSBWo72B tcprKYYFUL42RgukoTtPWyTZ1LPN1GyM6UKNQMo3H/h179FnE4EoBbOyv/W+2bdh1G1O ul6MVwUdB3qRbyyeZn7RSQTCia5GPaD2KNJaitrMixYp6jpOxnF2sp/WDOt+qTx0aIQ+ 8s5Q== X-Gm-Message-State: ALKqPwd8SQEiJ0Yv94KSQNVPIEUgrn/I9MxasvEvZ/pXD5vhVm3SSLsN 1MLiTzW6+qfNq2WHGHyjYJQGfpjPmeUVCqJCroIehMSn X-Google-Smtp-Source: ADUXVKJG+vPj1UCbvxMqvz+obtlJYnO/LIyxWWTtd83rJ7YrgEXKTANWBwZPsmccxBDEG37c+E76rw+oq9t70DpKrT4= X-Received: by 2002:a9d:7417:: with SMTP id n23-v6mr10782287otk.318.1527604494844; Tue, 29 May 2018 07:34:54 -0700 (PDT) MIME-Version: 1.0 Sender: carlos.rovira@gmail.com Received: by 2002:a9d:4207:0:0:0:0:0 with HTTP; Tue, 29 May 2018 07:34:34 -0700 (PDT) In-Reply-To: <8196A500-F844-45D3-B302-FF8D27FF6233@gmail.com> References: <5278BB3A-C34B-4313-B432-9C8810395589@adobe.com> <25602417-03F8-4D09-874E-B4EAE1F86844@adobe.com> <259EDB3A-BA4B-4194-BDD1-34F6B642D49C@gmail.com> <8196A500-F844-45D3-B302-FF8D27FF6233@gmail.com> From: Carlos Rovira Date: Tue, 29 May 2018 16:34:34 +0200 X-Google-Sender-Auth: Hxuiwr_E6C8Vy100evLXHRHj7_A Message-ID: Subject: Re: [Discussion] Package change names (was Re: 0.9.3 Release) To: dev@royale.apache.org Content-Type: multipart/alternative; boundary="00000000000045c8c5056d5923a9" --00000000000045c8c5056d5923a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi 2018-05-29 16:00 GMT+02:00 Harbs : > > > 1. How do we define what is =E2=80=9CCore"? > *Core*: This classes are needed to build a Royale Application. All pieces here are required. No CSS is present here to wire any concrete relationship between pieces, as well avoiding possible inclussions of CSS rules and/or bugs in a final App. > 2. Should package names match the project names? > Normaly this is true always. Don't recall libraries with mixed package names. Some exceptions: Network has "net", but this is normal for less verbosity. > 3. Do we care to try and make package names shorter (i..e limit the level > of folders)? > Yes, if we can, but in the case os beads, since we'll be using mostly on mxml, we put shorter class name over package levels. Even on AS3 in this case is better a longer import than multiple longer class names use. > 4. What are the advantages and disadvantages of making Basic a dependency > for other component sets? > I think this is mostly explained here, and a image use to be better than thousand words, but the image mix graphs and explanations: https://snag.gy/DbH4iG.jpg > 5. A question which might follow the ones above are whether we should add > a new package. I=E2=80=99d rather wait to discuss this until we have some= clarity > on the ones above. > mmm...you mean to say "package" or new "library" (maybe you refer to "Foundation" here) > > Can you think of any other questions we should be asking ourselves? > Not for now. Thanks Carlos > > Thanks, > Harbs > > > On May 29, 2018, at 4:41 PM, Carlos Rovira > wrote: > > > > Hi, > > > > completely. > > > > two things: > > > > 1. I propose in the new Discussion thread to make that work myself, but > we > > can do together. I think the best way is to rename and move things in > > chunks so we make this in various steps, testing builds not break, and = so > > on....this will take some days to reach a good shape. > > 2. I already said my work was totally incomplete. But as we need this > > discussion I didn't do more but fixing build. > > > > > > 2018-05-29 15:13 GMT+02:00 Harbs : > >> > >>> First, the hopefully easy things we can agree on: > >>> -I have no objection to dropping "Bead" off of bead class names > >>> -I have no objection to moving all views into a view subfolder as lon= g > >> as nobody else is concerned about the size and performance issues. > >>> -I have no objection to moving classes in Basic that are > >> org.apache.royale.html to org.apache.royale.basic. > >>> -I have no objection to doing a massive rename and long as it isn't m= e > >> doing the work. > >>> -Whatever is in Core and Basic now or before Carlos's started moving > >> things around is not perfect. > >> > >> I agree with this completely. Carlos, do you agree as well? (I would b= e > >> willing to help out with a rename, but I want to make sure it doesn't > cause > >> too much disruption. > >> > >> Thanks, > >> Harbs > >> > >>> On May 23, 2018, at 12:43 AM, Alex Harui > >> wrote: > >>> > >>> Hi Carlos, > >>> > >>> I guess I don't understand why separating beads from TLCs is better. > >> How will that make things better for users or other component set > >> developers? That would effectively double the number of SWCs and each > TLC > >> SWC will need its bead SWC. That doesn't sound like a good thing to m= e, > >> but if that's what other folks want to do, that's fine with me. > >>> > >>> I was just looking through the classes in Jewel. It looks like JeweL > >> doesn't have a DataGrid yet.. When it does, I would think you will > want to > >> use the DataGridModel from Express as it handles both Arrays and > >> ICollectionViews. We will probably create a similar model bead that > takes > >> both ICollectionViews and Arrays for Lists and put that in Express as > >> well. Then we might decide that is better for Jewel to use that model > >> instead. Or maybe we'll decide to create a JewelExpress set that has > those > >> more general models that don't require as much configuration. Anyway,= I > >> hope you agree that at some point, these more general models will be > used > >> by Express and some flavor of Jewel. I don't think this general model > >> should go in Core, or Basic (or some new category called Foundation). > And > >> at that point, Jewel or JewelExpress is going to re-use that code in > >> Express. > >>> > >>> Component sets are encouraged to re-use existing code from any other > SWC > >> since I think we've agreed that re-use is important. > >>> > >>> My 2 cents, > >>> -Alex > >>> > >>> =EF=BB=BFOn 5/21/18, 11:16 AM, "carlos.rovira@gmail.com >> carlos.rovira@gmail.com> on behalf of Carlos Rovira" < > >> carlos.rovira@gmail.com on behalf of > >> carlosrovira@apache.org > wrote: > >>> > >>> Hi Alex > >>> > >>> what do you think about separating the part in Basic that is > >> inherently the > >>> same as in Jewel (Button, CheckBox, TextInput, List, ...) along wit= h > >> CSS > >>> that wire the beads for Basic UI set, and left the fundamental > >> building > >>> blocks as something that is not Core but can be reused by Basic and > >> Jewel > >>> (Let's call this "Foundation" Lib, I even like this name for this > >> library). > >>> > >>> I mean that having "Foundation" lib and "Basic" lib, will be more > >> clear, > >>> since we can expect what is in Basic will be never reused to build > >> other UI > >>> Sets (MDL, or others can still hang from there or if someone wants = to > >> take > >>> the time refactor it). > >>> > >>> Foundation will not have any CSS wiring beads. We can return classe= s > >> from > >>> Core to Foundation. > >>> > >>> Basic will have its own CSS wiring beads, the same for Jewel. Both > >> will > >>> requiere Core and Foundation. > >>> > >>> I assume this will make all of us happy. > >>> > >>> We can as well do the package name changes to ensure consistency > >> along all > >>> code and libraries. > >>> > >>> Let me know what do you think > >>> > >>> thanks > >>> > >>> Carlos > >>> > >>> > >>> 2018-05-21 19:38 GMT+02:00 Alex Harui : > >>> > >>>> I understand this isn't the latest post on this thread, but it is th= e > >>>> easiest one for me to reply to: > >>>> > >>>> First, the hopefully easy things we can agree on: > >>>> -I have no objection to dropping "Bead" off of bead class names > >>>> -I have no objection to moving all views into a view subfolder as lo= ng > >> as > >>>> nobody else is concerned about the size and performance issues. > >>>> -I have no objection to moving classes in Basic that are > >>>> org.apache.royale.html to org.apache.royale.basic. > >>>> -I have no objection to doing a massive rename and long as it isn't = me > >>>> doing the work. > >>>> -Whatever is in Core and Basic now or before Carlos's started moving > >>>> things around is not perfect. > >>>> > >>>> Now for the less easy. Regarding Core vs Basic, I see it this way: > >> Basic > >>>> is the simplest implementation of the constructs/concepts in Royale. > >> It is > >>>> intended to be extended and enhanced by other component sets via our > >> PAYG > >>>> principles. Core is intended to identify the constructs/concepts an= d > >> their > >>>> fundamental contracts. > >>>> > >>>> Think of it this way: When you open any class in Royale, you will > want > >> to > >>>> know what kind of class it is. It is a TLC, a Bead? And what kind = of > >> TLC > >>>> or Bead? Is it View, Model, Controller? An ItemRenderer? These a= re > >> the > >>>> categories of classes we had, even in Flex. I've probably left out = a > >> few > >>>> categories. It is the interfaces for these categories that go in > Core. > >>>> And maybe some classes we think are universal implementations of tho= se > >>>> categories. And some beads that are component set agnostic, like > >>>> BrowserResizeHandler, although we could move those to another SWC an= d > >> say > >>>> that Core should not have any MXML components except maybe State. > >>>> > >>>> After any rename/refactor we decide on, Basic should still have some > >>>> interfaces because those interfaces describe the contract required f= or > >> the > >>>> simplest implementation. I get that it can be a fine line between > >>>> "fundamental" and "simplest", but where many classes that were in > Basic > >> get > >>>> away from "fundamental" is mainly around Containers. The way we > handle > >>>> Containers in Basic really seems like an opinion instead of a > universal, > >>>> "everyone must implement Containers this way" sort of thing. So it > does > >>>> not seem right that lots of Container-related things were moved to > Core. > >>>> > >>>> I thought we had agreement on the Terminology and Concepts thread th= at > >>>> re-usable pieces would be organized into multiple SWCs like Apache o= r > >> AS3 > >>>> Commons. Any component set designer gets to choose what SWCs to > borrow > >>>> from. The emulation SWCs may borrow from Express because they want = to > >>>> re-use multi-purpose beads and aren't interested in the smallest, > >> fastest, > >>>> implementation. Assuming we fix any issues with accidentally > dragging > >> in > >>>> classes that aren't used, if you can re-use code from some other gro= up > >> of > >>>> classes in another SWC, just do it. But do it because you "want to"= . > >>>> There is no "need to". The implementers should "want" to re-use cod= e > >> when > >>>> possible. > >>>> > >>>> In the end, many component sets will re-use Basic beads. Maybe even > >>>> transitively because they re-use Express which re-uses Basic. That > >> should > >>>> be ok. That doesn't make it Core. It just that lots of component > sets > >>>> will start from simple implementations and add more complex > >> functionality. > >>>> The goal is to minimize code size and maximize performance by re-usi= ng > >>>> code. And as I thought we had agreed upon in Terminology and > Concepts, > >> we > >>>> should not be afraid to re-use code. We are asking our users to do > >> exactly > >>>> the same. We must create testing infrastructure and have review > periods > >>>> and other processes so we don't break downstream component sets or o= ur > >>>> users applications. > >>>> > >>>> One related tidbit: IMO, the way folks will know what beads work wi= th > >>>> what components will be done by identifying what interfaces the bead= s > >>>> implement, but also, I expected that we would use ASDoc as well. If > you > >>>> rummage through the source, you'll see that I annotated a few classe= s > >> with > >>>> @viewbead and @toplevel. We could add more. And because our ASDoc = is > >> an > >>>> app, we can then apply smarter filtering that help folks narrow down > >> what > >>>> their choices are, similar to many of the online shopping filters I > see. > >>>> > >>>> My 2 cents, > >>>> -Alex > >>>> > >>>> > >>>> On 5/21/18, 3:53 AM, "Harbs" wrote: > >>>> > >>>> Thank you for this. > >>>> > >>>> There=E2=80=99s two groups of files that were changed: Interfaces = and and > >>>> Classes. > >>>> > >>>> In general, I would be more inclined to move interfaces than > classes, > >>>> but there are some things to consider: > >>>> > >>>> 1. There are still 17 interfaces in Basic. If the 5 that were move= d > >>>> belong in Core, what about the remaining 17? > >>>> 2. I don=E2=80=99t think we=E2=80=99ve come to an agreement on wha= t belongs in Core > >>>> and what belongs in Basic. > >>>> 3. I=E2=80=99d like to some to an agreement on a package name patt= ern. What > >>>> defines something belonging to a =E2=80=9Ccore=E2=80=9D path as oppo= sed to an =E2=80=9Chtml=E2=80=9D > >> path? > >>>> Some classes are in supportClasses and some had that removed from th= e > >> path. > >>>> What=E2=80=99s the logic? etc. > >>>> 4. How should different pieces (such as different bead types) be > >>>> defined in paths? (I don=E2=80=99t think we=E2=80=99re completely co= nsistent today.) > >>>> > >>>> I think we are coming to a conclusion on the CSS issues that Jewel > >>>> brought up. I think the CSS problems can be solved no matter whether > we > >>>> move things between packages and no matter wether we change package > >> paths. > >>>> I think the question on reorganization needs to be discussed on its > own > >>>> right. Do you agree with that? > >>>> > >>>> First organization of packages: > >>>> To me, there are two primary questions related to Core vs. Basic: > >>>> 1. What is the defining criteria for something to belong in Core a= s > >>>> opposed to Basic? > >>>> 2. Is there an issue with one component set (i.e. Jewel) to rely o= n > >>>> another (i.e. Basic). > >>>> > >>>> To be clear: I do believe that there is likely some reorganization > >>>> appropriate, but I=E2=80=99m not clear on exactly what and how. > >>>> > >>>> Depending on the answers to these questions, we can have a number = of > >>>> different courses of action. We might keep things very similar to ho= w > >> they > >>>> are. We might move things from Basic to Core. We might split Basic > into > >> two > >>>> packages. Other options? > >>>> > >>>> Regarding package paths: I don=E2=80=99t think there=E2=80=99s a s= ingle =E2=80=9Cright=E2=80=9D > >> answer > >>>> to that, but we do need to agree on a pattern that we all stick to. > >>>> Currently (even before any refactor) package paths feel like many ar= e > >>>> haphazard, and I often have difficulty guessing what the path is for= a > >>>> specific class. I also sometimes have difficulty guessing which > package > >> a > >>>> specific class belongs to. > >>>> > >>>> These are the high-level questions I have. > >>>> > >>>> Please allow me to focus on question #2. I find it easiest to > discuss > >>>> concrete examples, so I=E2=80=99m taking TextPrompt, but it=E2=80=99= s just an example. > >>>> Basic has a TextPromptBead. Jewel has TextPrompt. The code of the tw= o > >>>> classes are identical. I=E2=80=99m assuming TextPrompt was copied be= cause > >>>> TextPromptBead does not belong in Core (something I agree with), and > you > >>>> did not want Jewel to have a dependency on Basic. So my question is > >>>> (assuming CSS and classes not used are not copied), what is wrong wi= th > >>>> Jewel using the TextPromptBead in Basic? To me the advantage of usin= g > >> the > >>>> Basic bead is that there=E2=80=99s no code duplication and that help= s from a > >>>> development perspective (i.e. only a single place to fix bugs) and > from > >> a > >>>> perspective of code size in the resulting application (in case both > >> classes > >>>> are used somewhere). > >>>> > >>>> Harbs > >>>> > >>>>> On May 21, 2018, at 11:29 AM, Carlos Rovira > > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> as we talked I take the time to make a list of package name changes= . > >>>>> Finally 20 classes were changed from package. > >>>>> Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e879811 (in > >>>> red the > >>>>> changes to better following) > >>>>> > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/MXMLBeadView.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /MXMLBeadView.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/views/ContainerView.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html/beads/ContainerView.as. > >>>>> (1) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/views/DataContainerView.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ > >>>> html > >>>>> /beads/DataContainerView.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/GroupView.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /beads/GroupView.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/IBackgroundBead.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/ > >>>>> html/beads/IBackgroundBead.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/IBorderBead.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /beads/IBorderBead.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/IDropDownListView.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html > >>>>> /beads/IDropDownListView.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/IListView.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ > >>>> html/beads/IListView.as. > >>>>> (2) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/ITextFieldView.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/ > >>>>> html/beads/ITextFieldView.as (2) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/TextFieldViewBase.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html/beads/TextFieldViewBase.as > >>>>> (2) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/layouts/LayoutChangeNotifier.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /beads/layouts/LayoutChangeNotifier.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/models/ArraySelectionModel.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html > >>>>> /beads/models/ArraySelectionModel.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/models/ViewportModel.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ > >>>> html > >>>>> /beads/models/ViewportModel.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/supportClasses/Border.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/ > >>>>> html/supportClasses/Border.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/supportClasses/ContainerContentArea.as > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/ > >>>> html/supportClasses/ContainerContentArea.as. > >>>>> (2) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/supportClasses/DataGroup.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html/supportClasses/DataGroup.as > >>>>> > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/DataItemRenderer.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ > >>>>> supportClasses/DataItemRenderer.as (3) > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/MXMLItemRenderer.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ > >>>>> supportClasses/MXMLItemRenderer.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/UIItemRendererBase.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ > >>>>> supportClasses/UIItemRendererBase.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/supportClasses/Viewport.as > >>>>> frameworks/projects/Basic/src/ > >>>> main/royale/org/apache/royale/html > >>>>> /supportClasses/Viewport.as > >>>>> > >>>>> Some comments: > >>>>> > >>>>> (1) "views" should follow the same package structure we have with > >>>> other > >>>>> beads 8"models", "controllers"...) to be consistent. > >>>>> (2) should go to "core/beads/views" as well > >>>>> (3) item renderers that should normaly be used by final users could > >>>> go some > >>>>> kind of "itemRenderers" package, while base item redeemer classes > >>>> could go > >>>>> again to supportClasses. > >>>>> > >>>>> As Harbs said, if we agree in the change of packages, we should do > >>>> this > >>>>> well and perform some other changes that make all more consistent > >>>> though > >>>>> libraries. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Carlos > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> 2018-05-17 11:16 GMT+02:00 Harbs : > >>>>> > >>>>>> Definitely a plan. > >>>>>> > >>>>>> My guess is that if we agree on changing package paths, there will > >>>> likely > >>>>>> be other classes that should be considered. > >>>>>> > >>>>>> My preference would be to have this discussion after we finish the > >>>> project > >>>>>> refactor discussion because I think it=E2=80=99s going to be relat= ed to the > >>>> outcome > >>>>>> of that. > >>>>>> > >>>>>> Either way, I don=E2=80=99t think discussion should hold up the 0.= 9.3 > >>>> release. > >>>>>> We=E2=80=99re already past due for a release. We want to =E2=80=9C= release early and > >>>> release > >>>>>> often=E2=80=9D=E2=80=A6 ;-) > >>>>>> > >>>>>> Thanks, > >>>>>> Harbs > >>>>>> > >>>>>>> On May 17, 2018, at 12:07 PM, Carlos Rovira < > >>>> carlosrovira@apache.org> > >>>>>> wrote: > >>>>>>> > >>>>>>> Ok, > >>>>>>> > >>>>>>> what if: > >>>>>>> > >>>>>>> * I take the time to generate a list of classes with package name > >>>> changes > >>>>>>> * Make a thread with the list to expose it > >>>>>>> * Let's see from there if people can live with it (We'll call > >>>> people to > >>>>>>> express about this changes and could see if are or not dramatic t= o > >>>> them) > >>>>>>> > >>>>>>> Sounds this like a plan? > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2018-05-17 10:58 GMT+02:00 Harbs : > >>>>>>> > >>>>>>>> Sure. Same here. > >>>>>>>> > >>>>>>>> But things are much more stable now. As we move closer to =E2=80= =9C1.0=E2=80=9D, > >>>> I think > >>>>>>>> we should be more careful about breaking changes and documenting > >>>> them > >>>>>> when > >>>>>>>> we decide they are necessary. > >>>>>>>> > >>>>>>>> As far as these specific changes go: We haven=E2=80=99t even com= e to a > >>>>>> conclusion > >>>>>>>> on what (if any) package names should change yet, and including > >>>> those > >>>>>>>> changes in a release is premature. If we do change package names= , > >>>> I=E2=80=99m of > >>>>>>>> the opinion that they should be decided on and all happen at onc= e > >>>> to > >>>>>>>> minimize impact on end-users. > >>>>>>>> > >>>>>>>> Does that help clarify things? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Harbs > >>>>>>>> > >>>>>>>>> On May 17, 2018, at 11:49 AM, Justin Mclean < > >>>> justin@classsoftware.com> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>>> We are at the point where people are using Royale in > >>>> production. While > >>>>>>>> we can make breaking changes if they are warranted, they should > >>>> be kept > >>>>>> to > >>>>>>>> an absolute minimum and be carefully considered and well > >>>> documented if > >>>>>> we > >>>>>>>> do. > >>>>>>>>> > >>>>>>>>> There has been many previous breaking changes that broke the > >>>>>> application > >>>>>>>> I was working on and some more major than this and cost me a lot > >>>> of > >>>>>> time to > >>>>>>>> fix. Until you make it version 1.0 I think people will expect > >>>> that some > >>>>>>>> things may break with a new version. So why should this be an > >>>> exception > >>>>>> to > >>>>>>>> what has happened before? Saying that however, what would be goo= d > >>>> to > >>>>>> see is > >>>>>>>> to provide guidance to what users need to change so their app > >>>> works with > >>>>>>>> any changes / backward compatibility issues. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Justin > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Carlos Rovira > >>>>>>> https://na01.safelinks.protection.outlook.com/?url=3D > >>>> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=3D02%7C01%7Caharui%4 > 0adobe.com% > >>>> 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de > >>>> cee1%7C0%7C0%7C636624967805497091&sdata=3DbdXVzZzjutIIwP9lWwAj > osfP3JsQDt > >>>> rkTp%2FcrETCLE4%3D&reserved=3D0 > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Carlos Rovira > >>>>> https://na01.safelinks.protection.outlook.com/?url=3D > >>>> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=3D02%7C01%7Caharui%4 > 0adobe.com% > >>>> 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de > >>>> cee1%7C0%7C0%7C636624967805497091&sdata=3DbdXVzZzjutIIwP9lWwAj > osfP3JsQDt > >>>> rkTp%2FcrETCLE4%3D&reserved=3D0 > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Carlos Rovira > >>> https://na01.safelinks.protection.outlook.com/?url=3D > >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=3D02%7C01%7Caharui%40adobe.c= om% > >> 7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636625234021648344&sdata=3DVP%2BrBk%2FGm2iYVLGKZBb5W% > >> 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=3D0 >> protection.outlook.com/?url=3Dhttp%3A%2F%2Fabout.me% > >> 2Fcarlosrovira&data=3D02%7C01%7Caharui%40adobe.com% > >> 7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636625234021648344&sdata=3DVP%2BrBk%2FGm2iYVLGKZBb5W% > >> 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=3D0> > >> > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > --=20 Carlos Rovira http://about.me/carlosrovira --00000000000045c8c5056d5923a9--