Re: Need some help with Small Messages

[Alex Harui]

Hi Carlos,

This is definitely out of my area of expertise.  I spent some time poking 
through the code.

First, regarding your question about whether the parameter should be 
AMFBInaryData or BinaryData, IMO, the answer should be that the parameter 
should be an interface.  If there aren't backward compatibility constraints, we 
should try to use interfaces more in new APIs.  In looking around, I noticed 
that there is:

Core/src/main/royale/org/apache/royale/utils/IBinaryDataInput.as
Network/src/main/royale/org/apache/royale/net/utils/IDataInput.as
Storage/src/main/royale/org/apache/royale/storage/file/IDataInput.as

Seems like there should either be only one, and AMFBinaryData and BinaryData 
should both implement it, or maybe one interface should extend the other.  So 
some refactoring is probably warranted there.

Now to your main question.  Are you sure that code 168 is an AMF type code?  I 
could certainly be wrong, but it occurred to me that the 168  could just be the 
first byte in serialized data of the message and that the AMF decoding should 
instantiate the object based on the class alias then see if it implements 
IExternalizable and call readExternal without bothering to examine that byte in 
the stream.

HTH,
-Alex

On 5/31/18, 4:57 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

To be more clear on this, what I need is some guidance on how to deal I
readValueObject(), EXTERNALIZED_OBJECT case and if I must pass the rest of
data to the AcknowledgeMessageExt.readExternal method, or pass the entire
AMFBinaryData to that method. Or another thing I don't have in mind.

thanks!


2018-06-01 1:37 GMT+02:00 Carlos Rovira :

> Hi,
>
> in order to finish Small Messages implementation I need some guidance.
> Hope you guys could throw some light on this.
>
> When turning small messages on, BlazeDS send serialized version of some
> messages. For example the most important is "*DSK*" (the
> registerClassAlias for *AcknowledgeMessageExt.as*), in this case we get a
> type code *168* in "*readObject*" method from *AMFBinaryData*. We can get
> as well *169* and *161* codes, don't know if there's more since I
> couldn't find any documentation about this.
>
> So in *readValueObject*() I introduced a new case *EXTERNALIZED_OBJECT*
> (that is a constant with 168 value)
>
> Inside we need to deal with the deserialization of the
> *AcknowledgeMessageExt* message (the *DSK*).
>
> This kind of messages like the rest implements all *IExternalizable*
> methods (*readExternal*, *writeExternal*), that receive a *IDataInput*
> and *IDataOutput* respectively.
> I get all this code of messages from Flex RPC compile correctly . Here I
> have a doubt:
>
> ** When I have a ByteArray param here it should be BinaryData or
> AMFBinaryData in Royale?* (I suppose the second, but can't ensure it)
>
> Finally the main problem...How can I deserialize the DSK object that comes
> vía AMF
>
> 1.-* I'm pretty sure that AMFBinaryData must implement IDataInput and
> IDataOutput since is the object I suppose I must to pass to readExternal 
or
> writeExternal right?*
>
> 2.- In *readValueObject*(), case *EXTERNALIZED_OBJECT* I tried to do
> something like:
>
> *var dsk: AcknowledgeMessageExt = new AcknowledgeMessageExt()*
> *dsk.readExternal (this);*
> *value = dsk;*
>
> this is not working, if not we'll be done ;)
>
> But as I don't know how flash IExternalizable works under the hood, I
> don't know how to deal with this in Royale.
>
> I suppose that Flash Player manages the readExternal and writeExternal
> methods under the hood, right? but in Royale I suppose we need to call it
> ourselves.
>
> Maybe the IExternalizable, IDataOutput and IDataInput are not right as I
> write those. Notice that the last two doesn't have all the methods in
> Flash. I write only the required ones. I'll write the rest as we get the
> current problem solved.
>
> As I said, all messages has the message methods for readExternal and
> writeExternal compile in royale, so I think we are so close to get this
> implementation working hopefully with some help for your part to finally
> get the final pieces of this puzzle solved :)
>
> Thanks in advance
>
> Carlos
>
>
>
>
>
> --
> Carlos Rovira
> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7Ceffcd4e8bcf14b3d51dc08d5c75238cc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634078327400307=iaUSnW4FfeZFtb2q0Hd4aHTUW5wgNyzbRIYfna7WD9M%3D=0
>
>


-- 
Carlos Rovira

Re: New compiler back-end documentation?

[Alex Harui]

OK, I wrote this up.

https://github.com/apache/royale-compiler/wiki/Developer-Guide

Feel free to ask more questions or offer patches.

HTH,
-Alex

On 5/28/18, 11:29 PM, "Alex Harui"  wrote:

I will try to write something this week.

-Alex

On 5/28/18, 10:48 AM, "Jesse Nicholson"  wrote:

I'm looking for more details about the following, taken from the
royale-compiler readme on github:

The compiler has been modified and extended to transpile MXML and 
ActionScript
to JavaScript and potentially other output definitions and is
now being used as the compiler for the Apache Royale SDK. 

Specifically:

*and potentially other output definitions *Is there any documentation 
to help guide someone in adding a new emission back end to the compiler? If 
not, any pointers about where in the source to focus my gaze to learn from 
would be greatly appreciated.

Very exciting project by the way, great work.

TIA.**

Re: Need some help with Small Messages

[Carlos Rovira]

To be more clear on this, what I need is some guidance on how to deal I
readValueObject(), EXTERNALIZED_OBJECT case and if I must pass the rest of
data to the AcknowledgeMessageExt.readExternal method, or pass the entire
AMFBinaryData to that method. Or another thing I don't have in mind.

thanks!


2018-06-01 1:37 GMT+02:00 Carlos Rovira :

> Hi,
>
> in order to finish Small Messages implementation I need some guidance.
> Hope you guys could throw some light on this.
>
> When turning small messages on, BlazeDS send serialized version of some
> messages. For example the most important is "*DSK*" (the
> registerClassAlias for *AcknowledgeMessageExt.as*), in this case we get a
> type code *168* in "*readObject*" method from *AMFBinaryData*. We can get
> as well *169* and *161* codes, don't know if there's more since I
> couldn't find any documentation about this.
>
> So in *readValueObject*() I introduced a new case *EXTERNALIZED_OBJECT*
> (that is a constant with 168 value)
>
> Inside we need to deal with the deserialization of the
> *AcknowledgeMessageExt* message (the *DSK*).
>
> This kind of messages like the rest implements all *IExternalizable*
> methods (*readExternal*, *writeExternal*), that receive a *IDataInput*
> and *IDataOutput* respectively.
> I get all this code of messages from Flex RPC compile correctly . Here I
> have a doubt:
>
> ** When I have a ByteArray param here it should be BinaryData or
> AMFBinaryData in Royale?* (I suppose the second, but can't ensure it)
>
> Finally the main problem...How can I deserialize the DSK object that comes
> vía AMF
>
> 1.-* I'm pretty sure that AMFBinaryData must implement IDataInput and
> IDataOutput since is the object I suppose I must to pass to readExternal or
> writeExternal right?*
>
> 2.- In *readValueObject*(), case *EXTERNALIZED_OBJECT* I tried to do
> something like:
>
> *var dsk: AcknowledgeMessageExt = new AcknowledgeMessageExt()*
> *dsk.readExternal (this);*
> *value = dsk;*
>
> this is not working, if not we'll be done ;)
>
> But as I don't know how flash IExternalizable works under the hood, I
> don't know how to deal with this in Royale.
>
> I suppose that Flash Player manages the readExternal and writeExternal
> methods under the hood, right? but in Royale I suppose we need to call it
> ourselves.
>
> Maybe the IExternalizable, IDataOutput and IDataInput are not right as I
> write those. Notice that the last two doesn't have all the methods in
> Flash. I write only the required ones. I'll write the rest as we get the
> current problem solved.
>
> As I said, all messages has the message methods for readExternal and
> writeExternal compile in royale, so I think we are so close to get this
> implementation working hopefully with some help for your part to finally
> get the final pieces of this puzzle solved :)
>
> Thanks in advance
>
> Carlos
>
>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


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

Need some help with Small Messages

[Carlos Rovira]

Hi,

in order to finish Small Messages implementation I need some guidance. Hope
you guys could throw some light on this.

When turning small messages on, BlazeDS send serialized version of some
messages. For example the most important is "*DSK*" (the registerClassAlias
for *AcknowledgeMessageExt.as*), in this case we get a type code *168* in "
*readObject*" method from *AMFBinaryData*. We can get as well *169* and
*161* codes, don't know if there's more since I couldn't find any
documentation about this.

So in *readValueObject*() I introduced a new case *EXTERNALIZED_OBJECT*
(that is a constant with 168 value)

Inside we need to deal with the deserialization of the
*AcknowledgeMessageExt* message (the *DSK*).

This kind of messages like the rest implements all *IExternalizable*
methods (*readExternal*, *writeExternal*), that receive a *IDataInput* and
*IDataOutput* respectively.
I get all this code of messages from Flex RPC compile correctly . Here I
have a doubt:

** When I have a ByteArray param here it should be BinaryData or
AMFBinaryData in Royale?* (I suppose the second, but can't ensure it)

Finally the main problem...How can I deserialize the DSK object that comes
vía AMF

1.-* I'm pretty sure that AMFBinaryData must implement IDataInput and
IDataOutput since is the object I suppose I must to pass to readExternal or
writeExternal right?*

2.- In *readValueObject*(), case *EXTERNALIZED_OBJECT* I tried to do
something like:

*var dsk: AcknowledgeMessageExt = new AcknowledgeMessageExt()*
*dsk.readExternal (this);*
*value = dsk;*

this is not working, if not we'll be done ;)

But as I don't know how flash IExternalizable works under the hood, I don't
know how to deal with this in Royale.

I suppose that Flash Player manages the readExternal and writeExternal
methods under the hood, right? but in Royale I suppose we need to call it
ourselves.

Maybe the IExternalizable, IDataOutput and IDataInput are not right as I
write those. Notice that the last two doesn't have all the methods in
Flash. I write only the required ones. I'll write the rest as we get the
current problem solved.

As I said, all messages has the message methods for readExternal and
writeExternal compile in royale, so I think we are so close to get this
implementation working hopefully with some help for your part to finally
get the final pieces of this puzzle solved :)

