Re: [Discussion] Package change names (was Re: 0.9.3 Release)

Hi Alex, 2018-05-30 5:53 GMT+02:00 Alex Harui : > FWIW, I think there is still a disconnect here. Right, I think we are mostly on consensus about refactoring names and packages and how to deal with CSS names, but the final point (maybe most important) is about the dependency library that I thin

Re: 0.9.3 Release

I don't care what version number we give it as long as it is <1. I'm more concerned about what commit hash we are going to use. I see a great discussion going on about package re-organization, however, that is probably not going to be ready to release soon. My 2 cents, -Alex On 5/26/18, 6:2

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

FWIW, I think there is still a disconnect here. After looking at Carlos's diagram with a Foundation layer, maybe the confusion is around how to think about Composition-based instead of Inheritance-based components. There should be no desire to make every component set use only things from a si

Re: [Discussion] Summarizing all discussion about Royale organization and structure

Hi Olaf, you're right. This change is not for free. We should make a good job on classification. In the other hand think that we are trying to setup an scenario that will be there for every 1.x releases. So once we make all this changes they'll be fixed since 1.0 means stability and we have to liv

Re: [Discussion] Summarizing all discussion about Royale organization and structure

> I agree that beads could use organization. My understanding of these beads is that in the best case, they could be applied to various actors (DRY). Even if it's probably a good idea to organize those beads, isn't there also a danger to end up with more chaos? Imagine if somebody implements an

Re: [Discussion] Summarizing all discussion about Royale organization and structure

Hi Harbs, Right, what I'm doing in Jewel follows that pattern, but it be improved even more, since, although I use to take care while developing, sometimes I get points to improve things With that schema, I think is a matter to start make it happen in a branch. Is like a picture, we can talk about

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

Hi 2018-05-29 17:44 GMT+02:00 Harbs :. > > > OK. I define Core a bit differently. Core defines the *architecture* or > “scaffolding” of a Royale application. I don’t believe a Royale application > can be compiled from Core alone. > > Core is assumed to be a prerequisite for almost all other Royale

Re: [Discussion] Summarizing all discussion about Royale organization and structure

Do you have ideas for a naming structure? > On May 29, 2018, at 5:50 PM, Carlos Rovira wrote: > > +1 Agree. > > 2018-05-29 16:35 GMT+02:00 Harbs : > >> I agree that beads could use organization. >> >> Model view and controller are easy ones. The rest of the categorization is >> harder. >> >>

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

> On May 29, 2018, at 5:34 PM, Carlos Rovira wrote: > > Hi > > 2018-05-29 16:00 GMT+02:00 Harbs >: >> >> >> 1. How do we define what is “Core"? >> > > *Core*: This classes are needed to build a Royale > > Application. All pieces here are required. No CSS is p

Re: [Discussion] Summarizing all discussion about Royale organization and structure

+1 Agree. 2018-05-29 16:35 GMT+02:00 Harbs : > I agree that beads could use organization. > > Model view and controller are easy ones. The rest of the categorization is > harder. > > Layout is also pretty well defined. > > Here’s the rest of the categories I could come up with: > > ItemRenderer f

Re: [Discussion] Summarizing all discussion about Royale organization and structure

I agree that beads could use organization. Model view and controller are easy ones. The rest of the categorization is harder. Layout is also pretty well defined. Here’s the rest of the categories I could come up with: ItemRenderer factories General factories (i.e. MenuFactory) Beads that add v

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

Hi 2018-05-29 16:00 GMT+02:00 Harbs : > > > 1. How do we define what is “Core"? > *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 r

Re: [Discussion] Summarizing all discussion about Royale organization and structure

About beads: Right now all beads are mixed and the major problem I experience is to know what beads already exists and where I can find that code. For that reason, my proposal is to have a "bead" package, and then organize beads in sub packages: "views", "models", "controllers", then for controls:

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

Perfect. I think we did a great job on the css part of this discussion. Let’s see if we ca come to a meeting of the minds on the rest. :-) Let’s try and figure out what we all agree and don’t agree on. The important pieces I see are: 1. How do we define what is “Core"? 2. Should package names

Re: [Discussion] Summarizing all discussion about Royale organization and structure

> On May 29, 2018, at 4:48 PM, Olaf Krueger wrote: > > Hi Carlos, > > thanks for summarizing all this stuff. > > @all > I have not followed all the discussions, but I would like to ask if that > what Carlos has presented is consensual. Foundation Is what Carlos is proposing as a new way of o

Re: [Discussion] Summarizing all discussion about Royale organization and structure

Hi Carlos, thanks for summarizing all this stuff. @all I have not followed all the discussions, but I would like to ask if that what Carlos has presented is consensual. >Remove "Bead" ending from beads to make it all less verbose. Are there still any other ways of recognizing a bead then? Or

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

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 onthis will take some days to reach a good sh

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Hi, right, I, in fact, try to use the format "org_apache_royale_html_Button", but seems very cumbersome to me and for that reason in Jewel I write like in Semantic ".jewel.button", since this is more friendly with CSS, less verbose and more flexible 2018-05-29 14:47 GMT+02:00 Harbs : > > I like

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

Sorry for my delayed response to all of this. I’ve been kind of out of it… Can we try and get clear on the problems? I’d really like to figure out what we agree on before we try to nail down a solution. I’d like to start with Alex’s list: > First, the hopefully easy things we can agree on: > -I

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Sorry for the delay in response here. I was not feeling very well last week… (I forgot how much work an infant is…) ;-) I think it’s time to wrap this up. I don’t think there’s any completely PAYG solution to this problem. I think conflicts need to be prevented by default. I like the metadata