Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Carlos Rovira]

Hi Alex,

I think we are saying the same in essence.

I want to reuse beads. So lets take "TextPrompt" bead and have only one in
all Royale (always that make the same of course), think that is in a
library called "Foundation" that depends from Core but is not core. Seems
"Foundation" is a name less confusing than Basic. All UI sets, link this
foundation library and take what they want from it. Normally all UI sets
will borrow "TextPrompt" bead. The same with the pieces in you DataGrid
example.

In the other hand, UI sets has its own implementation of "Button" (and the
rest of components), and the CSS that wires all the beads used in that
concrete Button, and the rest of controls and components in that UI Set. I
think we all said that we want to reuse, but we don't want to use a CSS
from other UI set. So this concrete implementations of controls and
components and the CSS should go in each library, and so we'll have Basic,
Jewel, MDL, CreateJS,...

Have sense to have Basic CSS and controls in Foundation? for me clearly no,
since Jewel will not use it at all. Will use Foundation classes, (in your
example DataGrid pieces to reuse almost all of it). Will use the CSS that
wires all beads used in Basic, clearly not. So the code that goes in each
UI set library is clearly not reusable at all, and we don't want the
compiler to take extra time processing the CSS that wires all beads from a
UI Set that will not be used right?.

The opposite will be "lets take all ui set implementations (Basic, Jewel,
MDL, CreateJS,...) and mix altogether in a unique Foundation library with
all control and components implementations and all the CSSs that wires the
beads". Make this sense? For me clearly not. Moreover, in this case why
have libraries for Network, Binding, Collections...? Hope this extreme case
showcased makes more sense to explain.

If we want to reuse lets go and reuse, I'm all for it, but we shouldn't
have the CSS that binds all together for a UI Set that will not be used
since doesn't support anything in the normal use. And all of this even if
we get rid of the current bugs that brings lots of things to the final bake.

I think a library or SWC is in essence a reusable piece, but we not link
all existing SWC for all projects since we know we'll not using *all*
available SWCs we have, and since we don't want the compiler process all
CSSs in all that libraries all the time, since is time consuming. For this
reason we create the current SWC libraries, since if people will not use
Network, they normally don't link, if they use Basic, but not Jewel, MDL,
and CreateJS, those are not linked.

Finaly, if I'll not use Basic...then I don't want to be obligated to link
Basic (basic controls, and CSS) but I want to link Foundation since are the
reusable pieces in all Royale UI Sets.

Hope this explanation make more sense.

Thanks

Carlos







2018-05-22 23:43 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I guess I don't understand why separating beads from TLCs is better.  How
> will that make things better for users or other component set developers?
> That would effectively double the number of SWCs and each TLC SWC will need
> its bead SWC.  That doesn't sound like a good thing to me, but if that's
> what other folks want to do, that's fine with me.
>
> I was just looking through the classes in Jewel.  It looks like JeweL
> doesn't have a DataGrid yet..  When it does, I would think you will want to
> use the DataGridModel from Express as it handles both Arrays and
> ICollectionViews.  We will probably create a similar model bead that takes
> both ICollectionViews and Arrays for Lists and put that in Express as
> well.  Then we might decide that is better for Jewel to use that model
> instead.  Or maybe we'll decide to create a JewelExpress set that has those
> more general models that don't require as much configuration.  Anyway, I
> hope you agree that at some point, these more general models will be used
> by Express and some flavor of Jewel.  I don't think this general model
> should go in Core, or Basic (or some new category called Foundation).  And
> at that point, Jewel or JewelExpress is going to re-use that code in
> Express.
>
> Component sets are encouraged to re-use existing code from any other SWC
> since I think we've agreed that re-use is important.
>
> My 2 cents,
> -Alex
>
> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> Hi Alex
>
> what do you think about separating the part in Basic that is
> inherently the
> same as in Jewel (Button, CheckBox, TextInput, List, ...) along with
> CSS
> that wire the beads for Basic UI set, and left the fundamental building
> blocks as something that is not Core but can be reused by Basic and
> Jewel
> (Let's call this "Foundation" Lib, I even like this name for this
> library).
>
> I mean that having "Foundation" lib 