Thanks in advance

Carlos





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

Re: Royale - BlazeDS working

[Harbs]

Very impressive! Great work! :-)

Harbs

> On May 31, 2018, at 9:51 PM, Carlos Rovira  wrote:
> 
> Forgot to share the info in Github page :)
> 
> https://github.com/apache/royale-asjs/wiki/Apache-Royale-communication-with-AMF-and-RemoteObject
>  
> 
> 
> 2018-05-31 20:49 GMT+02:00 Carlos Rovira  >:
> Hi,
> 
> I get Royale working with BlazeDS. People using BlazeDS should be able to 
> finally start developing with Royale now! :)
> 
> Right now I'm test it with both the SampleAmfWebApp (in our repo) and with my 
> own backend (real flex/java app), and seems to work in both.
> 
> Things to have into account: While "clientId" is now working (we send the 
> required PING command, get the DSId and store it for later communication), we 
> need to use it with small messages turned off (blazeds turn it on by default).
> 
> This is the configuration per channel:
> 
> 
>   
> 
> false
> 
> 
> I think small messages are only something that will make our implementation 
> shine, but really is not required. I think that will improve a bit over the 
> normal message size. If you use as well the CompressedRemoteObject, that will 
> be a killer communication! :) 
> 
> About small messages, I'm trying to get it work, I uploaded the work 
> currently done, but still needs more to get it fully working.
> 
> As well I uploaded a SimpleRemoteObject that is a simpler version that should 
> work with AMF backends that require less things like AMFPHP. As I don't use 
> AMFPHP since many years I can say too much about it, but hope others will use 
> and report if something more is needed (The same for other AMF 
> implementations in other technologies).
> 
> Thanks!
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira 
> 
> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira 
> 

Jenkins build is back to normal : royale-asjs #811

[apacheroyaleci]

See 

Re: Royale - BlazeDS working

[Alex Harui]

Hi Carlos,

That’s great news!

One thing I would like to see someday (not necessarily from you, maybe some 
other user) is a comparison of JSON vs AMF.For some real-world server 
response, what would be the number of bytes transferred and what would be the 
CPU processing time in the browser to convert the data into “Value Objects”.

Thanks,
-Alex

From:  on behalf of Carlos Rovira 

Reply-To: "us...@royale.apache.org" 
Date: Thursday, May 31, 2018 at 11:52 AM
To: "us...@royale.apache.org" , 
"dev@royale.apache.org" 
Subject: Re: Royale - BlazeDS working

Forgot to share the info in Github page :)

https://github.com/apache/royale-asjs/wiki/Apache-Royale-communication-with-AMF-and-RemoteObject

2018-05-31 20:49 GMT+02:00 Carlos Rovira 
mailto:carlosrov...@apache.org>>:
Hi,

I get Royale working with BlazeDS. People using BlazeDS should be able to 
finally start developing with Royale now! :)

Right now I'm test it with both the SampleAmfWebApp (in our repo) and with my 
own backend (real flex/java app), and seems to work in both.

Things to have into account: While "clientId" is now working (we send the 
required PING command, get the DSId and store it for later communication), we 
need to use it with small messages turned off (blazeds turn it on by default).

This is the configuration per channel:




false


I think small messages are only something that will make our implementation 
shine, but really is not required. I think that will improve a bit over the 
normal message size. If you use as well the CompressedRemoteObject, that will 
be a killer communication! :)

About small messages, I'm trying to get it work, I uploaded the work currently 
done, but still needs more to get it fully working.

As well I uploaded a SimpleRemoteObject that is a simpler version that should 
work with AMF backends that require less things like AMFPHP. As I don't use 
AMFPHP since many years I can say too much about it, but hope others will use 
and report if something more is needed (The same for other AMF implementations 
in other technologies).

Thanks!

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




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

Re: Royale - BlazeDS working

[Carlos Rovira]

Forgot to share the info in Github page :)

https://github.com/apache/royale-asjs/wiki/Apache-Royale-communication-with-AMF-and-RemoteObject

2018-05-31 20:49 GMT+02:00 Carlos Rovira :

> Hi,
>
> I get Royale working with BlazeDS. People using BlazeDS should be able to
> finally start developing with Royale now! :)
>
> Right now I'm test it with both the SampleAmfWebApp (in our repo) and with
> my own backend (real flex/java app), and seems to work in both.
>
> Things to have into account: While "clientId" is now working (we send the
> required PING command, get the DSId and store it for later communication),
> we need to use it with small messages turned off (blazeds turn it on by
> default).
>
> This is the configuration per channel:
>
> 
> 
> 
> false
> 
>
> I think small messages are only something that will make our
> implementation shine, but really is not required. I think that will improve
> a bit over the normal message size. If you use as well the
> CompressedRemoteObject, that will be a killer communication! :)
>
> About small messages, I'm trying to get it work, I uploaded the work
> currently done, but still needs more to get it fully working.
>
> As well I uploaded a SimpleRemoteObject that is a simpler version that
> should work with AMF backends that require less things like AMFPHP. As I
> don't use AMFPHP since many years I can say too much about it, but hope
> others will use and report if something more is needed (The same for other
> AMF implementations in other technologies).
>
> Thanks!
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


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

Royale - BlazeDS working

[Carlos Rovira]

Hi,

I get Royale working with BlazeDS. People using BlazeDS should be able to
finally start developing with Royale now! :)

Right now I'm test it with both the SampleAmfWebApp (in our repo) and with
my own backend (real flex/java app), and seems to work in both.

Things to have into account: While "clientId" is now working (we send the
required PING command, get the DSId and store it for later communication),
we need to use it with small messages turned off (blazeds turn it on by
default).

This is the configuration per channel:




false


I think small messages are only something that will make our implementation
shine, but really is not required. I think that will improve a bit over the
normal message size. If you use as well the CompressedRemoteObject, that
will be a killer communication! :)

About small messages, I'm trying to get it work, I uploaded the work
currently done, but still needs more to get it fully working.

As well I uploaded a SimpleRemoteObject that is a simpler version that
should work with AMF backends that require less things like AMFPHP. As I
don't use AMFPHP since many years I can say too much about it, but hope
others will use and report if something more is needed (The same for other
AMF implementations in other technologies).

Thanks!

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

Build failed in Jenkins: royale-asjs #810

[apacheroyaleci]

See 


Changes:

[carlosrovira] UUID was has more length than expected by BlazeDS generating 
messages

[carlosrovira] Remove RPCUIDUtil since already exists UIDUtil that makes the 
same

--
[...truncated 1.57 MB...]
 [java] Loading configuration: 

 [java] 
 [java] 
:
 col: 16 Warning: Definition org.apache.royale.net.utils.RPCUIDUtil could not 
be found.
 [java] 
 [java] import org.apache.royale.net.utils.RPCUIDUtil; RPCUIDUtil;
 [java]^
 [java] 
 [java] 
:
 col: 56 Error: Access of possibly undefined property RPCUIDUtil.
 [java] 
 [java] import org.apache.royale.net.utils.RPCUIDUtil; RPCUIDUtil;
 [java]^
 [java] 
 [java] 
:
 col: 8 Warning: Definition org.apache.royale.net.utils.RPCUIDUtil could not be 
found.
 [java] 
 [java] import org.apache.royale.net.utils.RPCUIDUtil;
 [java]^
 [java] 
 [java] 
:
 col: 32 Error: Access of possibly undefined property RPCUIDUtil.
 [java] 
 [java] clientId = 
RPCUIDUtil.fromByteArray(clientIdBytes);
 [java]^
 [java] 
 [java] 
:
 col: 33 Error: Access of possibly undefined property RPCUIDUtil.
 [java] 
 [java] messageId = 
RPCUIDUtil.fromByteArray(messageIdBytes);
 [java] ^
 [java] 
 [java] 
:
 col: 29 Error: Access of possibly undefined property RPCUIDUtil.
 [java] 
 [java] clientIdBytes = RPCUIDUtil.toByteArray(_clientId);
 [java] ^
 [java] 
 [java] 
:
 col: 30 Error: Access of possibly undefined property RPCUIDUtil.
 [java] 
 [java] messageIdBytes = RPCUIDUtil.toByteArray(_messageId);
 [java]  ^
 [java] 
 [java] 
:
 col: 8 Warning: Definition org.apache.royale.net.utils.RPCUIDUtil could not be 
found.
 [java] 
 [java] import org.apache.royale.net.utils.RPCUIDUtil;
 [java]^
 [java] 
 [java] 
:
 col: 37 Error: Access of possibly undefined property RPCUIDUtil.
 [java] 
 [java] correlationId = 
RPCUIDUtil.fromByteArray(correlationIdBytes);
 [java] ^
 [java] 
 [java] 
:
 col: 34 Error: Access of possibly undefined property RPCUIDUtil.
 [java] 
 [java] correlationIdBytes = 
RPCUIDUtil.toByteArray(_correlationId);
 [java]  ^
 [java] 
 [java] 
:
 col: 16 Definition org.apache.royale.net.utils.RPCUIDUtil could not be found.
 [java] 
 [java] import org.apache.royale.net.utils.RPCUIDUtil; RPCUIDUtil;
 [java]^
 [java] 
 [java] 

Re: Restructuring Composite Components

[Alex Harui]

The way I customized the title bar of a Panel in the RoyaleStore is here:

The custom TitleBar:
https://github.com/apache/royale-asjs/blob/develop/examples/royale/RoyaleStore/src/main/royale/productsView/ProductCatalogPanelTitleBarView.mxml

Used here around line 511
https://github.com/apache/royale-asjs/blob/develop/examples/royale/RoyaleStore/src/main/royale/productsView/ProductCatalogPanel.mxml#L511

Views should be highly interchangeable.  They should care little about the 
strand and just expect certain things from the model.  A replacement View 
shouldn't need to subclass the default View.  No code should care about the 
type of the View.

HTH,
-Alex

On 5/31/18, 9:40 AM, "Piotr Zarzycki"  wrote:

