Ugh. Metadata, the "third" language. We'll have to add that to the list of work items.
On 7/16/13 6:25 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >On Jul 16, 2013 5:14 PM, "Alex Harui" <aha...@adobe.com> wrote: >> >> >> >> On 7/16/13 4:51 PM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> >>wrote: >> >> >That would be right if huge applications where created in a consistent >and >> >homogeneous way during all "development life". If the app is tiny >>there's >> >more opportunities that experienced programers make a good work and >>code >> >in >> >the overall. >> > >> >When the app, the team, the code grows over years, more difficult is to >> >see >> >something in that way. For example, we have a product started in Flex 4 >> >alpha, back in 2009. We started with a framework and API that was not >> >finished, we had less experience than we had today, experiment and >>learn >> >lots of things in this 4/5 years. To get all this knowledge in our app, >we >> >need to invest time to upgrade different pieces at different time. >>Today >> >we >> >continue evolving the code base, to simplify old code, readapt, to new >> >best >> >practices incorporated, and so on, through all codebase, trying to not >> >break things. This is a huge task not all people and companies want to >> >perform...take into account that this is a project with 160+ projects >(80+ >> >flex), so changes and improvements in all code base could take a year >>to >> >reach all modules. >> > >> >To rewrite this kind huge product in FlexJS...I think one day we could >get >> >it possible, but that implies we continue evolving and preparing our >>app, >> >and converge with FlexJS some time in the future when flexJS would be >more >> >robust and finished, and event there it would be a monumental task >>since >> >the product still continue growing.... >> > >> >So it's possible...yes, in theory, but I would love to see how many >>real >> >cases we could get (huge real cases) >> >> Yes, I'm interested in finding folks with huge real cases as well. The >> main question is: to what extent are low-level Flash APIs used in your >> app? I had my internal customer grep their code for "import flash.*". >> Most of their imports were for low-level events. This search will show >> you where you used Dictionary. >> >> The harder-to-answer question is about other Flash APIs that aren't >> supported easily on JS like weak references and e4x. You'd have to >>search >> every addEventListener call and find where you used that additional >> parameter. You can search for XMLList and find most places where you >>used >> E4x. >> >> Then there is the even harder-to-answer question about Flash APIs that >>are >> part of the component API that we got for free from Flash like >> useHandCursor or setting filters and blendModes or shaders, and >>transform >> manipulations. >> >> But otherwise, to the extent your app is MXML components glued together >> with ActionScript that doesn't rely on these hard-to-mimic things, it >>will >> be interesting to push this code through FalconJX and FlexJS and see >>where >> it falls down. Lots of APIs from existing Flex components will be >> missing, but I hope to see folks contribute these missing pieces over >time. >> >> I don't know Parsley or Swiz or the other app frameworks, but I'm >> wondering how reliant they were on any of the Flash stuff and if they >>will >> just cross-compile or not. It'll be fun to find out someday... > >I am sure there are others in the list with more knowledge about this, but >custom metadata and describeType is probably very important. > >Om > >> >> -Alex >>