Re: [royale-compiler] branch develop updated: remove code that copied in all CSS from files other than defaults.css. It was originally intended to handle folks specifying fx:Styles in other files, but

[Carlos Rovira]

Hi Alex

I think this change makes this happen, can take a look at it? I was looking
but my fixes seems not be the right ones so maybe is better to look in the
compiler

189970 bytes written to
/Users/carlosrovira/Dev/Royale/Source/royale-asjs/examples/royale/MobileStocks/target/MobileStocks-0.9.4-SNAPSHOT.swf
in 1.880 seconds

/Users/carlosrovira/Dev/Royale/Source/royale-asjs/examples/royale/MobileStocks/src/main/royale/MyInitialView.mxml(151):
col: 23 Error: org.apache.royale.html.beads.BackgroundImageBead is not
defined.


font-size: 18pt;

  ^


/Users/carlosrovira/Dev/Royale/Source/royale-asjs/examples/royale/MobileStocks/src/main/royale/MyInitialView.mxml(151):
col: 23 Error: org.apache.royale.html.beads.BackgroundImageBead is not
defined.


font-size: 18pt;

  ^

[*INFO*]
**

[*INFO*] *Reactor Summary:*

[*INFO*]

[*INFO*] Apache Royale: Examples: Royale: MobileStocks 0.9.4-SNAPSHOT
*FAILURE* [  4.364 s]

[*INFO*] Apache Royale: Examples: Royale: MobileTrader .. *SKIPPED*

[*INFO*] Apache Royale: Examples: Royale: ModuleExample . *SKIPPED*

[*INFO*] Apache Royale: Examples: Royale: ModuleExample: MainApp *SKIPPED*
*...*

*thanks*

*Carlos*



2018-05-22 20:16 GMT+02:00 :