When I have created Panel with custom header in one of the
Transpiledactionscript examples I did that part in following way [1].

[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbit.ly%2F2kDJ0Af=02%7C01%7Caharui%40adobe.com%7C637b49b00a4b41beda2808d5c7153fef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636633816524650727=rkbSV2t1r0qX8OMDoJbRaQrw6l51zSfTq4lh2%2BCCSuc%3D=0

czw., 31 maj 2018 o 17:28 Harbs  napisał(a):

> An additional wrinkle in this problem is wether there’s any way to specify
> the parts of the view using MXML, or it has to be in CSS.
>
> If they are beads, that problem is simplified. If not, is there a way to
> add to ValueManager via MXML?
>
> Harbs
>
> > On May 31, 2018, at 6:09 PM, Harbs  wrote:
> >
> > I don’t think so. The List is a component within ComboBox. I think the
> basic structure of ComboBox makes sense as is. I think it’s the View which
> needs work.
> >
> > It’s possible that an Express ComboBox might have additional properties
> to make it easier to set the labelField, listHeight, etc.
> >
> > I’m primarily trying to figure out the best way to declare the “skin
> pieces” of the view.
> >
> > Harbs
> >
> >> On May 31, 2018, at 5:17 PM, Piotr Zarzycki 
> wrote:
> >>
> >> Hi Harbs,
> >>
> >> What if ComboBox will extend DataContainer? It will be at some point
> list
> >> itself. Than the rest responsibility is in View. We know that ComboBox
> is
> >> always list, so if someone would like to change the other parts need to
> >> have dive into view.
> >>
> >> On the other hand this solution probably is less flexible than having
> >> through css some parts of that component.
> >>
> >> Thanks,
> >> Piotr
> >>
> >>
> >> czw., 31 maj 2018 o 15:35 Harbs  napisał(a):
> >>
> >>> I’m working on redoing ComboBox and I could use some input on best
> >>> practices.
> >>>
> >>> Right now, ComboBox has ComboBox view which has three components
> >>> hard-wired in. It has TextInput, TextButton, and List. If any visuals
> or
> >>> behavior need to be changed, the entire view needs to be rewritten.
> We’ve
> >>> already had two cases where I needed a new view. One was to disable 
the
> >>> TextInput input and change the button appearance. The second was to
> support
> >>> images in a dropdown.
> >>>
> >>> It seems to me like the ComboBoxView should add the three components
> based
> >>> on declared classes. I think there should be 1. A “Button” component.
> 2. An
> >>> ItemRenderer component for the “input” which displays the selected
> item. 3.
> >>> A List component for displaying the dropdown. The question I’m
> struggling
> >>> with is how to declare these.
> >>>
> >>> I don’t think it makes sense to make these all beads. Currently 
Buttons
> >>> are not beads.
> >>>
> >>> Should we add interfaces (i.e. IButton) and declare the classes using
> >>> interfaces? I mean something similar to IItemRenderer.
> >>>
> >>> Maybe just use ValuesManager to just lookup some other “name”? We’re
> >>> currently doing something similar with ColumnClassName in
> DynamicDataGrid.
> >>>
> >>> Other ideas?
> >>>
> >>> Thanks,
> >>> Harbs
> >>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: 
*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C637b49b00a4b41beda2808d5c7153fef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636633816524650727=L%2FBMBIVysfPdFXQ%2FmMIvWdoTT4%2Fla%2Bwdi%2FfMu5w5QD0%3D=0
> >> 
*
> >
>
>

-- 

Piotr Zarzycki

Patreon: 

Re: Restructuring Composite Components

[Piotr Zarzycki]

When I have created Panel with custom header in one of the
Transpiledactionscript examples I did that part in following way [1].

[1] https://bit.ly/2kDJ0Af

czw., 31 maj 2018 o 17:28 Harbs  napisał(a):

> An additional wrinkle in this problem is wether there’s any way to specify
> the parts of the view using MXML, or it has to be in CSS.
>
> If they are beads, that problem is simplified. If not, is there a way to
> add to ValueManager via MXML?
>
> Harbs
>
> > On May 31, 2018, at 6:09 PM, Harbs  wrote:
> >
> > I don’t think so. The List is a component within ComboBox. I think the
> basic structure of ComboBox makes sense as is. I think it’s the View which
> needs work.
> >
> > It’s possible that an Express ComboBox might have additional properties
> to make it easier to set the labelField, listHeight, etc.
> >
> > I’m primarily trying to figure out the best way to declare the “skin
> pieces” of the view.
> >
> > Harbs
> >
> >> On May 31, 2018, at 5:17 PM, Piotr Zarzycki 
> wrote:
> >>
> >> Hi Harbs,
> >>
> >> What if ComboBox will extend DataContainer? It will be at some point
> list
> >> itself. Than the rest responsibility is in View. We know that ComboBox
> is
> >> always list, so if someone would like to change the other parts need to
> >> have dive into view.
> >>
> >> On the other hand this solution probably is less flexible than having
> >> through css some parts of that component.
> >>
> >> Thanks,
> >> Piotr
> >>
> >>
> >> czw., 31 maj 2018 o 15:35 Harbs  napisał(a):
> >>
> >>> I’m working on redoing ComboBox and I could use some input on best
> >>> practices.
> >>>
> >>> Right now, ComboBox has ComboBox view which has three components
> >>> hard-wired in. It has TextInput, TextButton, and List. If any visuals
> or
> >>> behavior need to be changed, the entire view needs to be rewritten.
> We’ve
> >>> already had two cases where I needed a new view. One was to disable the
> >>> TextInput input and change the button appearance. The second was to
> support
> >>> images in a dropdown.
> >>>
> >>> It seems to me like the ComboBoxView should add the three components
> based
> >>> on declared classes. I think there should be 1. A “Button” component.
> 2. An
> >>> ItemRenderer component for the “input” which displays the selected
> item. 3.
> >>> A List component for displaying the dropdown. The question I’m
> struggling
> >>> with is how to declare these.
> >>>
> >>> I don’t think it makes sense to make these all beads. Currently Buttons
> >>> are not beads.
> >>>
> >>> Should we add interfaces (i.e. IButton) and declare the classes using
> >>> interfaces? I mean something similar to IItemRenderer.
> >>>
> >>> Maybe just use ValuesManager to just lookup some other “name”? We’re
> >>> currently doing something similar with ColumnClassName in
> DynamicDataGrid.
> >>>
> >>> Other ideas?
> >>>
> >>> Thanks,
> >>> Harbs
> >>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> *
> >
>
>

-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Restructuring Composite Components

[Carlos Rovira]

Hi Harbs,

I think that I still need to know what is a ComboBox in Royale, since is a
component that use to mean different things for different persons.
If is the same that we had in Flex, then I assume it will be a button with
a text and an arrow and a list dropdown, then if editable, people could
introduce text.
An important bead will be Autocomplete, since is what make this kind of
components usable.

Second, I use to search for how this component is done in current component
set. Is normal that the solutions out there should be the best we can do
now, so
looking at the HTML code we can abstract the components that we'll need in
Royale and see if there's some aggressive differences between JS and SWF
sides.
For example Slider is far different in SWF than JS.

For example I started a DropDownList in Jewel that I think can share many
things with ComboBox, but it was a first attempt and will still need much
work, I need to analyze more options to continue that work. If you are
working on ComboBox, I think is more intelligent to wait to your version
and then use it for Jewel for reuse.





2018-05-31 17:28 GMT+02:00 Harbs :

> An additional wrinkle in this problem is wether there’s any way to specify
> the parts of the view using MXML, or it has to be in CSS.
>
> If they are beads, that problem is simplified. If not, is there a way to
> add to ValueManager via MXML?
>
> Harbs
>
> > On May 31, 2018, at 6:09 PM, Harbs  wrote:
> >
> > I don’t think so. The List is a component within ComboBox. I think the
> basic structure of ComboBox makes sense as is. I think it’s the View which
> needs work.
> >
> > It’s possible that an Express ComboBox might have additional properties
> to make it easier to set the labelField, listHeight, etc.
> >
> > I’m primarily trying to figure out the best way to declare the “skin
> pieces” of the view.
> >
> > Harbs
> >
> >> On May 31, 2018, at 5:17 PM, Piotr Zarzycki 
> wrote:
> >>
> >> Hi Harbs,
> >>
> >> What if ComboBox will extend DataContainer? It will be at some point
> list
> >> itself. Than the rest responsibility is in View. We know that ComboBox
> is
> >> always list, so if someone would like to change the other parts need to
> >> have dive into view.
> >>
> >> On the other hand this solution probably is less flexible than having
> >> through css some parts of that component.
> >>
> >> Thanks,
> >> Piotr
> >>
> >>
> >> czw., 31 maj 2018 o 15:35 Harbs  napisał(a):
> >>
> >>> I’m working on redoing ComboBox and I could use some input on best
> >>> practices.
> >>>
> >>> Right now, ComboBox has ComboBox view which has three components
> >>> hard-wired in. It has TextInput, TextButton, and List. If any visuals
> or
> >>> behavior need to be changed, the entire view needs to be rewritten.
> We’ve
> >>> already had two cases where I needed a new view. One was to disable the
> >>> TextInput input and change the button appearance. The second was to
> support
> >>> images in a dropdown.
> >>>
> >>> It seems to me like the ComboBoxView should add the three components
> based
> >>> on declared classes. I think there should be 1. A “Button” component.
> 2. An
> >>> ItemRenderer component for the “input” which displays the selected
> item. 3.
> >>> A List component for displaying the dropdown. The question I’m
> struggling
> >>> with is how to declare these.
> >>>
> >>> I don’t think it makes sense to make these all beads. Currently Buttons
> >>> are not beads.
> >>>
> >>> Should we add interfaces (i.e. IButton) and declare the classes using
> >>> interfaces? I mean something similar to IItemRenderer.
> >>>
> >>> Maybe just use ValuesManager to just lookup some other “name”? We’re
> >>> currently doing something similar with ColumnClassName in
> DynamicDataGrid.
> >>>
> >>> Other ideas?
> >>>
> >>> Thanks,
> >>> Harbs
> >>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> *
> >
>
>


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

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

[Carlos Rovira]

Hi Harbs

2018-05-31 15:10 GMT+02:00 Harbs :

> I’m not sure if we’re communicating.
>
> Composite TLCs have many pieces and only some of them are related to View.
> DataGrid has 5 class reference and only one is IBeadView. DataGrid uses
> DataGridColumnList which has 9 class references. One is view and another
> which might (or might not) need replacement is layout. Other than these
> classes, the whole component should just work as-is in Jewel. All you need
> is to swap out the IBeadView and/or part of the view.
>

What I said is that we'll need at least "DataGrid" in Jewel SWC, then most
of the pieces in Basic will be reused (so I expect it to be in a shared
SWC, what I call Foundation). Then DataGridColumnList will be needed in
Jewel as well, but extending jewel List. DataGridButtonBar will extend
ButtonBar from Jewel, when this exits.
For example IDataGridColumn will be taken from Basic as well DataGridModel.
DataGridView will be implemented in Jewel
So, all that I can reuse, will be reused. No sense to duplicate code if can
avoid that.
So as you see is not the whole component, is not possible, but I think a
decent part will be shared.


>
> We *would* need to make sure that the swapped view classes are not
> imported unnecessarily.


That is easy to do making separation.
The opposite will be really hard since you'll find here and there points
hidden. I didn't see many problems until current separation shows the
problems in compilation.
I think that can only be accomplished by separation for sure. If not is a
finger to the wind ;)


