Hi Harbs,
2018-05-14 14:23 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> I think I still did not make myself clear.
>
> I’m not talking about someone only using Jewel. I am talking about an
> application which uses BOTH a Jewel Panel *AND* a Basic Panel (or Button,
> TextInput, etc.). The problem I’m discussing has nothing to do with whether
> Jewel extends Basic or not. I’m trying to come to an understanding 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’m working under the assumption that component sets are not necessarily
> mutually exclusive and users might use components of the same name in their
> apps from two different component sets. I’m assuming that conflicts 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 “jewel button” instead of “Button”. It’s 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’m not trying to pin down solutions yet. I’m first trying 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 <carlosrov...@apache.org>
> wrote:
> >
> > Hi Harbs,
> >
> > 2018-05-14 10:14 GMT+02:00 Harbs <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>>:
> >
> >> Hi Carlos,
> >>
> >> I’d like to work on getting this discussion as focused as possible. Once
> >> we’re clear on the problems, it’s much easier to find a solution which
> is
> >> acceptable to everyone. I think part of the miscommunication until now
> was
> >> that the discussion focused on solutions rather than problems. I’m
> 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’d also like to avoid lengthy emails as much as possible to make
> >> everything easier to digest. I’m going to leave out anything I don’t
> think
> >> is core to the discussion.
> >>
> >> First of all, I think we can take 1b and 1c out of the discussion. If 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 plan on
> >> discussing all the points, but I think it would be easiest to resolve
> >> issues one at a time. I’ll start with what I believe to be the one we’re
> >> 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 not
> >> 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 “Panel”, and there’s 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 best
> 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 splicitly
> code
> > an override.
> > Extending a final component brings all that is defined with him, so if
> 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" since if
> > you remove the current you'll get what is below. My opinion is that we
> > 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 “basic" prefix and Jewel
> >> typenames to have a “jewel" prefix. If that solution is used, then
> problem
> >> 1a goes away. There might be other solutions which don’t solve 1a. I
> don’t
> >> 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’t want to interject my thoughts before discussion is started 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 both
> 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 it?
> >>
> >
> > 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 exposed
> just
> > before), we have many ways to reach the same. But IMHO, I'm mostly like
> > 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 <carlosrov...@apache.org>
> >> wrote:
> >>>
> >>> Hi Harbs,
> >>>
> >>> 2018-05-13 10:40 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> >>>
> >>>> 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 avoiding
> to
> >>> introduce more noise.
> >>>
> >>>
> >>>>
> >>>> I’m a bit disappointed that we’re moving towards a vote before I
> believe
> >>>> we’ve 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 seems
> >> what
> >>> all of you demand at that point.
> >>>
> >>>
> >>>> Let me try and summarize the technical reasons as I see them for and
> >>>> 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 use
> >>>> ButtonBar, but ButtonBar and all related classes are included in the
> >> 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
> “basic”,
> >> but
> >>>> “core” and should be moved to the Core project. Doing so has the
> >> following
> >>>> benefits:
> >>>> a. There’s a clear separation of dependencies.
> >>>> b. Someone working on Jewel does not need to be concerned with the
> >>>> architecture of Basic.
> >>>>
> >>>> I’m not aware of any other arguments which are not variations 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’s natural for component sets to borrow 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 both
> 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 right
> >> Bead?
> >>> the right control?...If he optionally wants to add functionality, is up
> >> to
> >>> him to use one or another.
> >>>
> >>>
> >>>> 2. Moving pieces of Basic to Core does not scale. We need to define
> what
> >>>> Core is, and claiming that something is required by a component set
> >> 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’s why there are lots of interfaces, but
> >> not so
> >>>> many implementation classes. It’s possible that little bits 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 possibly
> 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 example,
> 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 this
> >> 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 that
> >> 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 extract
> >> 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’t actually solve the problems it’s meant to solve.
> Please
> >>>> allow me to explain:
> >>>>
> >>>> 1b and 1c are actually bugs. I’m 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 job of
> >> only
> >>>> using the css and classes where are *actually* used, these two issue
> 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’s actually a fourth problem related to CSS. What happens if a
> >> single
> >>>> app uses a Basic Button, an MDL Button and a Jewel Button? (As to why
> >> that
> >>>> might happen — components can be used within other components 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’m not even sure which CSS will
> >> win.
> >>>> It seems to me that typenames really should be qualified to prevent
> >>>> namespace conflicts. I’m 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 is
> >>> 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 developer)
> use
> >>> to fight each day when design a new control for MDL or Jewel, and If 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 Jewel
> 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’s my thoughts: I don’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 needs
> 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 little
> >>>> isolated corner. As difficult as it might be to deal with others’
> >> opinions
> >>>> and it causes things to drag on longer than it otherwise might, I
> think
> >>>> it’s 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’t
> >>>> know how to put that empathy into an email. It’s a poor medium for
> that.
> >>>> Ultimately, the more we rely on each other, the better the quality of
> >> the
> >>>> end product will be — even if it takes us longer to get there… ;-)
> >>>>
> >>>
> >>> Well, as I said to Yishay, I think separation brings flexibility and
> >> 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 depend
> 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 in
> >>> 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 more,
> >> 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. Since
> >> 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 <carlosrov...@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 this
> >>>>> 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 Application.
> >> 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 although
> 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 Slider,
> 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 from
> >>>> 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 of an
> >> UI
> >>>>> set, was in fact needed in all Royale Applications, and that cause
> 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/JqO2ZI.jpg>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. People
> >> using
> >>>>> Basic, will use it I the same way and get exactly the same. So this
> >>>>> 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 still
> >> 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. Normal
> >> 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 HTML
> >> 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 in
> 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 start
> 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 Jewel
> >>>> 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 present
> >> that
> >>>>> they don't need (CTRL+SPACE will only throw one kind of Button now
> >>>> 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) and
> >>>>> 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 <http://about.me/carlosrovira>
>
--
Carlos Rovira
http://about.me/carlosrovira
