Hi Harbs, 2018-05-21 12:52 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> Thank you for this. > > There’s 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 moved belong > in Core, what about the remaining 17? > I still didn't have to deal with the rest, but normaly when I'll complete more Jewel components I'll do. As well, I'm pretty sure that I'll need those interfaces, what will mean that are Core and needs to be moved to Core project. The other thing to take into account is what we are discussing in this thread, if I can put in a right core package or not. > 2. I don’t think we’ve come to an agreement on what belongs in Core and > what belongs in Basic. > I think that's not the focus of this thread, maybe we should discuss in other? My understanding is that all pieces needed to make a UI set should go in Core, so Jewel, Basic, and the rest can use it without the need to use things in others sets. > 3. I’d like to some to an agreement on a package name pattern. What > defines something belonging to a “core” path as opposed to an “html” path? For me is simple: classes in Core lib should be in "core" package. Things in Basic lib, "basic" package, and so... mixing seems confusing and it seems that we do not have the house clean. package, classes and method names and signatures are very important. Is what we expose to users, and what they'll finally be using. > Some classes are in supportClasses and some had that removed from the > path. What’s the logic? etc. > I think this is something to unify now. There's lot of this all over Royale. We have the change on make some work this days to unify the packages. We can take the ones that have different approaches and unifies all of them. I think now is better than later. I think we can't go 1.0 without do this. After 1.0 we'll be mostly "freeze". > 4. How should different pieces (such as different bead types) be defined > in paths? (I don’t think we’re completely consistent today.) > RIght, I think if we have "models" and "controllers" packages, we should have as well others like "views" and maybe even organize beads that applies to controls. How do we expect users to find the beads that apply to a particular control? If we have "beads/controls/textinput" and inside all TextInput beads, that should be more easy for a user to know what's available. If not he can miss some functionality, or never know that already exits. For beads that are usable cross controls "beads/controls" will be the best place. As well to make beads less verbose, I'll vote to remove "Bead" from the class name, since the package already indicate that is a bead. composition is more verbose to declare, and it's the main point against it for what I listen from people. We should try to make names as short while descriptive as possible. > > 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? > Right, I always said that package changes was not something needed for UI Sets independence. Just said the package changes were advisable to do. IMHO, that was not the focus at that time, and I think we can do our best on this focusing on it to get the best final snapshot. > > 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 as > opposed to Basic? > For me Core is what is needed to build any UI set we want to support (Jewel, Basic,....), or other libraries that uses as well common functionality. Is the required building block in every royale application. > 2. Is there an issue with one component set (i.e. Jewel) to rely on > another (i.e. Basic). > For me clearly. Making set independent we have more flexibility. And we're preparing Royale for the needs of the future. In this way a Royale 2.0 version would be far more easy to develop, and to make existing user not be affected by important changes that a major version will introduce. We can avoid the problems other did like in Flex, or even more neat in time Angular 1.x to 2.x and so. For me independence is clearly a winner feature. > > To be clear: I do believe that there is likely some reorganization > appropriate, but I’m not clear on exactly what and how. > It's only a matter of focus a discussion on it like we did on the rest of points. > > Depending on the answers to these questions, we can have a number of > different courses of action. We might keep things very similar to how they > are. We might move things from Basic to Core. We might split Basic into two > packages. Other options? > I think that's mostly the current options available now. One thing is clear: libraries with resources that wire beads through CSS should not be obligated to be linked in any application. That should be something to be choose by Application developers. So we can extract from Core and Basic beads and things that are needed but not core to a new library. For example reusable beads could go to "CoreBeads" or simply "Beads"... > > Regarding package paths: I don’t think there’s a single “right” 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 are 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. > We can post a list of proposed packages as a rule. I think this kind of things for final applications is less important, but not for framework developers like us in Royale, this matters to make more easy the work for the next layer (application developers) and make its life more easy. > > 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’m taking TextPrompt, but it’s just an example. > Basic has a TextPromptBead. Jewel has TextPrompt. The code of the two > classes are identical. I’m assuming TextPrompt was copied because > 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 with > Jewel using the TextPromptBead in Basic? To me the advantage of using the > Basic bead is that there’s no code duplication and that helps 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). > If the Bead is identical we can make a intermediate library to host all of this. Notice that some beads would not be possible since in Jewel will need to be different. In the other hand as I notice before, we can use this to refactor packages and names. Before I mention the convenience to reduce names. <beads> <js:TextPrompt/> seems less verbose, more elegant and equally efective than <beads> <js:TextPromptBead/> right? For me a final point in all of this is namespaces: To get the best final picture I can envision, I think all beads, core and common libraries should have its own namespace like: xmlns:r="library://nx.apache.org/royale/royale" then left others to concrete ui sets like: xmlns:js="library://nx.apache.org/royale/basic" or xmlns:b="library:// nx.apache.org/royale/basic" (since seems "js" prefix, although is something that the user can choose seems very strange taking into account our future mission to be platform independent) xmlns:j="library://nx.apache.org/royale/jewel" xmlns:mdl="library://nx.apache.org/royale/mdl" Thanks Carlos > > Harbs > > -- Carlos Rovira http://about.me/carlosrovira