> (I’m not sure if they are or not.) If they are, I think it’s clear that is
> a bug which needs to be fixed no-matter. Defaults should not be imported if
> overridden by applications.
>

Right bugs must be fixed, but a fixed bug doesn't mind we should avoid
setup things in the right way. We should want to pursue both.


>
> Maybe we should wait on this decision until Jewel is more complete? It’s
> possible that you are right and none of the TLCs will end up in Jewel. It’s
> possible I’m right and they will. I don’t see how restructuring Basic is
> necessary until we’re sure of the outcome of that.
>

The problem I see is that If I want to work on the next component, I'll
need to move things from Basic to Core, or make the intermediate Foundation
library, if not I'll be duplicating code that is not what we want. The good
point is that making Foundation SWC and moving pieces to it as I work on
Jewel should not impact current state of Royale, we only need to add the
dependency. The rename we plan to do is what will cause users to update
code.





>
> Thoughts?
> Harbs
>
> > On May 31, 2018, at 2:10 PM, Carlos Rovira 
> wrote:
> >
> >> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly
> >> ImageButon etc. The components are basically UIBase components which
> >> describe how the pieces are wired together. The views are separate
> >> components that are declared. For these TLCs, there shouldn’t be a need
> to
> >> duplicate the classes or subclass the classes in Jewel at all. It
> should be
> >> possible to simply use Basic or Express composite TLCs and simply
> declare a
> >> Jewel view to use with them.
> >>
> >>
> > yes, if you are seeing that the compositing TLCs are Jewel TLCs. For
> > example, ComboBox will compose a Jewel Button not Basic Button, to comply
> > with the overall set and purpose. As well will compose a TextInput and a
> > List from Jewel, not from Basic. Take into account that the first thing a
> > Jewel TLC (basic or complex) will do is set typeNames in constructor to
> > "jewel XXX", and then define "component parts" like button:Button (of
> Jewel
> > set).
> >
> > Image Button will as well composite a Jewel Button. DataGrid is a complex
> > TLC that will be using jewel TLCs and other build blocks currently in
> > Basic, that should move to Foundation (or whatever we want to call to
> > "reusable library with common code and beads").
> >
> > What is clear is that all pieces that are reusable in ComboBox, DataGrid
> or
> > ImageButton will be used to create those components in Jewel, as many as
> we
> > can.
> > All those components will have its own Jewel view to make its own
> visuals,
> > like SliderView in jewel needs that code that is different to basic one
> > since it "fills" the bar as we move the thumb.
> >
> >
> >
> >> Is there an issue that I’m missing here?
> >>
> >> Harbs
> >>
> >>> On May 31, 2018, at 12:12 PM, Carlos Rovira 
> >> wrote:
> >>>
> >>> Hi Harbs,
> >>>
> >>> concreting more over if Jewel should or not extend Basic TLCs. That I
> >> think
> >>> is the real point now to discuss. I'm sure it should not be the case.
> To
> >>> sum to all that I exposed, it was not clearly sufficient enough (that I
> >>> think it should be). Why I want all the class definitions overhead it
> >> will
> >>> cause?
> >>>
> >>> Why have the basic Button file with all the class text definitions and
> >> then
> >>> the jewel Button 

Re: Restructuring Composite Components

[Harbs]

An additional wrinkle in this problem is wether there’s any way to specify the 
parts of the view using MXML, or it has to be in CSS.

If they are beads, that problem is simplified. If not, is there a way to add to 
ValueManager via MXML?

Harbs

> On May 31, 2018, at 6:09 PM, Harbs  wrote:
> 
> I don’t think so. The List is a component within ComboBox. I think the basic 
> structure of ComboBox makes sense as is. I think it’s the View which needs 
> work.
> 
> It’s possible that an Express ComboBox might have additional properties to 
> make it easier to set the labelField, listHeight, etc.
> 
> I’m primarily trying to figure out the best way to declare the “skin pieces” 
> of the view.
> 
> Harbs
> 
>> On May 31, 2018, at 5:17 PM, Piotr Zarzycki  
>> wrote:
>> 
>> Hi Harbs,
>> 
>> What if ComboBox will extend DataContainer? It will be at some point list
>> itself. Than the rest responsibility is in View. We know that ComboBox is
>> always list, so if someone would like to change the other parts need to
>> have dive into view.
>> 
>> On the other hand this solution probably is less flexible than having
>> through css some parts of that component.
>> 
>> Thanks,
>> Piotr
>> 
>> 
>> czw., 31 maj 2018 o 15:35 Harbs  napisał(a):
>> 
>>> I’m working on redoing ComboBox and I could use some input on best
>>> practices.
>>> 
>>> Right now, ComboBox has ComboBox view which has three components
>>> hard-wired in. It has TextInput, TextButton, and List. If any visuals or
>>> behavior need to be changed, the entire view needs to be rewritten. We’ve
>>> already had two cases where I needed a new view. One was to disable the
>>> TextInput input and change the button appearance. The second was to support
>>> images in a dropdown.
>>> 
>>> It seems to me like the ComboBoxView should add the three components based
>>> on declared classes. I think there should be 1. A “Button” component. 2. An
>>> ItemRenderer component for the “input” which displays the selected item. 3.
>>> A List component for displaying the dropdown. The question I’m struggling
>>> with is how to declare these.
>>> 
>>> I don’t think it makes sense to make these all beads. Currently Buttons
>>> are not beads.
>>> 
>>> Should we add interfaces (i.e. IButton) and declare the classes using
>>> interfaces? I mean something similar to IItemRenderer.
>>> 
>>> Maybe just use ValuesManager to just lookup some other “name”? We’re
>>> currently doing something similar with ColumnClassName in DynamicDataGrid.
>>> 
>>> Other ideas?
>>> 
>>> Thanks,
>>> Harbs
>> 
>> 
>> 
>> -- 
>> 
>> Piotr Zarzycki
>> 
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> *
> 

Re: Restructuring Composite Components

[Harbs]

I don’t think so. The List is a component within ComboBox. I think the basic 
structure of ComboBox makes sense as is. I think it’s the View which needs work.

It’s possible that an Express ComboBox might have additional properties to make 
it easier to set the labelField, listHeight, etc.

I’m primarily trying to figure out the best way to declare the “skin pieces” of 
the view.

Harbs

> On May 31, 2018, at 5:17 PM, Piotr Zarzycki  wrote:
> 
> Hi Harbs,
> 
> What if ComboBox will extend DataContainer? It will be at some point list
> itself. Than the rest responsibility is in View. We know that ComboBox is
> always list, so if someone would like to change the other parts need to
> have dive into view.
> 
> On the other hand this solution probably is less flexible than having
> through css some parts of that component.
> 
> Thanks,
> Piotr
> 
> 
> czw., 31 maj 2018 o 15:35 Harbs  napisał(a):
> 
>> I’m working on redoing ComboBox and I could use some input on best
>> practices.
>> 
>> Right now, ComboBox has ComboBox view which has three components
>> hard-wired in. It has TextInput, TextButton, and List. If any visuals or
>> behavior need to be changed, the entire view needs to be rewritten. We’ve
>> already had two cases where I needed a new view. One was to disable the
>> TextInput input and change the button appearance. The second was to support
>> images in a dropdown.
>> 
>> It seems to me like the ComboBoxView should add the three components based
>> on declared classes. I think there should be 1. A “Button” component. 2. An
>> ItemRenderer component for the “input” which displays the selected item. 3.
>> A List component for displaying the dropdown. The question I’m struggling
>> with is how to declare these.
>> 
>> I don’t think it makes sense to make these all beads. Currently Buttons
>> are not beads.
>> 
>> Should we add interfaces (i.e. IButton) and declare the classes using
>> interfaces? I mean something similar to IItemRenderer.
>> 
>> Maybe just use ValuesManager to just lookup some other “name”? We’re
>> currently doing something similar with ColumnClassName in DynamicDataGrid.
>> 
>> Other ideas?
>> 
>> Thanks,
>> Harbs
> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: Restructuring Composite Components

[Piotr Zarzycki]

Hi Harbs,

What if ComboBox will extend DataContainer? It will be at some point list
itself. Than the rest responsibility is in View. We know that ComboBox is
always list, so if someone would like to change the other parts need to
have dive into view.

On the other hand this solution probably is less flexible than having
through css some parts of that component.

Thanks,
Piotr


czw., 31 maj 2018 o 15:35 Harbs  napisał(a):

