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

Reply via email to