Re: Jenkins and Falcon
thank you om cyrill On Fri, Mar 1, 2013 at 6:41 PM, Om bigosma...@gmail.com wrote: Cyrill, I dont think anyone is working on this yet. You can request our mentors to add you as a Jenkins admin. I got access by requesting on this list [1] Thanks, Om [1] http://markmail.org/message/yaf7balloqn2zq2j On Thu, Feb 28, 2013 at 11:25 PM, Cyrill Zadra cyrill.za...@gmail.comwrote: Created a while ago the JIRA tasks https://issues.apache.org/jira/browse/FLEX-33357 . I'd like help setting up the jenkins jobs for falcon and falcon tests. How do I get the access to configure a jenkins job? Or is already somebody working on that tasks? Cyrill On Fri, Sep 14, 2012 at 5:53 PM, Raju Bitter r.bitter.mailingli...@googlemail.com wrote: On Fri, Sep 14, 2012 at 4:17 AM, Gordon Smith gosm...@adobe.com wrote: Yes, I think it should build on Linux, and I believe Raju said it he tried building on Linux and it worked. Yes, that's correct. I've been building Falcon on Linux without any problems.
Re: [FalconJx] Refactoring packages
Hi, Mike, first off: I'm sorry if my work messed up something you were working on locally, but hadn't committed yet. You're right that it might have been better if I had first discussed on the list some of what I planned to do. That said, I did make sure all the tests and the VanillaSDK_POC example run correctly before I made any commit. Further, I did commit early, commit often as much as possible, it's just that setting up MXML required some changes in the project structure (more on that below). I didn't see a way to make that process more atomic and still check in only code that compiled without errors. A little belatedly, here is my reasoning behind most of the changes - argued in retrospect, I didn't have a grand evil plan before I started, I just wanted to get MXML parsing started ;-) In general, this is how I understand the structure of the project: there are two levels: API and implementation. The API lives in the 'org.apache.flex.compiler' packages and is mirrored in the implementation (duh) which lives in the 'org.apache.flex.compiler.internal' packages. Until I started out on the MXML work, we had one type of input (AS) and two main types of output: AS and JS. This was mirrored in the project structure: - for AS, there is 'org.apache.flex.compiler.as' and 'org.apache.flex.compiler.internal.as' - for JS, there is 'org.apache.flex.compiler.js' and 'org.apache.flex.compiler.internal.js' Each of these has at least two sub packages: 'codegen' and 'driver'. Each of these sub packages can have output type specific children, e.g. for AMD and Goog. Now with MXML, there is a second type of input and a third basic type of output. So, I created 'org.apache.flex.compiler.mxml' and 'org.apache.flex.compiler.internal.mxml' and associated sub packages. I like symmetry. However, as there are now 2 types of input (AS and MXML), I needed to abstract out some of the AS code that handles input, in order to share it with the MXML code. While looking for a place to put this new 'top level' code, I decided to put that in a package named 'common', which I created - being a fan of symmetry - on the now familiar two levels: 'org.apache.flex.compiler.common' and 'org.apache.flex.compiler.internal.common'. Also, some of the classes that were previously in 'as' really belong in 'common', as they are not specific to AS. As for the tests, I collected all the 'test base' classes, including the new one for MXML, and put them together in 'org.apache.flex.compiler.internal.test'. While doing this, I noticed that there were three nearly identical 'compile' methods in separate classes, so I consolidated those into one 'compile' method, with some supporting and overloading methods. I did not change any 'asserts' and made sure that all tests passed at any time. Now, for my strategy for the MXML parsing: as I said, I like symmetry. As we did for AS, first I want to make sure that FalconJx understands all MXML types that Falcon does (a long list that lives in the Falcon compiler in 'org.apache.flex.compiler.tree.mxml') and is able to output what is put in. To achieve this, I plan to write tests for each of these types/features, much as we did for AS. Once that is 'complete', I plan to start work on the various output types, like FlexJS and VanillaSDK. This I plan to do in a similar way as we did for AMD and Goog, by subclassing the MXML emitter and creating accompanying tests. So, with '-js-output-type=FLEXJS', the compiler will produce Alex's data structures (or whatever, I'm not yet up to speed on 'his' approach) and with '-js-output-type=GOOG' it will output something that makes the VanillaSDK work. Again, symmetry dictates that MXML output will be just as flexible as the AS output is. Mike, I do like to work with you on this project, so maybe we should talk some more about how we can best make this work? I thought about branching, but I couldn't find a workable way to branch only 'compiler.jx' without also having to create a branch of the 'compiler' and 'compiler.jx.tests'. Also, merging stuff from a branch that changed so much might have been more work than refactoring your local code after this monster commit of mine? Also, with MXML now in place, there will be no need for this kind of major architectural changes anymore. Any changes, at least for the foreseeable future, should be much more incremental and 'localised' in nature, allowing us both (and many, many others!?) to work on the code simultaneously without getting in each other's way. Now you know what I have planned, maybe you can explain what you are working on, so I can make sure my messing around won't hurt what you're doing too much? EdB On Fri, Mar 1, 2013 at 5:54 AM, Alex Harui aha...@adobe.com wrote: On 2/28/13 4:22 PM, Michael Schmalle apa...@teotigraphix.com wrote: I want 1451312 reverted Another major refactoring, but... Right, WAY TO MAJOR. This was to much to change in one commit. Mike I'm not sure this counts as a technical
Re: Spark Accordion
If I recall correctly, mobile components have destruction policy declared by ViewNavigatorBase. However, I don't deny that a NavigatorContent with creation/destruction policy is useful, but altering UIComponent (which is already huge) is not the best option in my opinion. All the best, Bogdan On Fri, Mar 1, 2013 at 8:11 AM, Alex Harui aha...@adobe.com wrote: On 2/28/13 9:53 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Hey a while ago, I've looked over the Accordion from adobe.next branch, having the same intention on my mind. What I found out is that they went all the way down, modifying UIComponent to add elementCreationPolicy and elementDestructionPolicy to the NavigatorContent, in order to make the Accordion support creation and destruction policies. Since Accordion component seems the only one who needs that, my approach (which remained an experiment that I haven't had time to finish), was to create a class named NavigatorContentWithPolicies that extends SkinnableContainer, so UIComponent doesn't need to be altered. @Alex or Carol do you know if there were any reason why elementDestructionPolicy was added in UIComponent and not in a way as Bogdan describes? I don't know for sure. It maybe be that we wanted all kinds of containers to allow for destruction policies. I think there are lots of scenarios in mobile where destruction policies are important and NavigatorContent may not always be involved. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- http://www.badu.ro
A guideline for adding new components to the Apache Flex SDK?
Hi, It is great to see that people start to raise their hands to work on new Apache Flex components. I just wanted to share a general concern with you ... How can we guarantee that our new components, coming up in the next versions of the Apache Flex SDK, have the same quality of the existing Adobe Flex components? People, like Chet Haase from the Adobe Flex team, working on the Slider and Scroller components [1], had the capacity to think about their Adobe Flex components for months (if not years) before they have added these components into the Adobe Flex SDK. They also had a team that focused on the mobile components only in Adobe Flex [2]. How can we keep up with the same quality for our components? Wouldn't it make sense to write down a guideline into our wiki so that we have a checklist we can go through before we add new components into the Apache Flex SDK? [1] http://tv.adobe.com/watch/codedependent/animated-scrollbar-and-slider-in-flex-4/ [2] http://www.hufkens.net/2009/10/slider-a-mobile-version-of-the-flex-framework/ -- Sebastian (PPMC) Interaction Designer Looking for a Login Example with Apache Flex? Please check out this code: http://code.google.com/p/masuland/wiki/LoginExample
Re: A guideline for adding new components to the Apache Flex SDK?
I agree On Fri, Mar 1, 2013 at 11:32 AM, Sebastian Mohr flex.masul...@gmail.comwrote: Hi, It is great to see that people start to raise their hands to work on new Apache Flex components. I just wanted to share a general concern with you ... How can we guarantee that our new components, coming up in the next versions of the Apache Flex SDK, have the same quality of the existing Adobe Flex components? People, like Chet Haase from the Adobe Flex team, working on the Slider and Scroller components [1], had the capacity to think about their Adobe Flex components for months (if not years) before they have added these components into the Adobe Flex SDK. They also had a team that focused on the mobile components only in Adobe Flex [2]. How can we keep up with the same quality for our components? Wouldn't it make sense to write down a guideline into our wiki so that we have a checklist we can go through before we add new components into the Apache Flex SDK? [1] http://tv.adobe.com/watch/codedependent/animated-scrollbar-and-slider-in-flex-4/ [2] http://www.hufkens.net/2009/10/slider-a-mobile-version-of-the-flex-framework/ -- Sebastian (PPMC) Interaction Designer Looking for a Login Example with Apache Flex? Please check out this code: http://code.google.com/p/masuland/wiki/LoginExample
Re: [FalconJx] Refactoring packages
Erik, Well you saw the little boy side of me as well as every one else, I'm proud I can show feelings in an email, in this respect, I will never consider myself a professional. The problem I had was with the fact we have been communicating quite nicely and then these two commits. Putting it in New Hampshire speak, it felt like I got a snow ball full of ice hitting my face directly. If we would have talked a bit first at least I could have ducked (prepared to refactor my dependent projects). My project is kind of NDA at the moment but completely uses the compiler.jx platform. This is what I have been talking about I am working on other projects. I actually mean, I am working on other projects that plug into THIS framework. So what you changed affected my project that is not going to be in Apache at the moment. I guess the real reason I got upset was just the communication about refactoring, I thought a month ago we had a conversation that we would talk to each other if we were going to do anything drastic. I understand the commit and review but, I hope we can understand with a project like this, we should review and commit on changes dealing with the test platform and public API. (you know what I'm talking about). Since you explain eloquently your reasons, I will take an hour and get my project working again. BTW, did you mean to commit the SWC in the repository? Mike Quoting Erik de Bruin e...@ixsoftware.nl: Hi, Mike, first off: I'm sorry if my work messed up something you were working on locally, but hadn't committed yet. You're right that it might have been better if I had first discussed on the list some of what I planned to do. That said, I did make sure all the tests and the VanillaSDK_POC example run correctly before I made any commit. Further, I did commit early, commit often as much as possible, it's just that setting up MXML required some changes in the project structure (more on that below). I didn't see a way to make that process more atomic and still check in only code that compiled without errors. A little belatedly, here is my reasoning behind most of the changes - argued in retrospect, I didn't have a grand evil plan before I started, I just wanted to get MXML parsing started ;-) In general, this is how I understand the structure of the project: there are two levels: API and implementation. The API lives in the 'org.apache.flex.compiler' packages and is mirrored in the implementation (duh) which lives in the 'org.apache.flex.compiler.internal' packages. Until I started out on the MXML work, we had one type of input (AS) and two main types of output: AS and JS. This was mirrored in the project structure: - for AS, there is 'org.apache.flex.compiler.as' and 'org.apache.flex.compiler.internal.as' - for JS, there is 'org.apache.flex.compiler.js' and 'org.apache.flex.compiler.internal.js' Each of these has at least two sub packages: 'codegen' and 'driver'. Each of these sub packages can have output type specific children, e.g. for AMD and Goog. Now with MXML, there is a second type of input and a third basic type of output. So, I created 'org.apache.flex.compiler.mxml' and 'org.apache.flex.compiler.internal.mxml' and associated sub packages. I like symmetry. However, as there are now 2 types of input (AS and MXML), I needed to abstract out some of the AS code that handles input, in order to share it with the MXML code. While looking for a place to put this new 'top level' code, I decided to put that in a package named 'common', which I created - being a fan of symmetry - on the now familiar two levels: 'org.apache.flex.compiler.common' and 'org.apache.flex.compiler.internal.common'. Also, some of the classes that were previously in 'as' really belong in 'common', as they are not specific to AS. As for the tests, I collected all the 'test base' classes, including the new one for MXML, and put them together in 'org.apache.flex.compiler.internal.test'. While doing this, I noticed that there were three nearly identical 'compile' methods in separate classes, so I consolidated those into one 'compile' method, with some supporting and overloading methods. I did not change any 'asserts' and made sure that all tests passed at any time. Now, for my strategy for the MXML parsing: as I said, I like symmetry. As we did for AS, first I want to make sure that FalconJx understands all MXML types that Falcon does (a long list that lives in the Falcon compiler in 'org.apache.flex.compiler.tree.mxml') and is able to output what is put in. To achieve this, I plan to write tests for each of these types/features, much as we did for AS. Once that is 'complete', I plan to start work on the various output types, like FlexJS and VanillaSDK. This I plan to do in a similar way as we did for AMD and Goog, by subclassing the MXML emitter and creating accompanying tests. So, with '-js-output-type=FLEXJS', the compiler will produce Alex's data structures (or whatever,
Re: [FalconJx] Refactoring packages
To me, your emotions show your involvement and commitment to the project. Nobody can work together in perfect harmony all the time :-) Just important that nobody draws conclusions in emotional times. Fréderic Cox On 01/03/13 12:46, Michael Schmalle apa...@teotigraphix.com wrote: Erik, Well you saw the little boy side of me as well as every one else, I'm proud I can show feelings in an email, in this respect, I will never consider myself a professional. The problem I had was with the fact we have been communicating quite nicely and then these two commits. Putting it in New Hampshire speak, it felt like I got a snow ball full of ice hitting my face directly. If we would have talked a bit first at least I could have ducked (prepared to refactor my dependent projects). My project is kind of NDA at the moment but completely uses the compiler.jx platform. This is what I have been talking about I am working on other projects. I actually mean, I am working on other projects that plug into THIS framework. So what you changed affected my project that is not going to be in Apache at the moment. I guess the real reason I got upset was just the communication about refactoring, I thought a month ago we had a conversation that we would talk to each other if we were going to do anything drastic. I understand the commit and review but, I hope we can understand with a project like this, we should review and commit on changes dealing with the test platform and public API. (you know what I'm talking about). Since you explain eloquently your reasons, I will take an hour and get my project working again. BTW, did you mean to commit the SWC in the repository? Mike Quoting Erik de Bruin e...@ixsoftware.nl: Hi, Mike, first off: I'm sorry if my work messed up something you were working on locally, but hadn't committed yet. You're right that it might have been better if I had first discussed on the list some of what I planned to do. That said, I did make sure all the tests and the VanillaSDK_POC example run correctly before I made any commit. Further, I did commit early, commit often as much as possible, it's just that setting up MXML required some changes in the project structure (more on that below). I didn't see a way to make that process more atomic and still check in only code that compiled without errors. A little belatedly, here is my reasoning behind most of the changes - argued in retrospect, I didn't have a grand evil plan before I started, I just wanted to get MXML parsing started ;-) In general, this is how I understand the structure of the project: there are two levels: API and implementation. The API lives in the 'org.apache.flex.compiler' packages and is mirrored in the implementation (duh) which lives in the 'org.apache.flex.compiler.internal' packages. Until I started out on the MXML work, we had one type of input (AS) and two main types of output: AS and JS. This was mirrored in the project structure: - for AS, there is 'org.apache.flex.compiler.as' and 'org.apache.flex.compiler.internal.as' - for JS, there is 'org.apache.flex.compiler.js' and 'org.apache.flex.compiler.internal.js' Each of these has at least two sub packages: 'codegen' and 'driver'. Each of these sub packages can have output type specific children, e.g. for AMD and Goog. Now with MXML, there is a second type of input and a third basic type of output. So, I created 'org.apache.flex.compiler.mxml' and 'org.apache.flex.compiler.internal.mxml' and associated sub packages. I like symmetry. However, as there are now 2 types of input (AS and MXML), I needed to abstract out some of the AS code that handles input, in order to share it with the MXML code. While looking for a place to put this new 'top level' code, I decided to put that in a package named 'common', which I created - being a fan of symmetry - on the now familiar two levels: 'org.apache.flex.compiler.common' and 'org.apache.flex.compiler.internal.common'. Also, some of the classes that were previously in 'as' really belong in 'common', as they are not specific to AS. As for the tests, I collected all the 'test base' classes, including the new one for MXML, and put them together in 'org.apache.flex.compiler.internal.test'. While doing this, I noticed that there were three nearly identical 'compile' methods in separate classes, so I consolidated those into one 'compile' method, with some supporting and overloading methods. I did not change any 'asserts' and made sure that all tests passed at any time. Now, for my strategy for the MXML parsing: as I said, I like symmetry. As we did for AS, first I want to make sure that FalconJx understands all MXML types that Falcon does (a long list that lives in the Falcon compiler in 'org.apache.flex.compiler.tree.mxml') and is able to output what is put in. To achieve this, I plan to write tests for each of these types/features, much as we did for AS. Once that is 'complete', I
Re: Spark Accordion
I think tink uses a similar approach as you mentioned bogdan, .. just looking at his source code ;-) Cyrill On Fri, Mar 1, 2013 at 8:52 PM, Bogdan DINU flex.programm...@gmail.com wrote: If I recall correctly, mobile components have destruction policy declared by ViewNavigatorBase. However, I don't deny that a NavigatorContent with creation/destruction policy is useful, but altering UIComponent (which is already huge) is not the best option in my opinion. All the best, Bogdan On Fri, Mar 1, 2013 at 8:11 AM, Alex Harui aha...@adobe.com wrote: On 2/28/13 9:53 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Hey a while ago, I've looked over the Accordion from adobe.next branch, having the same intention on my mind. What I found out is that they went all the way down, modifying UIComponent to add elementCreationPolicy and elementDestructionPolicy to the NavigatorContent, in order to make the Accordion support creation and destruction policies. Since Accordion component seems the only one who needs that, my approach (which remained an experiment that I haven't had time to finish), was to create a class named NavigatorContentWithPolicies that extends SkinnableContainer, so UIComponent doesn't need to be altered. @Alex or Carol do you know if there were any reason why elementDestructionPolicy was added in UIComponent and not in a way as Bogdan describes? I don't know for sure. It maybe be that we wanted all kinds of containers to allow for destruction policies. I think there are lots of scenarios in mobile where destruction policies are important and NavigatorContent may not always be involved. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- http://www.badu.ro
Re: [FalconJx] Refactoring packages
Mike, I got a snow ball full of ice hitting my face directly. If we would have talked a bit first at least I could have ducked (prepared to refactor my Yes, mea culpa on the communication. My project is kind of NDA at the moment but completely uses the compiler.jx platform. This is what I have been talking about I am working on other projects. I actually mean, I am working on other projects that plug into THIS framework. As a mental exercise, purely out of curiosity - as I just promised it won't happen again - would you try to veto changes to an Apache Flex project when those changes negatively affect a private, non-open source project? In light of our newly re-found communication (:-)), which parts of this framework do your private projects rely on? Can I hack away at the MXML stuff without bothering you too much? And, maybe more importantly, will you be donating improvements you make to your local copy of the framework back to Apache and if so, how might those improvements influence the code that's based upon the current version of the framework? BTW, did you mean to commit the SWC in the repository? I meant to commit all the FlexJS files and dependencies for the moment, until I have broken it down into their separate pieces and written test for all of them. I didn't however realize that the swc was a binary, thanks for pointing that out. I'll remove it from the repo on my next commit. Now, moving forward: I'll be doing a lot of work on any file that has MXML in it's name. Do you foresee any problems with that? I might also need to make minor modifications to some of the supporting files. When do you consider a change worthy of discussion? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] Refactoring packages
Quoting Erik de Bruin e...@ixsoftware.nl: Mike, I got a snow ball full of ice hitting my face directly. If we would have talked a bit first at least I could have ducked (prepared to refactor my Yes, mea culpa on the communication. My project is kind of NDA at the moment but completely uses the compiler.jx platform. This is what I have been talking about I am working on other projects. I actually mean, I am working on other projects that plug into THIS framework. As a mental exercise, purely out of curiosity - as I just promised it won't happen again - would you try to veto changes to an Apache Flex project when those changes negatively affect a private, non-open source project? No, I would not, I am sending an email right now that would explain a veto on this commit. I would never veto something based on something you couldn't see. BTW what I am working on WILL be 100% open source when it is released... In light of our newly re-found communication (:-)), which parts of this framework do your private projects rely on? Can I hack away at the MXML stuff without bothering you too much? And, maybe more importantly, will you be donating improvements you make to your local copy of the framework back to Apache and if so, how might those improvements influence the code that's based upon the current version of the framework? Erik, this had nothing to do with my project It had to do with I disagreed with your changes(some of them). Having an external project that uses the framework amplified my reason for disagreement, but I still would have disagreed without that project. There is no local copy! The framework is solid man, I am up to date on all my commits with falcon.jx. I am not developing anything in secret regarding the actual falcon.jx project. BTW, did you mean to commit the SWC in the repository? I meant to commit all the FlexJS files and dependencies for the moment, until I have broken it down into their separate pieces and written test for all of them. I didn't however realize that the swc was a binary, thanks for pointing that out. I'll remove it from the repo on my next commit. Now, moving forward: I'll be doing a lot of work on any file that has MXML in it's name. Do you foresee any problems with that? I might also need to make minor modifications to some of the supporting files. When do you consider a change worthy of discussion? No, go for it, see above, I have no hidden branch of falcon.jx. Mike EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
[FalconJx] Refactor Notes of the last couple commits
Erik, Now that I have got my project's tests passing again, I thought I would voice some of my opinions in a more professional manner after the storm. - 'common' Although I agree with you making things common, I don't agree with having sub packages, it seems redundant and confusing, if a sub package warrants in common, it should have a real package in compiler. - On the note of this change, if we could have talked about this first you would have heard me first say that maybe we should move 'compiler.as' and 'compiler.js' into a 'compiler.codegen' Existing org.apache.flex.compiler.as.codegen org.apache.flex.compiler.js.codegen To; org.apache.flex.compiler.codegen.as org.apache.flex.compiler.codegen.js Which then would have allowed; org.apache.flex.compiler.codegen.IEmitter org.apache.flex.compiler.codegen.IDocEmitter org.apache.flex.compiler.codegen.IEmitterTokens The toplevel codegen becomes the 'common' container. The same change could be applied to 'driver'. This was a mistake on my part when I was originally laying out the first impl of the packages. - The above I will argue for the 'driver' package as well. - Tests, I don't understand why addLibraries() and such in ITestBase are public API. They will never be called outside of the test. In java you would make them abstract and the TestBase class abstract and that creates the subclass contract implicitly. - Also, passing the List as a parameter of those 3 methods encapsulates the actual field, then if you are just overridding them in a sub class, you are not trying to figure out what field goes where, its just a template method that you add entries to the list passed. To me this is enough merrit for at least a discussion about a veto. I hope you can think about these issues, maybe we can change them down the road. Right now there are no reverting necessary. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] Refactor Notes of the last couple commits
Mike, - 'common' Although I agree with you making things common, I don't agree with having sub packages, it seems redundant and confusing, if a sub package warrants in common, it should have a real package in compiler. Might be non-native speaker choosing names... The code I put in 'common' is code that 'as' and 'mxml' have in common. In that sense, for symmetry's sake, I thought it should also have the same sub package structure as both 'as' and 'mxml'. Maybe 'shared' or 'general' might have been better names for the package? - On the note of this change, if we could have talked about this first you would have heard me first say that maybe we should move 'compiler.as' and 'compiler.js' into a 'compiler.codegen' ... The same change could be applied to 'driver'. This was a mistake on my part when I was originally laying out the first impl of the packages. I see two mistakes (your original layout and me blindly copying/extending it) combined creating one humongous refactor when things quiet down a bit ;-) - Tests, I don't understand why addLibraries() and such in ITestBase are public API. They will never be called outside of the test. In java you would make them abstract and the TestBase class abstract and that creates the subclass contract implicitly. At least one of them has an implementation in TestBase, and the others may well have one in the future... I'm not that familiar with Java - and AS has no 'abstract' - but wouldn't having an implementation prohibit the declaration from being abstract? - Also, passing the List as a parameter of those 3 methods encapsulates the actual field, then if you are just overridding them in a sub class, you are not trying to figure out what field goes where, its just a template method that you add entries to the list passed. That was your original implementation, but again my lack of familiarity with Java is probably causing me some problems here. I figured that calling 'super' with the list as argument might cause problems. In hindsight, it might have been a different aspect of my implementation that was causing the problem, prompting the change and loosing the advantage of the original approach (would this still work when using ITestbase?) I hope you can think about these issues, maybe we can change them down the road. Right now there are no reverting necessary. Excellent! EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] Refactor Notes of the last couple commits
Your right about the abstract, that is not something we want to force since its on demand invoking. They should be protected and pass the collection though. As I said, the 'as' and 'js' packages within compiler was my mistake. I agree that once things get more stable we should talk about one final refactor that moves everything to their most logical placements within the compiler hierarchy. I work with people to the point of idealism Erik, I will never understand the way somethings get developed in this world, such waste of resources. Communication saves resources, especially that most valuable resource, time. Mike Quoting Erik de Bruin e...@ixsoftware.nl: Mike, - 'common' Although I agree with you making things common, I don't agree with having sub packages, it seems redundant and confusing, if a sub package warrants in common, it should have a real package in compiler. Might be non-native speaker choosing names... The code I put in 'common' is code that 'as' and 'mxml' have in common. In that sense, for symmetry's sake, I thought it should also have the same sub package structure as both 'as' and 'mxml'. Maybe 'shared' or 'general' might have been better names for the package? - On the note of this change, if we could have talked about this first you would have heard me first say that maybe we should move 'compiler.as' and 'compiler.js' into a 'compiler.codegen' ... The same change could be applied to 'driver'. This was a mistake on my part when I was originally laying out the first impl of the packages. I see two mistakes (your original layout and me blindly copying/extending it) combined creating one humongous refactor when things quiet down a bit ;-) - Tests, I don't understand why addLibraries() and such in ITestBase are public API. They will never be called outside of the test. In java you would make them abstract and the TestBase class abstract and that creates the subclass contract implicitly. At least one of them has an implementation in TestBase, and the others may well have one in the future... I'm not that familiar with Java - and AS has no 'abstract' - but wouldn't having an implementation prohibit the declaration from being abstract? - Also, passing the List as a parameter of those 3 methods encapsulates the actual field, then if you are just overridding them in a sub class, you are not trying to figure out what field goes where, its just a template method that you add entries to the list passed. That was your original implementation, but again my lack of familiarity with Java is probably causing me some problems here. I figured that calling 'super' with the list as argument might cause problems. In hindsight, it might have been a different aspect of my implementation that was causing the problem, prompting the change and loosing the advantage of the original approach (would this still work when using ITestbase?) I hope you can think about these issues, maybe we can change them down the road. Right now there are no reverting necessary. Excellent! EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [MENTORS] Jenkins access
Your PMC Chair - Alex can do this. Or Greg. Regards, Dave On Feb 28, 2013, at 11:48 PM, Cyrill Zadra wrote: Hi mentors, Could you please give me access to Jenkins? My username is: czadra thx, cyrill
Spark ColorPicker
I've expanded the Bogdan ColorPicker to accept a dataProvider including color objects similar to the way the mx ColorPicker worked. I have a few things that I could use input on: 1) Both the skin and the component have functions to compute the color depending on whether it's a uint or object. As it stands the functions are duplicated. Is it a better design to have the function in a single place (i.e. the main component or a utility class)? 2) ColorChangeEvent dispatches the color an a uint. This is the way the mx component worked as well. I'm thinking that it makes more sense for the event to contain a color object for complex color objects. It is conceivable to have two color objects with the same color value. I'm thinking of changing the type of the color payload to * and it'll contain whatever is selected whether a uint or complex object. Another possibility is adding a data property which would contain the color object. Thoughts? 3) I personally extended the component to be able to select arbitrary colors for my own use. Does anyone see value of adding that capability to the main component? I'll probably attach my changes to a JIRA ticket next week… Harbs
Re: Spark Accordion
If we choose the Accordion in adobe.next branch I would suggest following steps: 1) Moving all relevant classes to develop branch direct in spark project (not experimental project). 2) Writing mustella tests for accordion. I guess it should be 2 first, then 1 if you want to move them to the spark lib otherwize I guess, it's preferable to move them to the experimental lib as we did with the Bogdan's components, btw, there's also a thread A guideline for adding new components to the Apache Flex SDK? where we can talk about it, what do you think ? -Fred -Message d'origine- From: Cyrill Zadra Sent: Friday, March 01, 2013 6:53 AM To: dev@flex.apache.org Subject: Re: Spark Accordion Hey a while ago, I've looked over the Accordion from adobe.next branch, having the same intention on my mind. What I found out is that they went all the way down, modifying UIComponent to add elementCreationPolicy and elementDestructionPolicy to the NavigatorContent, in order to make the Accordion support creation and destruction policies. Since Accordion component seems the only one who needs that, my approach (which remained an experiment that I haven't had time to finish), was to create a class named NavigatorContentWithPolicies that extends SkinnableContainer, so UIComponent doesn't need to be altered. @Alex or Carol do you know if there were any reason why elementDestructionPolicy was added in UIComponent and not in a way as Bogdan describes? Besides a bug about specifying width / height on AccordionContent that produces malfunction (never closes), the Accordion component seems compliant to pairing the MX one. Yes .. until now I have the same impression that it brings everything that the mx one does. Just having some issue with the icon attribute I'm trying to figure out. I haven't look at tink's source code yet just at his examples [1] .. but I definitely look also at his source code. If we choose the Accordion in adobe.next branch I would suggest following steps: 1) Moving all relevant classes to develop branch direct in spark project (not experimental project). 2) Writing mustella tests for accordion. Or would you prefer the experimental project? [1]http://www.tink.ws/examples/apache-flex/
Re: A guideline for adding new components to the Apache Flex SDK?
I think it is better to reset expectations. Sure, if we take a team of several people and develop a component in private, we can introduce to the public something with relatively high quality several weeks or months after we start, but I honestly don't think that is the most efficient policy. If you are reading this, then you are now part of that team, and instead of developing in private, we are doing it in the open. This means that early checkins may be as awful and bug-filled as any early checkins the Adobe folks saw internally, but it also means we have opportunity to get more feedback much sooner. So yes, new components may make their first appearance in a release with the same sense of quality you might have expected from Adobe, but I think we just have to manage expectations. The release notes can mention which components are new and may be in alpha or beta stages. And we also get to release more often so we can react to major issues found more quickly. On 3/1/13 4:21 AM, Nicholas Kwiatkowski nicho...@spoon.as wrote: I think this is a self-policing thing that has been going on, and will probably continue to go on. I know that many of us watch the commits as they come through (Alex I know dives into anything I touch, code-wise... that's probably a good thing). I personally have gotten feedback on many of the things that have happened in my own whiteboard. -Nick On Fri, Mar 1, 2013 at 6:32 AM, Sebastian Mohr flex.masul...@gmail.comwrote: Hi, It is great to see that people start to raise their hands to work on new Apache Flex components. I just wanted to share a general concern with you ... How can we guarantee that our new components, coming up in the next versions of the Apache Flex SDK, have the same quality of the existing Adobe Flex components? People, like Chet Haase from the Adobe Flex team, working on the Slider and Scroller components [1], had the capacity to think about their Adobe Flex components for months (if not years) before they have added these components into the Adobe Flex SDK. They also had a team that focused on the mobile components only in Adobe Flex [2]. How can we keep up with the same quality for our components? Wouldn't it make sense to write down a guideline into our wiki so that we have a checklist we can go through before we add new components into the Apache Flex SDK? [1] http://tv.adobe.com/watch/codedependent/animated-scrollbar-and-slider-in-flex -4/ [2] http://www.hufkens.net/2009/10/slider-a-mobile-version-of-the-flex-framework/ -- Sebastian (PPMC) Interaction Designer Looking for a Login Example with Apache Flex? Please check out this code: http://code.google.com/p/masuland/wiki/LoginExample -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: github mirrors aren't in sync anymore
Feel free to ping in JIRA again. And keep an eye out for my draft report to the board next week. If I have forgotten to mention it, remind me and we'll mention it in the board report. On 2/28/13 11:12 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Hi Alex It looks like the github mirrors are still not synced (except flex-sdk) . A few days ago I wrote a comment on the JIRA task [1]. Is there anything we/you could do? Cyrill [1] https://issues.apache.org/jira/browse/INFRA-5690 On Wed, Jan 16, 2013 at 12:12 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Currently only https://github.com/apache/flex-sdk is being in sync with github. All the other projects aren't working anymore. https://github.com/apache/flex-falcon https://github.com/apache/flex-utilities https://github.com/apache/flex-whiteboard https://github.com/apache/flex-tlf https://github.com/apache/flex-site I added a comment to https://issues.apache.org/jira/browse/INFRA-5690 but I can't reopen the task. Alex do you have the rights to reopen it? Cyrill -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: A guideline for adding new components to the Apache Flex SDK?
By the way the list of components in the spark namespace hasn't been updated in a while is there any current track to know where people can help or start helping ? On Fri, Mar 1, 2013 at 5:50 PM, Alex Harui aha...@adobe.com wrote: I think it is better to reset expectations. Sure, if we take a team of several people and develop a component in private, we can introduce to the public something with relatively high quality several weeks or months after we start, but I honestly don't think that is the most efficient policy. If you are reading this, then you are now part of that team, and instead of developing in private, we are doing it in the open. This means that early checkins may be as awful and bug-filled as any early checkins the Adobe folks saw internally, but it also means we have opportunity to get more feedback much sooner. So yes, new components may make their first appearance in a release with the same sense of quality you might have expected from Adobe, but I think we just have to manage expectations. The release notes can mention which components are new and may be in alpha or beta stages. And we also get to release more often so we can react to major issues found more quickly. On 3/1/13 4:21 AM, Nicholas Kwiatkowski nicho...@spoon.as wrote: I think this is a self-policing thing that has been going on, and will probably continue to go on. I know that many of us watch the commits as they come through (Alex I know dives into anything I touch, code-wise... that's probably a good thing). I personally have gotten feedback on many of the things that have happened in my own whiteboard. -Nick On Fri, Mar 1, 2013 at 6:32 AM, Sebastian Mohr flex.masul...@gmail.com wrote: Hi, It is great to see that people start to raise their hands to work on new Apache Flex components. I just wanted to share a general concern with you ... How can we guarantee that our new components, coming up in the next versions of the Apache Flex SDK, have the same quality of the existing Adobe Flex components? People, like Chet Haase from the Adobe Flex team, working on the Slider and Scroller components [1], had the capacity to think about their Adobe Flex components for months (if not years) before they have added these components into the Adobe Flex SDK. They also had a team that focused on the mobile components only in Adobe Flex [2]. How can we keep up with the same quality for our components? Wouldn't it make sense to write down a guideline into our wiki so that we have a checklist we can go through before we add new components into the Apache Flex SDK? [1] http://tv.adobe.com/watch/codedependent/animated-scrollbar-and-slider-in-flex -4/ [2] http://www.hufkens.net/2009/10/slider-a-mobile-version-of-the-flex-framework/ -- Sebastian (PPMC) Interaction Designer Looking for a Login Example with Apache Flex? Please check out this code: http://code.google.com/p/masuland/wiki/LoginExample -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Spark List instantiates an extra orphaned ItemRenderer (ostensibly for measuring)
Thanks to a brief, though, informative response to this question on the Adobe AIR forums, I've been told that when I instantiate a Spark List and assign it a custom item renderer and a data provider, that the reason it instantiates four item renderers (one for each item in my DataProvider), that properly are contextual children of the List control, and then instantiates a fifth orphaned instance of the renderer is 'for measurement'. I assume the answer I was given is correct, but the reality (not the answer) is distinctly distasteful and unsatisfying. In a day and age when we are trying to optimize programs to run on what are, frankly, the technological equivalent of 15-20 year old computers (1ghz processors and limited RAM) with end users expecting them to behave in a snappy non-latent manner as they would on a desktop machine with multi-multi-gHz cores, several GB of memory, and a GPU handling a lot of the load (as unrealistic as that may be... ...one of the major reasons I believe Adobe gave up on a mobile browser flash player), I cannot understand why something that seems so very wasteful is necessary. I don't pretend to understand the nuts and bolts of how the SDK accomplishes what it does... that's why it's an Abstract. I usually don't need to know... But I'm faced with a situation where I'm trying to understand why when I instantiate a view it basically halts an iPad2 for 11-13 seconds before displaying the new view... and when I investigate, I find that the processor intensive task I'm trying to complete is made that much more intensive by a factor of 20%. If I'm to believe my trace statements, the creationComplete event is being called on legitimate items 1, 2, 3, and 4, which, I would believe would make them available to be measured and do layout, starting with the first, and made all the more simple because my List has been told to use uniform row height... (which I assume means, 'figure out the first and go with it'). Very grateful for any insight... Especially if it would mean also having a way to help my extreme latency problem. I cannot even get a BusyIndicator to display and rotate before loading the view w/o using a timer to load the view after a brief time... and then it freezes the BusyIndicator. Frustrating... very frustrating. -- // Christian M. Cepel - Programmer/Analyst, Sr., University of Missouri *And the wrens have returned, and are nesting;* *In the hollow of that oak, where his heart once had been.* *And he lifts up his arms in a blessing, for being born again.* Rich Mullins, The Color Green, A Liturgy, a Legacy, a Ragamuffin Band
Re: Spark List instantiates an extra orphaned ItemRenderer (ostensibly for measuring)
If you can get the profiler performance sample, it should show you where the time is being spent. I would hope one extra renderer isn't the culprit, but you never know. But yes, in many cases it isn't necessary so we shouldn't always create it. If you have further questions about profiling, please use the us...@flex.apache.org mailing list. I'm sure others will be interested. You can even post links to screenshots of the profiler screens and we'll try to help you interpret it. One tip: turn off all the default filters on the profiler snapshots (there's a button/icon the right hand side). On 3/1/13 10:06 AM, Christian M. Cepel puddleg...@marshwiggle.org wrote: Thanks to a brief, though, informative response to this question on the Adobe AIR forums, I've been told that when I instantiate a Spark List and assign it a custom item renderer and a data provider, that the reason it instantiates four item renderers (one for each item in my DataProvider), that properly are contextual children of the List control, and then instantiates a fifth orphaned instance of the renderer is 'for measurement'. I assume the answer I was given is correct, but the reality (not the answer) is distinctly distasteful and unsatisfying. In a day and age when we are trying to optimize programs to run on what are, frankly, the technological equivalent of 15-20 year old computers (1ghz processors and limited RAM) with end users expecting them to behave in a snappy non-latent manner as they would on a desktop machine with multi-multi-gHz cores, several GB of memory, and a GPU handling a lot of the load (as unrealistic as that may be... ...one of the major reasons I believe Adobe gave up on a mobile browser flash player), I cannot understand why something that seems so very wasteful is necessary. I don't pretend to understand the nuts and bolts of how the SDK accomplishes what it does... that's why it's an Abstract. I usually don't need to know... But I'm faced with a situation where I'm trying to understand why when I instantiate a view it basically halts an iPad2 for 11-13 seconds before displaying the new view... and when I investigate, I find that the processor intensive task I'm trying to complete is made that much more intensive by a factor of 20%. If I'm to believe my trace statements, the creationComplete event is being called on legitimate items 1, 2, 3, and 4, which, I would believe would make them available to be measured and do layout, starting with the first, and made all the more simple because my List has been told to use uniform row height... (which I assume means, 'figure out the first and go with it'). Very grateful for any insight... Especially if it would mean also having a way to help my extreme latency problem. I cannot even get a BusyIndicator to display and rotate before loading the view w/o using a timer to load the view after a brief time... and then it freezes the BusyIndicator. Frustrating... very frustrating. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Spark List instantiates an extra orphaned ItemRenderer (ostensibly for measuring)
Christian, have you tried to define a typicalItem in the list? Does it behave the same? If you want a better way to track those performance issues, try to create a release version of your app and enable advanced telemetry on it. Then use scout to track what's really messing up between view changes. On 1 March 2013 18:06, Christian M. Cepel puddleg...@marshwiggle.orgwrote: Thanks to a brief, though, informative response to this question on the Adobe AIR forums, I've been told that when I instantiate a Spark List and assign it a custom item renderer and a data provider, that the reason it instantiates four item renderers (one for each item in my DataProvider), that properly are contextual children of the List control, and then instantiates a fifth orphaned instance of the renderer is 'for measurement'. I assume the answer I was given is correct, but the reality (not the answer) is distinctly distasteful and unsatisfying. In a day and age when we are trying to optimize programs to run on what are, frankly, the technological equivalent of 15-20 year old computers (1ghz processors and limited RAM) with end users expecting them to behave in a snappy non-latent manner as they would on a desktop machine with multi-multi-gHz cores, several GB of memory, and a GPU handling a lot of the load (as unrealistic as that may be... ...one of the major reasons I believe Adobe gave up on a mobile browser flash player), I cannot understand why something that seems so very wasteful is necessary. I don't pretend to understand the nuts and bolts of how the SDK accomplishes what it does... that's why it's an Abstract. I usually don't need to know... But I'm faced with a situation where I'm trying to understand why when I instantiate a view it basically halts an iPad2 for 11-13 seconds before displaying the new view... and when I investigate, I find that the processor intensive task I'm trying to complete is made that much more intensive by a factor of 20%. If I'm to believe my trace statements, the creationComplete event is being called on legitimate items 1, 2, 3, and 4, which, I would believe would make them available to be measured and do layout, starting with the first, and made all the more simple because my List has been told to use uniform row height... (which I assume means, 'figure out the first and go with it'). Very grateful for any insight... Especially if it would mean also having a way to help my extreme latency problem. I cannot even get a BusyIndicator to display and rotate before loading the view w/o using a timer to load the view after a brief time... and then it freezes the BusyIndicator. Frustrating... very frustrating. -- // Christian M. Cepel - Programmer/Analyst, Sr., University of Missouri *And the wrens have returned, and are nesting;* *In the hollow of that oak, where his heart once had been.* *And he lifts up his arms in a blessing, for being born again.* Rich Mullins, The Color Green, A Liturgy, a Legacy, a Ragamuffin Band -- João Fernandes
Re: svn commit: r1451713 - in /flex/asjs/branches/develop/frameworks/as/src/org/apache/flex: core/ html/staticControls/ html/staticControls/beads/models/
Looks mostly ok, but Array has the same issue as Object. It will cause
memory leaks unless you know of a way to clean up the Array.
Maybe one approach is to have a property on each RadioButton instance that
is the selectedValue that way there isn't an external entity to query: You
can ask any RadioButton which one is selected. RadioButtons could probably
reference each other because they'll get thrown away as a group. The only
question is how do they find each other? Maybe on the AS side you can use a
Dictionary and on the JS side it doesn't matter, you can query whatever
array is created for them. I guess the JS RBs must know how to find each
other.
On 3/1/13 12:49 PM, p...@apache.org p...@apache.org wrote:
Author: pent
Date: Fri Mar 1 20:49:58 2013
New Revision: 1451713
URL: http://svn.apache.org/r1451713
Log:
Moved button group management to the RadioButton. Map to IButtonGroup is done
through ValuesManager
Added:
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/IButtonGroup
.as (with props)
Modified:
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/ButtonGroup.
as
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/IRadioButton
Bead.as
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/IValueToggle
ButtonModel.as
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/html/staticContro
ls/RadioButton.as
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/html/staticContro
ls/beads/models/ValueToggleButtonModel.as
Modified:
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/ButtonGroup.
as
URL:
http://svn.apache.org/viewvc/flex/asjs/branches/develop/frameworks/as/src/org/
apache/flex/core/ButtonGroup.as?rev=1451713r1=1451712r2=1451713view=diff
==
---
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/ButtonGroup.
as (original)
+++
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/ButtonGroup.
as Fri Mar 1 20:49:58 2013
@@ -21,27 +21,8 @@ package org.apache.flex.core
import flash.events.Event;
import flash.events.EventDispatcher;
- public class ButtonGroup extends EventDispatcher
+ public class ButtonGroup extends EventDispatcher implements IButtonGroup
{
- private static var groups:Object;
-
- public static function getGroup( name:String ) : ButtonGroup
- {
- if( groups == null ) {
-groups = new Object();
- }
-
- var result:ButtonGroup;
- if( groups.hasOwnProperty(name) ) result = groups[name];
- else {
-result = new ButtonGroup();
-result.name = name;
-groups[name] = result;
- }
- return result;
- }
-
-
public function ButtonGroup()
{
}
Added:
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/IButtonGroup
.as
URL:
http://svn.apache.org/viewvc/flex/asjs/branches/develop/frameworks/as/src/org/
apache/flex/core/IButtonGroup.as?rev=1451713view=auto
==
---
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/IButtonGroup
.as (added)
+++
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/IButtonGroup
.as Fri Mar 1 20:49:58 2013
@@ -0,0 +1,31 @@
+/
///
+//
+// Licensed to the Apache Software Foundation (ASF) under one or more
+// contributor license agreements. See the NOTICE file distributed with
+// this work for additional information regarding copyright ownership.
+// The ASF licenses this file to You under the Apache License, Version 2.0
+// (the License); you may not use this file except in compliance with
+// the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an AS IS BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+//
+/
///
+package org.apache.flex.core
+{
+ import flash.events.IEventDispatcher;
+
+ public interface IButtonGroup extends IEventDispatcher
+ {
+ function get name() : String;
+ function set name(value:String):void;
+
+ function get value() : Object;
+ function set value(newValue:Object):void;
+ }
+}
\ No newline at end of file
Propchange:
flex/asjs/branches/develop/frameworks/as/src/org/apache/flex/core/IButtonGroup
.as
--
svn:eol-style = native
Modified:
Re: [MENTORS] Jenkins access
Thanks you .. it's working. Cyrill On Sat, Mar 2, 2013 at 3:41 AM, Alex Harui aha...@adobe.com wrote: OK, I did it. On 3/1/13 6:36 AM, Dave Fisher dave2w...@comcast.net wrote: Your PMC Chair - Alex can do this. Or Greg. Regards, Dave On Feb 28, 2013, at 11:48 PM, Cyrill Zadra wrote: Hi mentors, Could you please give me access to Jenkins? My username is: czadra thx, cyrill -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Latest on FlexJS
Ok, I've reduced the number of setup steps and posted on the wiki here: https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+Adobe+Fla sh+Builder Feedback welcome, -Alex On 2/25/13 4:29 PM, Om bigosma...@gmail.com wrote: Thanks for this Alex. I am trying to keep up as much as possible. Do you mind putting these instructions up on the wiki as well? Thanks, Om On Mon, Feb 25, 2013 at 4:26 PM, Alex Harui aha...@adobe.com wrote: OK, time for another update before I get lost in ApacheCon: I¹ve added the FalconJS stuff to the FlexJSOverlay.zip. You can now use Flash Builder to create non-Flash apps. We have prototypes of a List, Button, Label, TextArea, and TextInput We have a prototype of a HTTPService and a LazyCollection The FlexJSSDKTest example is updated so you can choose a stock symbol from the List, hit a Button and see the stock price in the Label If you want to play with the this stuff and are too lazy to build from the sources, I have hacked together a way for you to try it in Flash Builder. Setup instructions are: 1) Get Apache Flex 4.9 working in FB. (I tried it with FB 4.7, but not FB 4.6) 2) Shut down FB 3) Make a copy of your Apache Flex 4.9 folder. The zip file contains a shell script that will neuter the Flex aspects of this folder and replace it with FlexJS stuff. 4) Unzip FlexJSOverlay into a some other folder. 5) Change to that folder and run deploy.sh or deploy.bat path to copy of Apache Flex 4.9 folder 6) Run Flash Builder 7) In the Flash Builder Preferences menu add this new folder as a Flex SDK. 8) Choose from the File menu, Import, Run/Debug, Launch Configurations 9) Choose the ide/flashbuilder folder from this copy of Apache Flex 4.9 we are mucking with. 10) There should now be four new configs in the Run menu under External Tools 11) Go to External Tools Configuration 12) Select one of the configs 13) Hit the variables button 14) Hit the Edit Variables button 15) Change FLEX_HOME to point to the modified Apache Flex SDK. 16) Install Google Closure library 17) For each of the two FalconJS configs, edit the launch configurations environment variables to set FLEXJS_HOME to the js/src of your overlaid SDK 18) For each of the two FalconJS configs, edit the launch configurations environment variables to set GOOG_HOME to the goog folder of your GoogleClosure install. 19) For each of the four launch configurations, ensure that the location field points to the Java runtime. Now for each project: 1) Create a new Flex Project 2) Choose this modified Apache Flex SDK 3) Do not change the output folder from bin-debug 4) Flash Builder will generate a totally messed up Application tag so replace it with this template: ?xml version=1.0 encoding=utf-8? basic:Application xmlns:fx=http://ns.adobe.com/mxml/2009; xmlns:basic=library://ns.apache.org/flexjs/basic /basic:Application Source Code Right now, Application doesn¹t contain any UI, it takes another MXML file as the initialView property and a model and a controller. You can reference the example in FlexJSSDKTest. Building and Running/Debugging As you edit the code, the regular Flex compiler is compiling and reporting errors, but it only knows how to build Flex SWFs so the output SWF probably won¹t run. So, before you debug, choose from the Run menu the new External Tool: ³FlexJS (Debug Build)². This will run the Falcon compiler with the right options to generate a SWF in the bin-debug folder that overwrites the one that is there. Then you should be able to set breakpoints and debug. Once you have your app working as a SWF, try one of the FalconJS tools. It will output by default to the binjs-debug or binjs-release folder. If you run the FalconJS debug configuration, see the console output for instructions on how to copy the goog and FlexJS source folders into your binjs-debug folder. I¹m sure there¹ll be lots of issues, but feel free to comment or contribute. Remember, this is in its infancy so it will likely fall down easily and poop unexpectedly. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
[FALCON] JFlex dependency
Hi In the Falcon compiler there is a prerequisite to download JFLEX manually and add an environment variable for that. Wouldn't it be easier to automatically download this jar the same way as all the other jars in download.xml. Or is there a reason that this step needs to be done manually ... maybe a legal issue? Cyrill
Re: github mirrors aren't in sync anymore
Do you have the rights to reopen it? Maybe doesn't get any notification as long as it's closed? cyrill On Sat, Mar 2, 2013 at 3:55 AM, Alex Harui aha...@adobe.com wrote: Feel free to ping in JIRA again. And keep an eye out for my draft report to the board next week. If I have forgotten to mention it, remind me and we'll mention it in the board report. On 2/28/13 11:12 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Hi Alex It looks like the github mirrors are still not synced (except flex-sdk) . A few days ago I wrote a comment on the JIRA task [1]. Is there anything we/you could do? Cyrill [1] https://issues.apache.org/jira/browse/INFRA-5690 On Wed, Jan 16, 2013 at 12:12 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Currently only https://github.com/apache/flex-sdk is being in sync with github. All the other projects aren't working anymore. https://github.com/apache/flex-falcon https://github.com/apache/flex-utilities https://github.com/apache/flex-whiteboard https://github.com/apache/flex-tlf https://github.com/apache/flex-site I added a comment to https://issues.apache.org/jira/browse/INFRA-5690 but I can't reopen the task. Alex do you have the rights to reopen it? Cyrill -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [FALCON] JFlex dependency
It is a license issue. Sent via the PANTECH Discover, an ATT 4G LTE smartphone. Cyrill Zadra cyrill.za...@gmail.com wrote: Hi In the Falcon compiler there is a prerequisite to download JFLEX manually and add an environment variable for that. Wouldn't it be easier to automatically download this jar the same way as all the other jars in download.xml. Or is there a reason that this step needs to be done manually ... maybe a legal issue? Cyrill
Re: github mirrors aren't in sync anymore
On 3/1/13 4:08 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Do you have the rights to reopen it? Maybe doesn't get any notification as long as it's closed? I don't have the power to reopen. When was the last time you pinged them on this issue? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: AddAirToSDK and setFlashPlayerVersion scripts
Hi, I just noticed that setFlashPlayerVersion script goes back to 10.2, but AddAIRtoSDK doesn’t go back as far. Anybody know why? Because I only made it compatible for AIR 3.1+ should be easy enough to change. Do you want me to do it? Justin
Re: AddAirToSDK and setFlashPlayerVersion scripts
Yeah, I want to try to hit the last AIR for Linux. If you make the changes I'll give it a try (although I don't have Linux to test with, I want to see what FB will do with it). On 3/1/13 9:12 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, I just noticed that setFlashPlayerVersion script goes back to 10.2, but AddAIRtoSDK doesn¹t go back as far. Anybody know why? Because I only made it compatible for AIR 3.1+ should be easy enough to change. Do you want me to do it? Justin -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: AddAirToSDK and setFlashPlayerVersion scripts
On Fri, Mar 1, 2013 at 9:15 PM, Alex Harui aha...@adobe.com wrote: Yeah, I want to try to hit the last AIR for Linux. If you make the changes I'll give it a try (although I don't have Linux to test with, I want to see what FB will do with it). You could fire up a (free) Linux VM on Amazon AWS if you want a box to test. Om On 3/1/13 9:12 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, I just noticed that setFlashPlayerVersion script goes back to 10.2, but AddAIRtoSDK doesn¹t go back as far. Anybody know why? Because I only made it compatible for AIR 3.1+ should be easy enough to change. Do you want me to do it? Justin -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