> I’m working on redoing ComboBox and I could use some input on best
> practices.
>
> Right now, ComboBox has ComboBox view which has three components
> hard-wired in. It has TextInput, TextButton, and List. If any visuals or
> behavior need to be changed, the entire view needs to be rewritten. We’ve
> already had two cases where I needed a new view. One was to disable the
> TextInput input and change the button appearance. The second was to support
> images in a dropdown.
>
> It seems to me like the ComboBoxView should add the three components based
> on declared classes. I think there should be 1. A “Button” component. 2. An
> ItemRenderer component for the “input” which displays the selected item. 3.
> A List component for displaying the dropdown. The question I’m struggling
> with is how to declare these.
>
> I don’t think it makes sense to make these all beads. Currently Buttons
> are not beads.
>
> Should we add interfaces (i.e. IButton) and declare the classes using
> interfaces? I mean something similar to IItemRenderer.
>
> Maybe just use ValuesManager to just lookup some other “name”? We’re
> currently doing something similar with ColumnClassName in DynamicDataGrid.
>
> Other ideas?
>
> Thanks,
> Harbs



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Restructuring Composite Components

[Harbs]

I’m working on redoing ComboBox and I could use some input on best practices.

Right now, ComboBox has ComboBox view which has three components hard-wired in. 
It has TextInput, TextButton, and List. If any visuals or behavior need to be 
changed, the entire view needs to be rewritten. We’ve already had two cases 
where I needed a new view. One was to disable the TextInput input and change 
the button appearance. The second was to support images in a dropdown.

It seems to me like the ComboBoxView should add the three components based on 
declared classes. I think there should be 1. A “Button” component. 2. An 
ItemRenderer component for the “input” which displays the selected item. 3. A 
List component for displaying the dropdown. The question I’m struggling with is 
how to declare these.

I don’t think it makes sense to make these all beads. Currently Buttons are not 
beads.

Should we add interfaces (i.e. IButton) and declare the classes using 
interfaces? I mean something similar to IItemRenderer.

Maybe just use ValuesManager to just lookup some other “name”? We’re currently 
doing something similar with ColumnClassName in DynamicDataGrid.

Other ideas?

Thanks,
Harbs

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

[Harbs]

I’m not sure if we’re communicating.

Composite TLCs have many pieces and only some of them are related to View. 
DataGrid has 5 class reference and only one is IBeadView. DataGrid uses 
DataGridColumnList which has 9 class references. One is view and another which 
might (or might not) need replacement is layout. Other than these classes, the 
whole component should just work as-is in Jewel. All you need is to swap out 
the IBeadView and/or part of the view.

We *would* need to make sure that the swapped view classes are not imported 
unnecessarily. (I’m not sure if they are or not.) If they are, I think it’s 
clear that is a bug which needs to be fixed no-matter. Defaults should not be 
imported if overridden by applications.

Maybe we should wait on this decision until Jewel is more complete? It’s 
possible that you are right and none of the TLCs will end up in Jewel. It’s 
possible I’m right and they will. I don’t see how restructuring Basic is 
necessary until we’re sure of the outcome of that.

Thoughts?
Harbs

> On May 31, 2018, at 2:10 PM, Carlos Rovira  wrote:
> 
>> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly
>> ImageButon etc. The components are basically UIBase components which
>> describe how the pieces are wired together. The views are separate
>> components that are declared. For these TLCs, there shouldn’t be a need to
>> duplicate the classes or subclass the classes in Jewel at all. It should be
>> possible to simply use Basic or Express composite TLCs and simply declare a
>> Jewel view to use with them.
>> 
>> 
> yes, if you are seeing that the compositing TLCs are Jewel TLCs. For
> example, ComboBox will compose a Jewel Button not Basic Button, to comply
> with the overall set and purpose. As well will compose a TextInput and a
> List from Jewel, not from Basic. Take into account that the first thing a
> Jewel TLC (basic or complex) will do is set typeNames in constructor to
> "jewel XXX", and then define "component parts" like button:Button (of Jewel
> set).
> 
> Image Button will as well composite a Jewel Button. DataGrid is a complex
> TLC that will be using jewel TLCs and other build blocks currently in
> Basic, that should move to Foundation (or whatever we want to call to
> "reusable library with common code and beads").
> 
> What is clear is that all pieces that are reusable in ComboBox, DataGrid or
> ImageButton will be used to create those components in Jewel, as many as we
> can.
> All those components will have its own Jewel view to make its own visuals,
> like SliderView in jewel needs that code that is different to basic one
> since it "fills" the bar as we move the thumb.
> 
> 
> 
>> Is there an issue that I’m missing here?
>> 
>> Harbs
>> 
>>> On May 31, 2018, at 12:12 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> concreting more over if Jewel should or not extend Basic TLCs. That I
>> think
>>> is the real point now to discuss. I'm sure it should not be the case. To
>>> sum to all that I exposed, it was not clearly sufficient enough (that I
>>> think it should be). Why I want all the class definitions overhead it
>> will
>>> cause?
>>> 
>>> Why have the basic Button file with all the class text definitions and
>> then
>>> the jewel Button file with all the definitions there? Think that we don't
>>> get anything profitable from all that overhead. I think that reusable
>> code
>>> are pieces to construct, but not pieces designed to be final in some
>> case.
>>> So to build a house I use bricks, cement, beams, and so on, but then I
>>> don't use the house to make a castle.
>>> 
>>> Moreover, think that Basic needs to change some component part...then
>> maybe
>>> Jewel can't do that... that's a huge problem. So think that in the house
>> I
>>> want to change a window from a place to another, then the castle will
>> need
>>> to live with that without any reason and possibility to not be affected.
>>> 
>>> You must to recognize that although the theory here is good (remember
>> that
>>> I started to be aligned with that), the reality is not the same.
>>> 
>>> My experience in many things in life make think that not all is 100%
>> black
>>> or white. I think is great the philosophy we have on PAYG, beads and
>> reuse,
>>> but I the case of TLCs and see that as something optionally extendible,
>> but
>>> not mandatory. Or in other words TLCs are almost a leaf usable component
>>> that is mainly designed with a concrete end or use, and work great in
>>> aggregation (i.e: Express), but should not be part of any mandatory use.
>>> It's building blocks, in opposite, (the bricks) need to be enforced to
>>> reuse as much as we can.
>>> 
>>> Hope this additional vision will help on the overall discussion.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2018-05-31 10:05 GMT+02:00 Harbs :
>>> 
 Comments inline.
 
> On May 31, 2018, at 10:44 AM, Carlos Rovira 
 wrote:
> 
> I think there's a cost, don't know if the cost is higher or lower.
 

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

[Carlos Rovira]

Hi,

2018-05-31 11:35 GMT+02:00 Harbs :

> To me, there are two classes of TLCs.
>
> 1. Simple TLCs are components such as Button, Checkbox, DropDownList etc.
> Which are designed to represent a single HTML element. For these components
> I completely understand and agree with your decision to *NOT* subclass
> Basic TLCs. The styling paradigm is different. We don’t want to bring in
> the superclass CSS, etc. We are in agreement here.
>

Right, agree too


>
> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly
> ImageButon etc. The components are basically UIBase components which
> describe how the pieces are wired together. The views are separate
> components that are declared. For these TLCs, there shouldn’t be a need to
> duplicate the classes or subclass the classes in Jewel at all. It should be
> possible to simply use Basic or Express composite TLCs and simply declare a
> Jewel view to use with them.
>
>
yes, if you are seeing that the compositing TLCs are Jewel TLCs. For
example, ComboBox will compose a Jewel Button not Basic Button, to comply
with the overall set and purpose. As well will compose a TextInput and a
List from Jewel, not from Basic. Take into account that the first thing a
Jewel TLC (basic or complex) will do is set typeNames in constructor to
"jewel XXX", and then define "component parts" like button:Button (of Jewel
set).

Image Button will as well composite a Jewel Button. DataGrid is a complex
TLC that will be using jewel TLCs and other build blocks currently in
Basic, that should move to Foundation (or whatever we want to call to
"reusable library with common code and beads").

What is clear is that all pieces that are reusable in ComboBox, DataGrid or
ImageButton will be used to create those components in Jewel, as many as we
can.
All those components will have its own Jewel view to make its own visuals,
like SliderView in jewel needs that code that is different to basic one
since it "fills" the bar as we move the thumb.



> Is there an issue that I’m missing here?
>
> Harbs
>
> > On May 31, 2018, at 12:12 PM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs,
> >
> > concreting more over if Jewel should or not extend Basic TLCs. That I
> think
> > is the real point now to discuss. I'm sure it should not be the case. To
> > sum to all that I exposed, it was not clearly sufficient enough (that I
> > think it should be). Why I want all the class definitions overhead it
> will
> > cause?
> >
> > Why have the basic Button file with all the class text definitions and
> then
> > the jewel Button file with all the definitions there? Think that we don't
> > get anything profitable from all that overhead. I think that reusable
> code
> > are pieces to construct, but not pieces designed to be final in some
> case.
> > So to build a house I use bricks, cement, beams, and so on, but then I
> > don't use the house to make a castle.
> >
> > Moreover, think that Basic needs to change some component part...then
> maybe
> > Jewel can't do that... that's a huge problem. So think that in the house
> I
> > want to change a window from a place to another, then the castle will
> need
> > to live with that without any reason and possibility to not be affected.
> >
> > You must to recognize that although the theory here is good (remember
> that
> > I started to be aligned with that), the reality is not the same.
> >
> > My experience in many things in life make think that not all is 100%
> black
> > or white. I think is great the philosophy we have on PAYG, beads and
> reuse,
> > but I the case of TLCs and see that as something optionally extendible,
> but
> > not mandatory. Or in other words TLCs are almost a leaf usable component
> > that is mainly designed with a concrete end or use, and work great in
> > aggregation (i.e: Express), but should not be part of any mandatory use.
> > It's building blocks, in opposite, (the bricks) need to be enforced to
> > reuse as much as we can.
> >
> > Hope this additional vision will help on the overall discussion.
> >
> >
> >
> >
> >
> > 2018-05-31 10:05 GMT+02:00 Harbs :
> >
> >> Comments inline.
> >>
> >>> On May 31, 2018, at 10:44 AM, Carlos Rovira 
> >> wrote:
> >>>
> >>> I think there's a cost, don't know if the cost is higher or lower.
> >>
> >> My question is whether we would actually be avoiding this cost by
> pulling
> >> the CSS out of Basic. I don’t know the answer to this question. I
> suspect
> >> that the compiler needs to analyze all the CSS files in every swc in the
> >> libs folder whether they are used or not. If that’s the case, there’s
> >> nothing to gain by pulling out the CSS for at least 90% of the use
> cases of
> >> Royale. Almost all Royale users will have the full lib of swcs.
> >>
> >>> To me is
> >>> not only the cost, is about as well as methodology. For me is incorrect
> >> to
> >>> have a CSS always be compiled, no matter what kind of application I'll
> be
> >>> constructing, even if nothing of that CSS goes into the 

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

