SharedObjectJSON sounds useful and a good alternative short of AMF. I'm sure you're not surprised to hear me say that we should give users choices depending on their needs. If they only need to store simple values, LocalStorage should work.
I think we do have Strong-Type to JSON and back with the JSONReviver and friends in the Reflection SWC. I wonder if that would work with SharedObjectJSON. My 2 cents, -Alex On 1/30/20, 12:03 PM, "Greg Dove" <[email protected]> wrote: I think the browser can store objects already? Perhaps there is some way to do that, but I could not find anything for localStorage: ' The keys and the values are *always strings* (note that, as with objects, integer keys will be automatically converted to strings). ' The LSO version is an emulation of Flash, so needs AMF to match behaviour. But it doesn't cover everything from the flash version. I made a separate version ' SharedObjectJSON' that uses JSON, and has no AMF dependency: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Fnet%2FSharedObjectJSON.as&data=02%7C01%7Caharui%40adobe.com%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867588036&sdata=b3EqPdXjr2x87PdM5Gg7NUy072eEMo%2FfpSc1NPvnkII%3D&reserved=0 I'd also suggest the JSON version would be probably a good option for new projects that don't need strongly typed instances serialized. I used TDD for working on those. Both of the implementations are tested across swf and js, but I did not add tests to the CI build tests, and I can't remember all the reasons why now, but some tests required manual page refresh to test automatic flush etc. On Fri, Jan 31, 2020 at 8:42 AM Alex Harui <[email protected]> wrote: > Hi Carlos, > > I probably don't understand your use case. I would not recommend to new > projects to use AMF to store data locally. I think the browser can store > objects already? And I would think the difficulty of re-coding > SharedObject.setProperty to LocalStorage.setItem would be worth the effort. > > I must be missing something. > -Alex > > On 1/30/20, 11:35 AM, "Carlos Rovira" <[email protected]> wrote: > > Hi Alex, > > I tried this and reverted the commit since it has more things to be > considered. LSO can be considered part of the AMF set of code, and > depends > on AMF classes that are currently in MXRoyale, for that reason Greg > created > there and not in Storage. These classes will need to be refactored out > of > MXRoyale as we already planned months ago. Right now we need to > exclude CSS > from MXRoyale, to avoid mess with other CSS. Another reason for me (and > maven users) is to avoid have APIs that you don't need (a thing that I > know > is not very important for you or others that could prefer all APIs at > hand, > but that I care for). > > A side from that I think MXRoyale needs to focus on MX and SparkRoyale > on > Spark, as well someday hope I can create MXRPC that have all RPC, > HTTPService, LSO,... If you remember we already talked about this > months > ago, and I tried, but was more time at that moment, and needed to left > the > work in a branch. > > LSO is a flash class and has the benefits of use AMF encoding and > decoding, what > I think is a cool feature to consider (many not for others) and > there's no > MX counterpart, is now part of the emulation due to the AMF issue, but > will > need to be in MXRPC lib. > > I tried LSO for the TodoMVC.com example I'm working on (since is part > of > the specifications in the todomvc.com site), and did not want to add > to the > pom MXRoyale to not confuse new comers, anyway, there's no way for > now, and > we need to left as is. > > Anyway I'm very satisfied with the example since we can see Royale is > now > very robust in many aspects :). Hope to finish it soon and share. > > Thanks > > Carlos > > > > > El jue., 30 ene. 2020 a las 18:28, Alex Harui > (<[email protected]>) > escribió: > > > I don't know if it would be more "general" since it would be > > Flash-specific, but re-use of code from Storage is always a great > goal. > > The MXRoyale components re-use quite a bit of code from Basic. > > > > Taking a quick look at the ASDoc, SharedObject offers both Local and > > Remote flavors and a "connect(NetConnection)" API which is probably > not > > needed for locally storing some data and would drag in dependencies > for > > NetConnection emulation from MXRoyale. Meanwhile, > > org.apache.royale.storage.LocalStorage seems to have a similar API > to the > > subset of SharedObject that folks would actually use for a local > > SharedObject, so the MXRoyale emulation of SharedObject would > probably > > subclass or wrap LocalStorage. > > > > Of course, I could be wrong... > > -Alex > > > > On 1/30/20, 9:05 AM, "Harbs" <[email protected]> wrote: > > > > Possibly a MX version with Flash APIs should use a more general > > version from Storage? > > > > > On Jan 30, 2020, at 5:45 PM, Alex Harui > <[email protected]> > > wrote: > > > > > > I don't know LSO or the Storage SWC that well, but there is > some > > sort of LocalStorageProvider.as file already in Storage. > > > > > > IMO, if you are planning to 100% emulate the Flash LSO, that > should > > go in MXRoyale. A more platform-independent API for local storage > should > > go in Storage. I don't know what is already there. > > > > > > My 2 cents, > > > -Alex > > > > > > On 1/30/20, 7:23 AM, "Carlos Rovira" <[email protected]> > > wrote: > > > > > > Hi, > > > > > > I was searching for some Flex counter part to the LSO > classes in > > MXRoyale > > > but didn't find anything. > > > So if nobody opposite I'll move to the Storage library that > seems > > its > > > natural place. > > > > > > Thanks > > > > > > -- > > > Carlos Rovira > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867598031&sdata=pWys%2B7bseu%2FfikqaQYOrqSS1CPmm4GpGO8q724g0wAs%3D&reserved=0 > > > > > > > > > > > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867598031&sdata=pWys%2B7bseu%2FfikqaQYOrqSS1CPmm4GpGO8q724g0wAs%3D&reserved=0 > > >
