I have modifyed XMLEncoder class from Flex SDK (XMLEncoder.as)
After it I run my project but I don't see any changes...
What should I do to realy modify project's behaviour?
Thanks!!!
It's not usually recommended but what you are trying to do is Monkey Patching. You can just copy your modified source file into your project and then you application's XMLEncoder will overwrite the one used in Flex (because of how the Flex linker works). This doesn't work with the framework RSLs though.
If you don't see changes, this means sources aren't used - swc is used instead. To use modified sources, recreate folder structure for the class you modified and put source there. You may see a lot of errors (most of the time because include directive), this means you need to copy files needed to satisfy dependencies.
Maybe this is not the right way, but sometimes it's the only option to fix broken Flex class, so professional Flex developer masters it sooner or later :)
Related
I have a problem with my Flex Builder Plug-in.
I'm using the Flex Builder 3 Plug-in in my Flex application (in Eclipse).
Now I want to customize the MessageResponder.as File in the Plug-In. I found the ActionScript File without any problems, but the point is, that my changes doesn't cause anything because the file is allready compiled. (That's my guess)
Now my question:
How can I compile the file after editing it? Is there a possibility at all?
Thanks for your help!!
What you want to do is called "Monkey Patching." What you need to do is create your own version of the file in the same package location, and yours will be used in preference to the one from the swc.
The MessageResponder.as class is a file in the Flex Framework. You can modify it if you want, and--in essence--create your own version of the Flex SDK. However, you will most likely have to re-buld the entire framework for this to work. You're best bet for doing this is to get the source for the most current Apache Flex SDK; modify your class and then build the framework from scratch. After that you can use the Flash Builder "multi-SDK feature" to use your modified SDK in a Flex Project.
I'm not sure if Flex Builder 3.x supports multiple SDKs.
This may be a time consuming process. The alternative is to extend the MessageResponder and add your changes. Then you'll have to make sure that your new MessageResponder class is used instead of the old MessageResponder class. This could difficult due to many private methods used in the Flex Framework.
I'm trying to compile an existing Flex3 project with the Flex4 SDK. I'm getting this error:
Warning: This compilation unit did not have a factoryClass specified in Frame metadata to load the configured runtime shared libraries. To compile without runtime shared libraries either set the -static-link-runtime-shared-libraries option to true or remove the -runtime-shared-libraries option.
The resulting file is roughly the same as my old Flex3 compiled .swf file. Playing the resulting .swf file in the Flash Player also gives the following errors:
An Actionscript error ocurred: VerifyError: Error #1014: Class spark.core::SpriteVisualElement could not be found
If I set the compiler attribute static-link-runtime-shared-libraries to true, then the error disappears and all is well. However, the size of the resulting .SWF is a couple of 100K's bigger. And that's not what I want.
I don't fully understand the concept of runtime shared libraries, but it seems that with the option to statically link them set to true, the libraries are included in the .swf. However, I like to exclude them from the .swf and only load the needed library at runtime, as my project seemed to do with Flex3 (I didn't know that by the way).
If I understand correctly, playerglobal.swc should hold all the necessary code for the external libraries that my .swf has to load. Do Flex4 compiled files need more libraries? Should I do something with the factoryClass in the Frame metadata tag?
I think my question boils down to this: How do I compile a Flex4 .swf that is the same size as my previous Flex3 compiled .swf?
You have to add [Frame(factoryClass="path.to.your.preloader")] to the main class (the one you set in the compiler options).
Flex3 did not use rsls by default but you could enable them. Flex4 rsls are enabled by default, see: http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7add.html
The concept of runtime shared libraries is: splitting of a part of your application that is (re)used by other apps as well, thereby only requiring the user to download it once. This won't save anything on the first download but will save on later downloads. You could possibly make your own rsl, but it's mostly the ones provided by adobe that are meant to make the difference: Since 'everybody' will use them there will be a bit chance the library you need is already present on the user's system, thereby speeding up the download-time of your app.
playerglobal.swc never contained any flex framework classes, most of them are in flex.swc and framework.swc (a standard flex 3 project also includes rpc.swc and utilities.swc - I didn't check but these probably contain some flex parts as well)
Looks like you might have project migration problems. You might want to read up on the process on:
http://www.adobe.com/devnet/flex/articles/flexbuilder3_to_flashbuilder4.html
It's a really good article with overview of different possibilities for migration, depending on the amount of Flex4 stuff you want to use.
I'm using the Subversive plugin for Eclipse/Flex and I can commit the files correctly, but I have to rebuild Data/Services each time and reconfigure return types for each, etc. Does Subversion not provide a way to check/in out Data/Services or must these be rebuilt each time?
If I understand your comment to your question correctly, then it seems to me that it's not a problem of Subversion/Subversive, but a problem of Flash Builder's code generator which is generating/overriding your customized return types.
Maybe there are some Flex project settings files that are not committed. That would explain why you need to rebuild Data/Services each time you open the project.
By the way, if you do commit the project settings files, make sure all the paths are relative paths, so that the project settings can be shared among several developers.
You might find value in this Adobe devnet article about Flex project settings
My partner and I had different local names for the project we were working on so we had conflicts with the settings file.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.
Setting up Flex project for group development can be a bit tricky. There are lots of little local settings that might need to be tweaked in order to have a project that can be easily checked out.
I've had limited success using the built-in import/export flex project utilities. I seem to wind up editing by hand a lot and I think I might be missing something.
UPDATE
I neglected to mention originally that my goal is to make it possible to checkout a project from subversion and get up and running with as little fuss as possible. The biggest problems that I have run into all revolve around managing the "dot" files and how to make them flexible enough to deal with different developer environments.
For example, even with just me, I would like to have this ability: at work, I use a Vista machine and at home I use a Mac. There are certainly differences in the way certain paths are described, but they really are quite similar. On Vista, the flex root is c:/ColdFusion8/wwwroot, on OS X, it is /Applications/ColdFusion8. I have been able to set up a linked resource path variable for both CF_FLEX_SERVER and WEBSERVER that I then reference using the ${WEBSERVER}/myProject syntax.
So far, it seems to work pretty well, but I find there are a few places that it still has issues. Specifically, in the .project file you find something like:
<linkedResources>
<link>
<name>bin-debug</name>
<type>2</type>
<location>c:/inetpub/wwwroot/myProject-debug</location>
</link>
</linkedResources>
Unfortunately, if I try to change the location entity to ${WEBSERVER}/wwwroot/myProject-debug, flex throws a compiler error. That's a shame, because pretty much everything else works.
I have worked through this problem before and generally set my projects up as such:
Application/trunk/source/ <-- workspace is here (can also be in 'trunk')
Application/trunk/source/Application <-- Application here
I DO keep my project (.actionScriptProperties, .flexProperties, .project, .settings) in SVN, but NOT my workspace (.metadata) because it's too big.
I find that importing projects via Import -> Flex Project enforces alot of restrictions. For example, if your workspace was in the 'trunk' directory above then importing as a Flex Project will cause the project to be copies into trunk/Application or simply complain about the location.
The better way to go about it is to create the workspace and then Import -> [General] Existing Projects into Workspace. The only difference is that you will have to manually add the Flex Development perspective.
Edit: I'd also recommend setting your compiler options to "Use default SDK" and then setting the appropriate SDK as default. This will prevent commit-tennis when each developer names his SDK differently.
Since Flex Builder is written on top of Eclipse, it can integrate with Subclipse. This allows you to pretty easily tag files as 'SVN ignore' to avoid project-specific settings. I've used this to add my Flex projects to an existing SVN repository, which I've checked out to multiple sites. I have noticed a few issues here and there (some checkins get errors, but they're relatively rare), but it generally works.