[Harbs]

To me, there are two classes of TLCs.

1. Simple TLCs are components such as Button, Checkbox, DropDownList etc. Which 
are designed to represent a single HTML element. For these components I 
completely understand and agree with your decision to *NOT* subclass Basic 
TLCs. The styling paradigm is different. We don’t want to bring in the 
superclass CSS, etc. We are in agreement here.

2, Composite TLCs are components such as ComboBox, DataGrid, possibly 
ImageButon etc. The components are basically UIBase components which describe 
how the pieces are wired together. The views are separate components that are 
declared. For these TLCs, there shouldn’t be a need to duplicate the classes or 
subclass the classes in Jewel at all. It should be possible to simply use Basic 
or Express composite TLCs and simply declare a Jewel view to use with them.

Is there an issue that I’m missing here?

Harbs

> On May 31, 2018, at 12:12 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> concreting more over if Jewel should or not extend Basic TLCs. That I think
> is the real point now to discuss. I'm sure it should not be the case. To
> sum to all that I exposed, it was not clearly sufficient enough (that I
> think it should be). Why I want all the class definitions overhead it will
> cause?
> 
> Why have the basic Button file with all the class text definitions and then
> the jewel Button file with all the definitions there? Think that we don't
> get anything profitable from all that overhead. I think that reusable code
> are pieces to construct, but not pieces designed to be final in some case.
> So to build a house I use bricks, cement, beams, and so on, but then I
> don't use the house to make a castle.
> 
> Moreover, think that Basic needs to change some component part...then maybe
> Jewel can't do that... that's a huge problem. So think that in the house I
> want to change a window from a place to another, then the castle will need
> to live with that without any reason and possibility to not be affected.
> 
> You must to recognize that although the theory here is good (remember that
> I started to be aligned with that), the reality is not the same.
> 
> My experience in many things in life make think that not all is 100% black
> or white. I think is great the philosophy we have on PAYG, beads and reuse,
> but I the case of TLCs and see that as something optionally extendible, but
> not mandatory. Or in other words TLCs are almost a leaf usable component
> that is mainly designed with a concrete end or use, and work great in
> aggregation (i.e: Express), but should not be part of any mandatory use.
> It's building blocks, in opposite, (the bricks) need to be enforced to
> reuse as much as we can.
> 
> Hope this additional vision will help on the overall discussion.
> 
> 
> 
> 
> 
> 2018-05-31 10:05 GMT+02:00 Harbs :
> 
>> Comments inline.
>> 
>>> On May 31, 2018, at 10:44 AM, Carlos Rovira 
>> wrote:
>>> 
>>> I think there's a cost, don't know if the cost is higher or lower.
>> 
>> My question is whether we would actually be avoiding this cost by pulling
>> the CSS out of Basic. I don’t know the answer to this question. I suspect
>> that the compiler needs to analyze all the CSS files in every swc in the
>> libs folder whether they are used or not. If that’s the case, there’s
>> nothing to gain by pulling out the CSS for at least 90% of the use cases of
>> Royale. Almost all Royale users will have the full lib of swcs.
>> 
>>> To me is
>>> not only the cost, is about as well as methodology. For me is incorrect
>> to
>>> have a CSS always be compiled, no matter what kind of application I'll be
>>> constructing, even if nothing of that CSS goes into the final
>> Application.
>>> You're making a useless compilation, that can introduce bugs or not, or
>> you
>>> must keep and eye always that is not doing wrong things. If you don't put
>>> that CSS in mandatory SWC, your problems are all gone. I think CSS should
>>> be *always* in optional SWCs. For me maybe this is the most important
>>> concept or rule we should follow.
>> 
>> In theory, I agree with you. In practice, I’m not so sure.
>> 
>> The problem with pulling the TLC components out of Basic is that it
>> requires a separate dependency for use. That makes more work for someone
>> using Maven (for example). Also the likelihood of NONE of the TLCs to be
>> used by other component sets is slim. I believe that Basic (or Express)
>> composite components (such as ComboBox, DataGrid, etc.) should be used in
>> Jewel and just the views should be swapped out. Dictating that Jewel can’t
>> use Basic TLCs simply on principle is something I have a hard time with.
>> 
>> If using them would have a concrete negative effect on an app, I agree
>> that it would be a problem, but I think we’ve determined that to not be the
>> case.
>> 
>> Thanks,
>> Harbs
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

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

[Carlos Rovira]

Hi Harbs,

concreting more over if Jewel should or not extend Basic TLCs. That I think
is the real point now to discuss. I'm sure it should not be the case. To
sum to all that I exposed, it was not clearly sufficient enough (that I
think it should be). Why I want all the class definitions overhead it will
cause?

Why have the basic Button file with all the class text definitions and then
the jewel Button file with all the definitions there? Think that we don't
get anything profitable from all that overhead. I think that reusable code
are pieces to construct, but not pieces designed to be final in some case.
So to build a house I use bricks, cement, beams, and so on, but then I
don't use the house to make a castle.

Moreover, think that Basic needs to change some component part...then maybe
Jewel can't do that... that's a huge problem. So think that in the house I
want to change a window from a place to another, then the castle will need
to live with that without any reason and possibility to not be affected.

You must to recognize that although the theory here is good (remember that
I started to be aligned with that), the reality is not the same.

My experience in many things in life make think that not all is 100% black
or white. I think is great the philosophy we have on PAYG, beads and reuse,
but I the case of TLCs and see that as something optionally extendible, but
not mandatory. Or in other words TLCs are almost a leaf usable component
that is mainly designed with a concrete end or use, and work great in
aggregation (i.e: Express), but should not be part of any mandatory use.
It's building blocks, in opposite, (the bricks) need to be enforced to
reuse as much as we can.

Hope this additional vision will help on the overall discussion.





2018-05-31 10:05 GMT+02:00 Harbs :

> Comments inline.
>
> > On May 31, 2018, at 10:44 AM, Carlos Rovira 
> wrote:
> >
> > I think there's a cost, don't know if the cost is higher or lower.
>
> My question is whether we would actually be avoiding this cost by pulling
> the CSS out of Basic. I don’t know the answer to this question. I suspect
> that the compiler needs to analyze all the CSS files in every swc in the
> libs folder whether they are used or not. If that’s the case, there’s
> nothing to gain by pulling out the CSS for at least 90% of the use cases of
> Royale. Almost all Royale users will have the full lib of swcs.
>
> > To me is
> > not only the cost, is about as well as methodology. For me is incorrect
> to
> > have a CSS always be compiled, no matter what kind of application I'll be
> > constructing, even if nothing of that CSS goes into the final
> Application.
> > You're making a useless compilation, that can introduce bugs or not, or
> you
> > must keep and eye always that is not doing wrong things. If you don't put
> > that CSS in mandatory SWC, your problems are all gone. I think CSS should
> > be *always* in optional SWCs. For me maybe this is the most important
> > concept or rule we should follow.
>
> In theory, I agree with you. In practice, I’m not so sure.
>
> The problem with pulling the TLC components out of Basic is that it
> requires a separate dependency for use. That makes more work for someone
> using Maven (for example). Also the likelihood of NONE of the TLCs to be
> used by other component sets is slim. I believe that Basic (or Express)
> composite components (such as ComboBox, DataGrid, etc.) should be used in
> Jewel and just the views should be swapped out. Dictating that Jewel can’t
> use Basic TLCs simply on principle is something I have a hard time with.
>
> If using them would have a concrete negative effect on an app, I agree
> that it would be a problem, but I think we’ve determined that to not be the
> case.
>
> Thanks,
> Harbs
>
>


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

Re: Royale snippets for VSCode

[Piotr Zarzycki]

Hi Guys,

Thanks! Looking forward to add new! :)

Enjoy!

On Thu, May 31, 2018, 8:30 AM Alina Kazi  wrote:

> Awesome!!!
>
> -Original Message-
> From: Piotr Zarzycki [mailto:piotrzarzyck...@gmail.com]
> Sent: Wednesday, May 30, 2018 11:43 PM
> To: us...@royale.apache.org; dev@royale.apache.org
> Subject: Royale snippets for VSCode
>
> Hello Royale Developers,
>
> Lately, neminovo has created a useful extension for VSCode, which provides
> a bunch of snippets for Flex SDK.[1] I immediately decided to make exactly
> the same extension but for Apache Royale SDK.
> I created the extension in my GitHub project: royalesnippetsforvscode[2]
> and added a couple of snippets, which are most frequently used by me.
>
> The very first release[3] is available for your VSCode.
>
> Feel free to make a pull request or to suggest any other snippets and I
> will add them in the next version.
>
> You can support ActionScript & MXML engine on Patreon [4].
> You can support Royale snippets on Patreon [5]
>
> [1]
>
> https://marketplace.visualstudio.com/items?itemName=neminovno.vscode-flex-snippets
> [2] https://github.com/piotrzarzycki21/royalesnippetsforvscode
> [3]
>
> https://github.com/piotrzarzycki21/royalesnippetsforvscode/releases/tag/v0.0.1
> [4] https://www.patreon.com/josht
> [5] https://www.patreon.com/piotrzarzycki
>
> Enjoy!,
> Piotr
>
>

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

[Harbs]

Comments inline.

> On May 31, 2018, at 10:44 AM, Carlos Rovira  wrote:
> 
> I think there's a cost, don't know if the cost is higher or lower.

