RE: Uploading files with parameters

Hi Piotr, It looks like IFileModel should have a set fileContent(content:BinaryData):void Then, FileModelWithParams would set the correct param in the FormData and FileModel would simply set blob. IFileModel.blob should be read only. That way, you can still use the rest of the beads the same

Re: Uploading files with parameters

Hi Yishay, Yes that is a good plan - however I still have some questions to make sure that I will pursue this addition correctly. Then, FileModelWithParams would set the correct param in the FormData Do you agree on my idea have here params:FormData property as I understand ? I agree with the

Re: Build failed in Jenkins: royale-asjs_jsonly #3219

Hi Harbs, I missed your message, sorry. I just have a doubt here. Is that latest update in official GCC visible to us? I mean, don't know if they need to do some publication or update in his side (maybe this change is only in code but is not released yet). And I think we was using a concrete

Re: Crux Branch

Hi Alex, your concerns about Crux name applies to the others like Basic or Jewel (just to name a few). If I search for "Jewel js" in google I get various Jewel libraries (same for Basic js). What makes Jewel appropriate for us is that is an internal name (internal branding) we use to refer to

Re: Maven Royale-compiler build

Great Piotr! : ) El dom., 14 jul. 2019 a las 16:50, Piotr Zarzycki (< piotrzarzyck...@gmail.com>) escribió: > All build are again up and running! > > On Fri, Jul 12, 2019, 4:54 PM Piotr Zarzycki > wrote: > > > The same is with https://builds.apache.org/job/Royale-asjs/1947/console > > > > pt.,

Re: AMF and class aliases

Hi Andrew, El lun., 15 jul. 2019 a las 16:18, Frost, Andrew () escribió: > Hi > > A custom bead for localization is a very good idea, yes. In this instance, > we're looking at a migration from Flex so trying to keep as much of the > original code the same as possible; with a custom (albeit

RE: AMF and class aliases

Hi A custom bead for localization is a very good idea, yes. In this instance, we're looking at a migration from Flex so trying to keep as much of the original code the same as possible; with a custom (albeit generic) bead we've managed to do this. Not sure whether their code was the most

RE: Uploading files with parameters

It sounds right to me. Maybe this [1] code from URLStream will need refactoring one day but I’m not sure. [1] var requestData:Object = urlRequest.data is BinaryData ? (urlRequest.data as BinaryData).data : HTTPUtils.encodeUrlVariables(urlRequest.data);

Re: Uploading files with parameters

This is exactly what I'm saying in my previous email - It has to be refactored here to apply FormData stuff. Thanks for all suggestions! Very helpful! Piotr pon., 15 lip 2019 o 15:37 Yishay Weiss napisał(a): > It sounds right to me. Maybe this [1] code from URLStream will need > refactoring

Re: AMF and class aliases

Also, before I forget: If your legacy flex app includes [Transient] metadata anywhere, don't forget to include that in the keep-as3-metadata as part of the configuration for your royale app version as well. AMFBinaryData will ignore those members with Transient metadata in the amf serialization,

Re: library-path and external-library-path fixes

Hi Josh, that sounds fantastic! Thanks for your work on that! This is also more how I would intuitively expect things to work. I had 'wondered' why we were using 'library-path' instead of 'extenal-library-path' everywhere at different times, but I just followed the existing pattern I guess

Re: AMF and class aliases

Hi Andrew, to answer specifically about: > - the AMF serialization for classes is taking their public properties. We > had removed the public properties and changed them into private properties > plus public get functions, in order to avoid the warning from the Google > Closure Compiler, but the

library-path and external-library-path fixes

Hey folks, I just pushed some commits to royale-compiler and royale-asjs, and I wanted to add a little explanation, and some possible troubleshooting advice if anything seems to have broken in your apps. My work over the last week has been to fix an issue related to specifying dependencies when

Re: library-path and external-library-path fixes

FYI: Found an issue building royale-compiler with Maven. Working on the fix. -- Josh Tynjala Bowler Hat LLC On Mon, Jul 15, 2019 at 12:32 PM Josh Tynjala wrote: > Hey folks, > > I just pushed some commits to royale-compiler and royale-asjs, and I > wanted to add a

Re: library-path and external-library-path fixes

The Maven royale-compiler build is fixed now. :) -- Josh Tynjala Bowler Hat LLC On Mon, Jul 15, 2019 at 1:19 PM Josh Tynjala wrote: > FYI: Found an issue building royale-compiler with Maven. Working on the > fix. > > -- > Josh Tynjala > Bowler Hat LLC

Re: Crux Branch

Hi Carlos, I don't think you understood my point. Probably every good name has been used on GitHub or soon will be. Even Royale was. The question is whether anyone would want to see some other 3rd-party Jewel or Basic library implemented in Royale. I suspect it is unlikely. "Crux" for

Crux Branch

Hi Guys, Actually I resonate with Alex on that. If we use Swiz it will be more catchy to Flex developers who wanted to port something. +1 for having it. Why actually renaming everything. We have renamed whole framework - I think it's enough. ;) Thanks, Piotr On Tue, Jul 16, 2019, 6:14 AM Alex