I'm replying to my post again even though it isn't the latest. At the end I
address what I think is a misconception that I saw in those more recent posts.
> We want these beads, even high level beads, to be re-usable in multiple
> components sets.
Key word here is *optional* not *mandatory*. Take this in mind, since while
I have the option to use it or not, I even should have the option to link
it or not, since there's no obligation or requeriment to use.
Everything is currently optional the way we have it, but the principle of code
re-use is primary. Copying code to avoid a project dependency is not a
recommended practice.
> There may be a SuperJewel someday or variants on Jewel with completely
> different names that borrow beads from Jewel under the principle of
> re-using code.
That will requiere that SuperJewel links Jewel to use it, as well Express
need to link Basic. CreateJS does need to link Jewel, that will be
pointless.
> The Emulation set will probably use Jewel views.
Hope so, so MXRoyale will link Jewel since it needs, while Basic not since
it never will use it.
The Emulation set will use Basic beads for models and controllers and lots of
other things, if the simple implementations suffice.
> Our users have asked for our component sets to require little
> configuration, so Jewel should re-use Express beads.
>
Can give an example of a reusable Express bead in Jewel. FWIK Express is an
aggregation of Basic UI Set, so it makes less need of configuration in
final code, so a Button can integrate Disabled bead. Don't have in mind a
reusable case of Express in Jewel, since Jewel doesn't use Basic at all.
I mentioned this before. The DataGridModel in Express is type-agnostic
(dataProvider is Object) whereas in Basic is assumes the dataProvider is an
Array. And you can configure the Basic one to use different dataProviders of
different types. That's on purpose, for PAYG (no extra code to handle
different types) and to help folks ensure type-safety. But our users want less
configuration so you can pass "anything" into Express DataGrid's dataProvider,
just like Flex.
>
> I think you are making the argument for doubling the number of SWCs so
> that beads go in a SWC and TLCs that use those beads go in a separate SWC.
Doubling no, jut one: Foundation - Basic. The rest is up to discussion, but
since are not required right now (are already not linked or mandatory) like
MDL, CreateJS, and more, I'm fine with it. I recommend in the future
refactor as well, but that should be made by volunteers if they want
I think that's inconsistent. If you agree above that some other component set
can re-use Jewel Views, then you will need to break Jewel beads out into a
separate SWC as well according to your arguments. And that will double the
number of SWCs. Instead, I think we have ways to use the current organization
to address your concerns about extra CSS processing.
> There isn't an Apache Commons analogy for that since JARs are dynamically
> linked. But in statically-linked libraries like C/C++ on Windows, the
> compiler does visit entire libraries and only links in what is needed.
>
But links all existing available libraries? when you program in C++ you
link what you need. So in Royale there's no point to link a Basic UI Set
(TLCs and CSS) if I'm going to not use it, but use another one.
The user is in complete control over the number of SWCs that get read in, even
for Ant, IDEs and command-line users. The compiler only reads in the SWCs it
is told to read in. The default royale-config.xml currently uses a wildcard.
Will it always? Maybe not if we someday have enough SWCs that reading them all
in becomes a problem. If you specify the exact set of SWCs that you would in
a Maven pom, you will enjoy the same benefits of the compiler only reading
those SWCs, if any. It is simply a trade-off of configuration effort vs
compile-time. Also having more SWCs get loaded should mean more options
offered in code-hinting which is, IMO a good thing for now, but probably not in
the future. So, don't be worried about how many SWCs get read in. Users can
control that.
I am going to try to move the exclude-defaults-css to the loading phase instead
of the output phase. I think once I finish that and Harbs finishes removing
class selectors we can see if there are any remaining issues or concerns with
the current set of libraries.
HTH,
-Alex
