royale-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aha...@apache.org
Subject [royale-asjs.wiki] branch master updated: Updated Terminology and Concepts (markdown)
Date Tue, 15 May 2018 05:41:59 GMT
This is an automated email from the ASF dual-hosted git repository.

aharui pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/royale-asjs.wiki.git


The following commit(s) were added to refs/heads/master by this push:
     new ef40e38  Updated Terminology and Concepts (markdown)
ef40e38 is described below

commit ef40e3808e38be241079258060d301bb0e250afc
Author: aharui <aharui@apache.org>
AuthorDate: Mon May 14 22:41:57 2018 -0700

    Updated Terminology and Concepts (markdown)
---
 Terminology-and-Concepts.md | 45 +++++++++++++++++++++++++++++++++++----------
 1 file changed, 35 insertions(+), 10 deletions(-)

diff --git a/Terminology-and-Concepts.md b/Terminology-and-Concepts.md
index 08ea1a3..632a960 100644
--- a/Terminology-and-Concepts.md
+++ b/Terminology-and-Concepts.md
@@ -28,29 +28,54 @@ A component set is a set of TLCs and any source files needed to implement
the TL
 
 A Strand is an array of beads.  An individual bead can also provide a strand and thus have
its own beads.
 
+### CSS Kinds
+There are three kinds of CSS in Royale
+
+* **ClassReferences**  These define default beads required for operation.  ClassReferences
are not CSS compliant.
+* **Visual CSS**  This is compliant CSS that affects what the pixels are
+* **Positional CSS**  This is also compliant CSS that affects structure (display, position).
IOW, where the pixels are.
+
 
 ## Concepts
 
-Primary Goals:
+### Primary Goals
 
 First and foremost, we want to keep an eye on these primary goals when making framework decisions.
 
-1) Code Size and Performance.  These two often have trade-offs against each other.  For example,
inline code is faster, but means more code.
+* Small Code Size
+* Fast Performance  
+
+These two often have trade-offs against each other so one is not more important than the
other.  For example, inline code is faster, but means more code.
 
 
-Execution Goals:
+### Execution Goals
 
 How do we achieve small code size and good performance?  By executing with the following
in mind:
 
-1) Pay-as-you-go (PAYG)  
-1) Re-use as much code as possible.  
-2) Choose Composition over inheritance in most cases
-3) Use Inheritance and utility functions in other cases
+1. Pay-as-you-go (PAYG)  
+2. Re-use as much code as possible.  
+3. Choose Composition over inheritance in most cases
+4. Use Inheritance and utility functions in other cases
 
-Organization Goals:
+### Organization Goals
+
+We want to support multiple component sets.  Users may mix-and-match TLCs from various component
sets, but that should be relatively rare since, once you have used a more complex TLC, there
are few code size savings to also using a simpler TLC.  What is more likely is that users
may mix and match beads from various component sets.
 
-We want to support multiple component sets.  Users may mix-and-match top-level components,
but that should be rare.
 Beads should be organized into SWCs with other beads they have something in common with.
 So MaterialDesignLite, CreateJS, Basic, Jewel, Express all will contain beads specific to
what they do.  Basic does simple implementations.  Express rolls up Basic beads into aggregates.
 
-Other Goals:
+### Other Goals
 Backward compatibility will become more important after 1.0 but don't do too many name changes
without getting agreement first.
+
+### Subclassing  
+Because TLCs are always compositions, there is less value to subclassing them.  There is
less code to re-use.   TLCs are primarily reserved for Application Developers since the MXML
component model must use subclassing.  Thus, there should be no "final" TLCs.  Subclassing
TLCs can also be used within a component set if it helps code reuse or styling.  TLCs are
just examples and labels for popular compositions of beads.
+
+On the other hand, subclassing is commonly used in creating beads (and always used in base
classes).  
+
+### Exploded Component
+Any Top-Level Component should be able to be approximated in MXML by using the base class
and beads.  This is known as the "exploded component".  The code in the Top-Level Component
should proxy model properties and hopefully do little else.  The beads should not ever reference
the Top-Level Component, only the Strand.  That allows the exploded component to work and
makes it easier to re-use the beads in other component sets or as base classes for beads in
other component sets.  
+
+### CSS
+
+* **ClassReferences** Missing ClassReferences are likely to cause major failures.  Thus they
should be specified in the containing SWC's defaults.css.
+* **Visual CSS** should go in theme SWCs
+* **Positional CSS** can be hard-coded into layout classes or specified in class selectors
and referenced by layout classes.
\ No newline at end of file

-- 
To stop receiving notification emails like this one, please contact
aharui@apache.org.

Mime
View raw message