My question is whether we would actually be avoiding this cost by pulling the 
CSS out of Basic. I don’t know the answer to this question. I suspect that the 
compiler needs to analyze all the CSS files in every swc in the libs folder 
whether they are used or not. If that’s the case, there’s nothing to gain by 
pulling out the CSS for at least 90% of the use cases of Royale. Almost all 
Royale users will have the full lib of swcs.

> To me is
> not only the cost, is about as well as methodology. For me is incorrect to
> have a CSS always be compiled, no matter what kind of application I'll be
> constructing, even if nothing of that CSS goes into the final Application.
> You're making a useless compilation, that can introduce bugs or not, or you
> must keep and eye always that is not doing wrong things. If you don't put
> that CSS in mandatory SWC, your problems are all gone. I think CSS should
> be *always* in optional SWCs. For me maybe this is the most important
> concept or rule we should follow.

In theory, I agree with you. In practice, I’m not so sure.

The problem with pulling the TLC components out of Basic is that it requires a 
separate dependency for use. That makes more work for someone using Maven (for 
example). Also the likelihood of NONE of the TLCs to be used by other component 
sets is slim. I believe that Basic (or Express) composite components (such as 
ComboBox, DataGrid, etc.) should be used in Jewel and just the views should be 
swapped out. Dictating that Jewel can’t use Basic TLCs simply on principle is 
something I have a hard time with.

If using them would have a concrete negative effect on an app, I agree that it 
would be a problem, but I think we’ve determined that to not be the case.

Thanks,
Harbs

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

[Carlos Rovira]

I think there's a cost, don't know if the cost is higher or lower. To me is
not only the cost, is about as well as methodology. For me is incorrect to
have a CSS always be compiled, no matter what kind of application I'll be
constructing, even if nothing of that CSS goes into the final Application.
You're making a useless compilation, that can introduce bugs or not, or you
must keep and eye always that is not doing wrong things. If you don't put
that CSS in mandatory SWC, your problems are all gone. I think CSS should
be *always* in optional SWCs. For me maybe this is the most important
concept or rule we should follow.

2018-05-31 9:05 GMT+02:00 Harbs :

> The point of analyzing css is one I hadn’t thought of.
>
> I’m a bit unclear on how the compiler deals with Framework CSS files. How
> does the compiler know which CSS files it needs to examine?
>
> Most compiler methods use royalelib which points to a folder with all the
> Royale swcs. Does it make a difference whether a specific swc is actually
> used?
>
> Unless you are using Maven, the full set of framework libs will always be
> downloaded. If Maven caches a particular sac, would that be in the royale
> lib path as well?
>
> What is the performance hit on analyzing a swc css file? If we’re talking
> a few ms or less, I don’t think it’s worth worrying about.
>
> Thanks,
> Harbs
>
> > On May 31, 2018, at 9:02 AM, Carlos Rovira 
> wrote:
> >
> >> I see a claim that there is a problem because of the compiler parsing a
> >> CSS file from a SWC where that CSS will not be used.  Is there proof
> that
> >> it is a significant performance problem?  Such a claim should be backed
> by
> >> data from an experiment by making the Basic defaults.css one blank line
> and
> >> see if compile time of a Jewel-only example speeds up in a significant
> >> way.  Also, we already have an -exclude-defaults-css-files option.  It
> >> currently does not prevent parsing of the CSS file, but we could make it
> >> so.
> >
> >
> > I don't say it was a performance issue, I said that is no point in
> process
> > a CSS that will never be use.
> > As well if exclude option continues parsing the CSS, seems a bit
> incomplete
> > right?
>
>


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

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

Right.

> On May 31, 2018, at 10:29 AM, Carlos Rovira  wrote:
> 
> Just an important point here: I understand that in this case, we're talking
> about a metadata analyzed at compiler time, so there's no cost at runtime
> and that metadata will not be preserved. I think that would be great
> improvement
> 
> I think Alex is thinking in some kind of metadata at runtime, but I
> understand this is not the case.
> 
> thanks
> 
> 2018-05-31 8:58 GMT+02:00 Harbs  >:
> 
>> I’m not talking about solving subclassing here.
>> 
>> I’m talking about one thing: How to determine what classnames the compiler
>> writes to HTML CSS files for specific types.
>> 
>> Carlos and I would both like for the compiler to compile:
>> j|Button{
>>   background-color: #fff;
>> }
>> 
>> To:
>> .jewel.Button{
>>   background-color: #fff;
>> }
>> 
>> Rather than:
>> org_apache_royale_jewel_Button{
>>   background-color: #fff;
>> }
>> 
>> And we all agree that we don’t want:
>> .Button{
>>   background-color: #fff;
>> }
>> 
>> The question is how to accomplish that. We’re suggesting to include some
>> kind of meta tag or comment in the Button class source which acts as a
>> compiler directive to specify exactly what to output. If you have another
>> suggestion on how we can achieve that goal, that’s fine too.
>> 
>> Makes sense?
>> Harbs
>> 
>>> On May 31, 2018, at 12:30 AM, Alex Harui 
>> wrote:
>>> 
>>> There has always been an option to keep/strip metadata in the output.
>> It is -compiler.keep-as3-metadata.
>>> 
>>> I don't think I understand what you are proposing with metadata.  I
>> thought I'd shown that there was no easy way to solve what the runtime
>> (ValuesManager) should do. I thought we'd agreed upthread that metadata was
>> not required, and we would decide on some short-name abbreviations based on
>> the fully qualified names (package and class name).   The abbreviation
>> scheme doesn't have to be perfect, as long as it reduces likelihood of
>> collision at very low cost.  An example might be that you can register
>> abbreviation mappings so we say that "oarh" is short for
>> "org.apache.royale.html".
>>> 
>>> Thoughts?
>>> -Alex
>>> 
>>> On 5/29/18, 5:47 AM, "Harbs" >>  > harbs.li...@gmail.com >> wrote:
>>> 
>>>   Sorry for the delay in response here. I was not feeling very well
>> last week… (I forgot how much work an infant is…) ;-)
>>> 
>>>   I think it’s time to wrap this up.
>>> 
>>>   I don’t think there’s any completely PAYG solution to this problem. I
>> think conflicts need to be prevented by default.
>>> 
>>>   I like the metadata and .basic.Button approach and I think it’s more
>> PAYG than org_apache_royale_html_Button. Theoretically, component sets can
>> just use “Button” and ignore conflicts for complete PAYG (although I would
>> not recommend that).
>>> 
>>>   We should definitely use metadata that does not insure a runtime tax.
>> If we could somehow strip out the bracket metadata, I prefer that. Using
>> metadata would allow different component sets to make their own decisions.
>>> 
>>>   Thanks,
>>>   Harbs
>>> 
 On May 21, 2018, at 7:41 PM, Alex Harui >>> >
>> wrote:
 
 I think we are in agreement.  My most recent posts were intended to
>> show that #2 is not easily solvable, if at all, and thus we should not
>> invest time or energy there.
 
 My only suggestions regarding #1 is that we do not invent a second
>> naming system, and that whatever we do is PAYG in the sense that I don’t
>> expect users to mix component sets as much as borrow beads from other
>> component sets.  Folks who have the goal of building the smallest possible
>> app with only one component set should not pay for the possibility of
>> mixing in other component sets.
 
 My 2 cents,
 -Alex
 
 On 5/21/18, 7:00 AM, "carlos.rov...@gmail.com 
  > carlos.rov...@gmail.com > 
>>  > carlos.rov...@gmail.com >> on behalf of 
>> Carlos Rovira" <
>> carlos.rov...@gmail.com  
>> >> carlos.rov...@gmail.com  
>> >> on behalf 
>> of
>> carlosrov...@apache.org  
>> > > carlosrov...@apache.org  
>> > styles,
  drawings, colors, fonts) things are showing that before passed
>> unnoticed.
  And now we have the 

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

[Carlos Rovira]

great thanks! :)

2018-05-31 8:50 GMT+02:00 Harbs :

> I’m planning on working on this.
>
> I think it’s very solvable.
>
> > On May 31, 2018, at 9:02 AM, Carlos Rovira 
> wrote:
> >
> >>
> >> I believe we still need a volunteer to change the royale-asjs code to
> >> eliminate use of class selectors in its defaults.css files.
> >>
> >
> > I think this should be done by someone like Peter that is more aware of
> the
> > implications on that part.
>
>


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

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Carlos Rovira]

Just an important point here: I understand that in this case, we're talking
about a metadata analyzed at compiler time, so there's no cost at runtime
and that metadata will not be preserved. I think that would be great
improvement

I think Alex is thinking in some kind of metadata at runtime, but I
understand this is not the case.

thanks

2018-05-31 8:58 GMT+02:00 Harbs :