> This is an automated email from the ASF dual-hosted git repository.
>
> aharui pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-compiler.git
>
>
> The following commit(s) were added to refs/heads/develop by this push:
>  new c73d89e  remove code that copied in all CSS from files other than
> defaults.css.  It was originally intended to handle folks specifying
> fx:Styles in other files, but I'm pretty sure we've since fixed that in
> other ways, and that code was wrongly copying in CSS from theme files.  So
> we'll see if custom css files break after this change
> c73d89e is described below
>
> commit c73d89ec20c2ffbbb1d3eeca47204e9cdcc50510
> Author: Alex Harui 
> AuthorDate: Tue May 22 11:16:39 2018 -0700
>
> remove code that copied in all CSS from files other than
> defaults.css.  It was originally intended to handle folks specifying
> fx:Styles in other files, but I'm pretty sure we've since fixed that in
> other ways, and that code was wrongly copying in CSS from theme files.  So
> we'll see if custom css files break after this change
> ---
>  .../internal/driver/js/royale/JSCSSCompilationSession.java   | 9
> +
>  1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/compiler-jx/src/main/java/org/apache/royale/compiler/
> internal/driver/js/royale/JSCSSCompilationSession.java
> b/compiler-jx/src/main/java/org/apache/royale/compiler/
> internal/driver/js/royale/JSCSSCompilationSession.java
> index fad1da8..f0031aa 100644
> --- a/compiler-jx/src/main/java/org/apache/royale/compiler/
> internal/driver/js/royale/JSCSSCompilationSession.java
> +++ b/compiler-jx/src/main/java/org/apache/royale/compiler/
> internal/driver/js/royale/JSCSSCompilationSession.java
> @@ -549,14 +549,7 @@ public class JSCSSCompilationSession extends
> CSSCompilationSession
>  {
> if (super.keepRule(newRule))
> return true;
> -
> -   // include all rules not found in defaults.css
> -   // theoretically, defaults.css rules were
> -   // properly added in the super call.
> -   String sp = newRule.getSourcePath();
> -   if (!sp.contains("defaults.css"))
> -   return true;
> -
> +
> // might need to loop over all selectors in selector group
> if (newRule.getSelectorGroup().size() > 0)
> {
>
> --
> To stop receiving notification emails like this one, please contact
> aha...@apache.org.
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Alex Harui]

Hi Carlos,

I guess I don't understand why separating beads from TLCs is better.  How will 
that make things better for users or other component set developers?  That 
would effectively double the number of SWCs and each TLC SWC will need its bead 
SWC.  That doesn't sound like a good thing to me, but if that's what other 
folks want to do, that's fine with me.

I was just looking through the classes in Jewel.  It looks like JeweL doesn't 
have a DataGrid yet..  When it does, I would think you will want to use the 
DataGridModel from Express as it handles both Arrays and ICollectionViews.  We 
will probably create a similar model bead that takes both ICollectionViews and 
Arrays for Lists and put that in Express as well.  Then we might decide that is 
better for Jewel to use that model instead.  Or maybe we'll decide to create a 
JewelExpress set that has those more general models that don't require as much 
configuration.  Anyway, I hope you agree that at some point, these more general 
models will be used by Express and some flavor of Jewel.  I don't think this 
general model should go in Core, or Basic (or some new category called 
Foundation).  And at that point, Jewel or JewelExpress is going to re-use that 
code in Express.

Component sets are encouraged to re-use existing code from any other SWC since 
I think we've agreed that re-use is important.

My 2 cents,
-Alex

On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex

what do you think about separating the part in Basic that is inherently the
same as in Jewel (Button, CheckBox, TextInput, List, ...) along with CSS
that wire the beads for Basic UI set, and left the fundamental building
blocks as something that is not Core but can be reused by Basic and Jewel
(Let's call this "Foundation" Lib, I even like this name for this library).

I mean that having "Foundation" lib and "Basic" lib, will be more clear,
since we can expect what is in Basic will be never reused to build other UI
Sets (MDL, or others can still hang from there or if someone wants to take
the time refactor it).

Foundation will not have any CSS wiring beads. We can return classes from
Core to Foundation.

Basic will have its own CSS wiring beads, the same for Jewel. Both will
requiere Core and Foundation.

I assume this will make all of us happy.

We can as well do the package name changes to ensure consistency along all
code and libraries.

Let me know what do you think

thanks

Carlos


2018-05-21 19:38 GMT+02:00 Alex Harui :

> I understand this isn't the latest post on this thread, but it is the
> easiest one for me to reply to:
>
> First, the hopefully easy things we can agree on:
> -I have no objection to dropping "Bead" off of bead class names
> -I have no objection to moving all views into a view subfolder as long as
> nobody else is concerned about the size and performance issues.
> -I have no objection to moving classes in Basic that are
> org.apache.royale.html to org.apache.royale.basic.
> -I have no objection to doing a massive rename and long as it isn't me
> doing the work.
> -Whatever is in Core and Basic now or before Carlos's started moving
> things around is not perfect.
>
> Now for the less easy.  Regarding Core vs Basic, I see it this way:  Basic
> is the simplest implementation of the constructs/concepts in Royale.  It 
is
> intended to be extended and enhanced by other component sets via our PAYG
> principles.  Core is intended to identify the constructs/concepts and 
their
> fundamental contracts.
>
> Think of it this way:  When you open any class in Royale, you will want to
> know what kind of class it is.  It is a TLC, a Bead?  And what kind of TLC
> or Bead?  Is it  View, Model, Controller?  An ItemRenderer?  These are the
> categories of classes we had, even in Flex.  I've probably left out a few
> categories.  It is the interfaces for these categories that go in Core.
> And maybe some classes we think are universal implementations of those
> categories.  And some beads that are component set agnostic, like
> BrowserResizeHandler, although we could move those to another SWC and say
> that Core should not have any MXML components except maybe State.
>
> After any rename/refactor we decide on, Basic should still have some
> interfaces because those interfaces describe the contract required for the
> simplest implementation.  I get that it can be a fine line between
> "fundamental" and "simplest", but where many classes that were in Basic 
get
> away from "fundamental" is mainly around Containers.  The way we handle
> Containers in Basic really seems like an 

Jenkins build is back to normal : royale-asjs_jsonly #836

[apacheroyaleci]

See 

Build failed in Jenkins: royale-asjs_jsonly #835

[apacheroyaleci]

See 


--
[...truncated 1.79 MB...]
[mxmlc] goog/debug/entrypointregistry.js
[mxmlc] goog/events/events.js
[mxmlc] goog/events/eventtarget.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IParent.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IContentViewHost.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IStrandPrivate.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IRenderedObject.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IBead.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IBeadLayout.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/LayoutBase.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/beads/layouts/HorizontalFlexLayout.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/events/IRoyaleEvent.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/events/Event.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/events/CustomEvent.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/events/ItemRemovedEvent.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IBeadView.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/beads/IDataGridView.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/ILayoutHost.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/events/IEventDispatcher.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/events/EventDispatcher.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/BeadViewBase.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/beads/GroupView.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/beads/DataGridView.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/utils/loadBeadFromValuesManager.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/html/beads/layouts/DataGridLayout.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IItemRendererProvider.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IList.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IListWithPresentationModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/ILayoutView.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IStrand.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IStrandWithModel.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IStyleableObject.js
[mxmlc] C:/Program Files 
(x86)/Jenkins/workspace/royale-asjs_jsonly/mustella/tests/basicTests/bin/js-debug/org/apache/royale/core/IChild.js
[mxmlc] C:/Program Files 

Build failed in Jenkins: royale-asjs_jsonly #834

[apacheroyaleci]

See 


Changes:

[carlosrovira] remove "return null" that can never be reach

[carlosrovira] add missing Bindable "dataProviderChanged" to allow reassign 
completely

[carlosrovira] add Bindable "dataProviderChanged" and example. We must notice 
that a

--
[...truncated 952.97 KB...]
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [https]:24: WARNING - accessing name require in externs 
has no effect. Perhaps you forgot to add a var keyword?
 [java] var tls = require('tls');
 [java]   ^^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [https]:84: WARNING - name module is not defined in the 
externs.
 [java] module.exports = https;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [net]:23: WARNING - accessing name require in externs has 
no effect. Perhaps you forgot to add a var keyword?
 [java] var events = require('events');
 [java]  ^^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [net]:219: WARNING - name module is not defined in the 
externs.
 [java] module.exports = net;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [os]:112: WARNING - name module is not defined in the 
externs.
 [java] module.exports = os;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [path]:97: WARNING - name module is not defined in the 
externs.
 [java] module.exports = path;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [punycode]:74: WARNING - name module is not defined in the 
externs.
 [java] module.exports = punycode;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [querystring]:66: WARNING - name module is not defined in 
the externs.
 [java] module.exports = querystring;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [readline]:22: WARNING - accessing name require in externs 
has no effect. Perhaps you forgot to add a var keyword?
 [java] var events = require('events');
 [java]  ^^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [readline]:23: WARNING - accessing name require in externs 
has no effect. Perhaps you forgot to add a var keyword?
 [java] var stream = require('stream');
 [java]  ^^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [readline]:84: WARNING - name module is not defined in the 
externs.
 [java] module.exports = readline;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [repl]:23: WARNING - accessing name require in externs has 
no effect. Perhaps you forgot to add a var keyword?
 [java] var events = require('events');
 [java]  ^^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [repl]:24: WARNING - accessing name require in externs has 
no effect. Perhaps you forgot to add a var keyword?
 [java] var stream = require('stream');
 [java]  ^^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [repl]:48: WARNING - name module is not defined in the 
externs.
 [java] module.exports = repl;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [stream]:23: WARNING - accessing name require in externs 
has no effect. Perhaps you forgot to add a var keyword?
 [java] var events = require('events');
 [java]  ^^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 [java] WARNING: [stream]:254: WARNING - name module is not defined in the 
externs.
 [java] module.exports = stream;
 [java] ^^
 [java] 
 [java] May 22, 2018 5:49:53 PM 
com.google.javascript.jscomp.LoggerErrorManager println
 

New Blog post: "Selecting options from a group of Jewel CheckBox controls"

[Carlos Rovira]

Hi,

we have a new blog post for you

https://royale.apache.org/selecting-options-from-a-group-of-jewel-checkbox-controls/

Enjoy! :)

-- 
Carlos Rovira
http://about.me/carlosrovira

New blog post to review: "Selecting options from a group of Jewel CheckBox controls"

[Carlos Rovira]

Hi Andrew,

just finished a new blog post to review. Hope you can find the time to take
a look.

https://royale.codeoscopic.com/selecting-options-from-a-group-of-jewel-checkbox-controls/

Thanks in advance for your help!


-- 
Carlos Rovira
http://about.me/carlosrovira