royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <>
Subject Re: Container change
Date Thu, 10 May 2018 12:02:28 GMT
2018-05-10 13:41 GMT+02:00 Harbs <>:

> Hi Carlos,
> Thank you for summarizing your reasons. I appreciate it.
> Please allow me to categorize your reasons. Please let me know if I’m not
> categorizing them correctly.
> When I mentioned reason #1, I think it includes:
> #3, #5 and #7

For me 3,5,7 are not something about "philosophy", are pure technical
structuration of code. If you want to left as is, is because you're talking
from an Application ser not from an archictecture point of view or with the
team member hat.

> #2 AFAICT includes #4. As I mentioned the fact that there can be
> conflicting typenames is a problem. Removing Basic as a dependency will not
> solve that problem because clients can (and likely will) bring in Basic as
> part of their application.

There's much difference in obligation to link a library and decision to
make part of your solution. We as Royale PMCs should make the best for not
obligate, the user is how could want then to use Jewel, MDL and Basic all
together. Is up to them.

> I really don’t understand your point with #6. Why do application
> developers need to think about dependencies? Is it because of Maven
> dependencies? If so, that seems to be a Maven problem which should be fixed
> there.

Not App developers, We are how need to be careful on this. In the same way
we are pushing hard on PAYG, to avoid mistake of the past like 15k lines
UIComponent class, We need to always be careful and don't make unneeded
relations. And Basic -Jewel is totally unneeded.

> Please explain why you think $8 is true. What about the refactoring will
> reduce the size of applications?

I explained just in a Yshay response. copying the entire email response
here. But rather to make me repeat or copy I though you read all this
thread carefully:

"I think the problem is that Basic UI set links things through CSS, so If I
have Application, Group, View, Button all this components and more has CSS
that links beads (ViewBeads, ModelBeads, ControllerBeads, and more)

In Jewel until the refactor the components where sublcassing Basic ones,
and this made all this classes go in the Jewel Application, and that not
only introduced more size but makes the behaviour unexpected since I find
css styles and linked classes modifying the Jewel Behavior.

Now that Jewel is not depending on Basic anymore, since it should be, all
works perfect.

I think this is key, in a tree graph we should envision, Core as the root
of the tree, and when coming to UI sets that in royale we coincide in
having many of them, one should not depend from the other. And by design
that's important, and will prevent people in the future to come back to
make relations between them. In fact Alex, said many times the errors
coming from 15k lines of code in UIComponent in Flex. If we left UI sets
depend at library level, people can start to make that kind of extension,
and that should not be doable by design."

> As I mentioned earlier, Basic is not simply a component set. It’s also a
> set of building-blocks which can and should be used in other component
> sets. Devision between Core and Basic is not as clear-cut as you seem to be
> asserting that it is. After your refactor the building blocks seem to be
> split between Core and Basic.

That's not what I talked in the past in this mailing list. Alex said that
people would want to use Basic for things very basic and more complex UI
sets for other things. In fact Jewel born to be more visual attractive, so
for Jewel, all building block regarding UI should be from itself, and
prevent to mix with things in Basic that will (or could) evolve in other

My refactor was searching a goal, separation. But as many things can not be
final. After it, we can think a bit more on how things are settle now, and
continue to improve it, to make Core real core, and Basic a UI set that
could be has it's own essence without make it to mix in other libraries
that should not need it.
I think we should continue improving this instead of wanting again to have
a mess between all this libraries and packages mixed in libraries like core
and html.

But for this to happen, we must focus in why the JSONLY build is different
from the main one, and if ANT fails, that shouldn't, that I'm still don't
know if we have a problem there


> Thanks,
> Harbs
> > On May 10, 2018, at 2:13 PM, Carlos Rovira <>
> wrote:
> >
> > Hi Harbs
> >
> > after 75 emails on this thread, understand that I don't want to again
> write
> > it, since this is making me waste lots of time in this discussion.
> >
> > 3) Having the need to link a library that should not be used, is that
> > something is wrong, so it's not about 1) it's about things are not
> setting
> > correctly, and this refactor tries to fix that at least to put a point in
> > wich we can make things better.
> > 4) aside 2, some classes are linked via CSS as well (Application, Group,
> > Container, Button, Slider, and many more
> > 5) Having Basic to be a core dependency, makes it Core in itself, so why
> > the separation Core- Basic if I'm obligated to link it?
> > 6) Making Basic not present in libraries that doesn't need it, makes
> people
> > obligated by design to avoid extend Basic classes making the effect but
> > time that things mess between libraries, and obligates SDK developers to
> > think about the using of classes, since if we need some, maybe that will
> be
> > Core and not Basic
> > 7) Basic is only another UI set at the same level or sibling like Jewel,
> > MDL, CreateJS, Flat, and more we want to do, until now was very needed,
> but
> > if we want to make Royale to serve general purpose, making it to be
> present
> > always is not the right way to go.
> > 8) reduced size in final jewel applications.
> >
> > I think for sure I put more things on the plate, but can't invest now the
> > time to go all 75 emails to retrieve it
> >
> >
> >
> > 2018-05-10 12:48 GMT+02:00 Harbs <>:
> >
> >> The only reasons I seem to have seen are:
> >> 1. A philosophical opposition to having Basic as a dependency.
> >> 2. Not wanting Basic CSS included in a Jewel project.
> >>
> >> Unless I’m missing something, #1 I simply disagree with.
> >> #2 sounds like a valid argument, but it seems to me more like something
> >> which needs to be fixed in the compiler. CSS not used by an app should
> not
> >> be included and I think we need a way of avoiding typename conflicts
> >> between component sets.
> >>
> >> Are there other arguments which I missed?
> >>
> >> Since Carlos does not seem to want to explain himself again, I’m asking
> >> others on the list:
> >>
> >> Do others understand why Carlos feels the refactor is important?
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On May 10, 2018, at 1:32 PM, Carlos Rovira <>
> >> wrote:
> >>>
> >>>> Can we please keep this discussion about the technical reasons for a
> >>>> refactor and whether or not it’s the right thing to do? If you have
> >> strong
> >>>> technical reasons why Basic should not be a dependency please explain
> >> them.
> >>>>
> >>>
> >>> Harbs, I'll explained lots of time, and you keep ask the same. What did
> >> you
> >>> not understand of the things I expressed so many time?
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> >

Carlos Rovira

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message