> I’m not talking about solving subclassing here.
>
> I’m talking about one thing: How to determine what classnames the compiler
> writes to HTML CSS files for specific types.
>
> Carlos and I would both like for the compiler to compile:
> j|Button{
>background-color: #fff;
> }
>
> To:
> .jewel.Button{
>background-color: #fff;
> }
>
> Rather than:
> org_apache_royale_jewel_Button{
>background-color: #fff;
> }
>
> And we all agree that we don’t want:
> .Button{
>background-color: #fff;
> }
>
> The question is how to accomplish that. We’re suggesting to include some
> kind of meta tag or comment in the Button class source which acts as a
> compiler directive to specify exactly what to output. If you have another
> suggestion on how we can achieve that goal, that’s fine too.
>
> Makes sense?
> Harbs
>
> > On May 31, 2018, at 12:30 AM, Alex Harui 
> wrote:
> >
> > There has always been an option to keep/strip metadata in the output.
> It is -compiler.keep-as3-metadata.
> >
> > I don't think I understand what you are proposing with metadata.  I
> thought I'd shown that there was no easy way to solve what the runtime
> (ValuesManager) should do. I thought we'd agreed upthread that metadata was
> not required, and we would decide on some short-name abbreviations based on
> the fully qualified names (package and class name).   The abbreviation
> scheme doesn't have to be perfect, as long as it reduces likelihood of
> collision at very low cost.  An example might be that you can register
> abbreviation mappings so we say that "oarh" is short for
> "org.apache.royale.html".
> >
> > Thoughts?
> > -Alex
> >
> > On 5/29/18, 5:47 AM, "Harbs"  harbs.li...@gmail.com>> wrote:
> >
> >Sorry for the delay in response here. I was not feeling very well
> last week… (I forgot how much work an infant is…) ;-)
> >
> >I think it’s time to wrap this up.
> >
> >I don’t think there’s any completely PAYG solution to this problem. I
> think conflicts need to be prevented by default.
> >
> >I like the metadata and .basic.Button approach and I think it’s more
> PAYG than org_apache_royale_html_Button. Theoretically, component sets can
> just use “Button” and ignore conflicts for complete PAYG (although I would
> not recommend that).
> >
> >We should definitely use metadata that does not insure a runtime tax.
> If we could somehow strip out the bracket metadata, I prefer that. Using
> metadata would allow different component sets to make their own decisions.
> >
> >Thanks,
> >Harbs
> >
> >> On May 21, 2018, at 7:41 PM, Alex Harui 
> wrote:
> >>
> >> I think we are in agreement.  My most recent posts were intended to
> show that #2 is not easily solvable, if at all, and thus we should not
> invest time or energy there.
> >>
> >> My only suggestions regarding #1 is that we do not invent a second
> naming system, and that whatever we do is PAYG in the sense that I don’t
> expect users to mix component sets as much as borrow beads from other
> component sets.  Folks who have the goal of building the smallest possible
> app with only one component set should not pay for the possibility of
> mixing in other component sets.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 5/21/18, 7:00 AM, "carlos.rov...@gmail.com  carlos.rov...@gmail.com> > on behalf of Carlos Rovira" <
> carlos.rov...@gmail.com  carlos.rov...@gmail.com > on behalf of
> carlosrov...@apache.org   carlosrov...@apache.org >> wrote:
> >>
> >>   I think Harbs is right here.
> >>
> >>   We should take into account that as we focus on presentation (CSS,
> styles,
> >>   drawings, colors, fonts) things are showing that before passed
> unnoticed.
> >>   And now we have the chance to address all of this to make
> architecture and
> >>   presentation get to its best. Both things are equally important here,
> >>   Royale finaly has to be very careful with visual things since we are
> an
> >>   interface framework, so if we get styling things works as flexible as
> >>   possible, we can expect designers to work with royale.
> >>
> >>   Thanks
> >>
> >>   2018-05-21 11:35 GMT+02:00 Harbs  harbs.li...@gmail.com>>:
> >>
> >>> I’m getting confused.
> >>>
> >>> Let me try and summarize the issues as I understand them:
> >>>
> >>> There are two different types of issues: Compile time issues, and
> runtime
> >>> issues.
> >>>
> >>> Compile time issues are:
> >>> 1. Compiled css files do not differentiate 

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

[Harbs]

The point of analyzing css is one I hadn’t thought of.

I’m a bit unclear on how the compiler deals with Framework CSS files. How does 
the compiler know which CSS files it needs to examine?

Most compiler methods use royalelib which points to a folder with all the 
Royale swcs. Does it make a difference whether a specific swc is actually used?

Unless you are using Maven, the full set of framework libs will always be 
downloaded. If Maven caches a particular sac, would that be in the royale lib 
path as well?

What is the performance hit on analyzing a swc css file? If we’re talking a few 
ms or less, I don’t think it’s worth worrying about.

Thanks,
Harbs

> On May 31, 2018, at 9:02 AM, Carlos Rovira  wrote:
> 
>> I see a claim that there is a problem because of the compiler parsing a
>> CSS file from a SWC where that CSS will not be used.  Is there proof that
>> it is a significant performance problem?  Such a claim should be backed by
>> data from an experiment by making the Basic defaults.css one blank line and
>> see if compile time of a Jewel-only example speeds up in a significant
>> way.  Also, we already have an -exclude-defaults-css-files option.  It
>> currently does not prevent parsing of the CSS file, but we could make it
>> so.
> 
> 
> I don't say it was a performance issue, I said that is no point in process
> a CSS that will never be use.
> As well if exclude option continues parsing the CSS, seems a bit incomplete
> right?

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

I’m not talking about solving subclassing here.

I’m talking about one thing: How to determine what classnames the compiler 
writes to HTML CSS files for specific types.

Carlos and I would both like for the compiler to compile:
j|Button{
   background-color: #fff;
}

To: 
.jewel.Button{
   background-color: #fff;
}

Rather than:
org_apache_royale_jewel_Button{
   background-color: #fff;
}

And we all agree that we don’t want:
.Button{
   background-color: #fff;
}

The question is how to accomplish that. We’re suggesting to include some kind 
of meta tag or comment in the Button class source which acts as a compiler 
directive to specify exactly what to output. If you have another suggestion on 
how we can achieve that goal, that’s fine too.

Makes sense?
Harbs

> On May 31, 2018, at 12:30 AM, Alex Harui  wrote:
> 
> There has always been an option to keep/strip metadata in the output.  It is 
> -compiler.keep-as3-metadata.
> 
> I don't think I understand what you are proposing with metadata.  I thought 
> I'd shown that there was no easy way to solve what the runtime 
> (ValuesManager) should do. I thought we'd agreed upthread that metadata was 
> not required, and we would decide on some short-name abbreviations based on 
> the fully qualified names (package and class name).   The abbreviation scheme 
> doesn't have to be perfect, as long as it reduces likelihood of collision at 
> very low cost.  An example might be that you can register abbreviation 
> mappings so we say that "oarh" is short for "org.apache.royale.html".
> 
> Thoughts?
> -Alex
> 
> On 5/29/18, 5:47 AM, "Harbs"  > wrote:
> 
>Sorry for the delay in response here. I was not feeling very well last 
> week… (I forgot how much work an infant is…) ;-)
> 
>I think it’s time to wrap this up.
> 
>I don’t think there’s any completely PAYG solution to this problem. I 
> think conflicts need to be prevented by default.
> 
>I like the metadata and .basic.Button approach and I think it’s more PAYG 
> than org_apache_royale_html_Button. Theoretically, component sets can just 
> use “Button” and ignore conflicts for complete PAYG (although I would not 
> recommend that).
> 
>We should definitely use metadata that does not insure a runtime tax. If 
> we could somehow strip out the bracket metadata, I prefer that. Using 
> metadata would allow different component sets to make their own decisions.
> 
>Thanks,
>Harbs
> 
>> On May 21, 2018, at 7:41 PM, Alex Harui  wrote:
>> 
>> I think we are in agreement.  My most recent posts were intended to show 
>> that #2 is not easily solvable, if at all, and thus we should not invest 
>> time or energy there.
>> 
>> My only suggestions regarding #1 is that we do not invent a second naming 
>> system, and that whatever we do is PAYG in the sense that I don’t expect 
>> users to mix component sets as much as borrow beads from other component 
>> sets.  Folks who have the goal of building the smallest possible app with 
>> only one component set should not pay for the possibility of mixing in other 
>> component sets.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 5/21/18, 7:00 AM, "carlos.rov...@gmail.com 
>>  > > on behalf of Carlos Rovira" 
>> > > > on behalf of carlosrov...@apache.org 
>>  > >> wrote:
>> 
>>   I think Harbs is right here.
>> 
>>   We should take into account that as we focus on presentation (CSS, styles,
>>   drawings, colors, fonts) things are showing that before passed unnoticed.
>>   And now we have the chance to address all of this to make architecture and
>>   presentation get to its best. Both things are equally important here,
>>   Royale finaly has to be very careful with visual things since we are an
>>   interface framework, so if we get styling things works as flexible as
>>   possible, we can expect designers to work with royale.
>> 
>>   Thanks
>> 
>>   2018-05-21 11:35 GMT+02:00 Harbs > >:
>> 
>>> I’m getting confused.
>>> 
>>> Let me try and summarize the issues as I understand them:
>>> 
>>> There are two different types of issues: Compile time issues, and runtime
>>> issues.
>>> 
>>> Compile time issues are:
>>> 1. Compiled css files do not differentiate between different packages.
>>> (i.e. ImageButton type selectors will always compile to and .ImageButton
>>> class selector, no matter what the package name is.
>>> 2. There’s no way to prevent superclass dependencies from being included
>>> in output when they are specified in Type selectors in Royale CSS files.
>>> 
>>> Runtime issues:
>>> 1. Because of the issue in #1 above, there can be css styling conflicts
>>> across component sets.
>>> 
>>> I’m pretty sure 

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

[Harbs]

I’m planning on working on this.

I think it’s very solvable.

> On May 31, 2018, at 9:02 AM, Carlos Rovira  wrote:
> 
>> 
>> I believe we still need a volunteer to change the royale-asjs code to
>> eliminate use of class selectors in its defaults.css files.
>> 
> 
> I think this should be done by someone like Peter that is more aware of the
> implications on that part.

RE: Royale snippets for VSCode

[Alina Kazi]

Awesome!!! 

-Original Message-
From: Piotr Zarzycki [mailto:piotrzarzyck...@gmail.com] 
Sent: Wednesday, May 30, 2018 11:43 PM
To: us...@royale.apache.org; dev@royale.apache.org
Subject: Royale snippets for VSCode

Hello Royale Developers,

Lately, neminovo has created a useful extension for VSCode, which provides a 
bunch of snippets for Flex SDK.[1] I immediately decided to make exactly the 
same extension but for Apache Royale SDK.
I created the extension in my GitHub project: royalesnippetsforvscode[2] and 
added a couple of snippets, which are most frequently used by me.

The very first release[3] is available for your VSCode.

Feel free to make a pull request or to suggest any other snippets and I will 
add them in the next version.

You can support ActionScript & MXML engine on Patreon [4].
You can support Royale snippets on Patreon [5]

[1]
https://marketplace.visualstudio.com/items?itemName=neminovno.vscode-flex-snippets
[2] https://github.com/piotrzarzycki21/royalesnippetsforvscode
[3]
https://github.com/piotrzarzycki21/royalesnippetsforvscode/releases/tag/v0.0.1
[4] https://www.patreon.com/josht
[5] https://www.patreon.com/piotrzarzycki

Enjoy!,
Piotr