Since my application is getting bigger, I decided to fragment my project into several modules, but the documentation from Swiz on Modules is very poor (http://swizframework.jira.com/wiki/display/SWIZ/Module+Support). I tried out the Swiz Examples (http://www.briankotek.com/blog/index.cfm/2010/8/16/Swiz-Example-Application-Demonstrating-Module-Support) but I couldn't inject any data into my module or even catch an event. The module is loaded properly however.
Ideally I will end up having multiple Flex-Projects, each containing one module and each .swf file is deployed into the application deploy folder.
However if you aren't famililiar with a structure like that, but instead you know how to inject data/event mediating into a module inside the same Flex project, I'd also be happy to read your advice/knowledge.
Any helpful answers welcome.
I don't know Swiz, but I have had great results using SwiftSuspenders - you can have very complex modular structures completely decoupled and loaded separately.
What might be an issue you want to check first, though, is which ApplicationDomain you load your module into: If you are going to use a common class loader, inject data and catch events properly, it should be loaded into currentDomain.
In any case - SwiftSuspenders is worth looking at...
Related
I would like to create a web component which is an auto-complete combobox, but since there is no such thing natively, is it considered bad practise to make a web component which also depends on a third party library or libraries?
I've only had some minor involvement with Polymer a year ago, and now that v1 of the spec is out, I'm looking at them again. It seems to me that most people develop web components that are 100% plain javascript with no external dependencies, but given the state of UI controls available, that would make for some very plain-Jane components.
There are two ways to handle this. OK. Maybe more, but I will show two.
1) Rely on ES6 imports and then your components just use `import something from './somefile.js". Yes, you will have to provide both the component and the library or reference a library that supports ES6 imports. But this prevents doubling up code.
2) Package your components with their dependencies. Some people use things like Webpack, but I felt that was going too far so I created component-build-tools to allow you to write your components using import but then combining the components parts into a single file. This allows the components to be loaded in any browser even if they don't support import. The limitation here is that you need to load your combined component files in the correct order. For most projects this isn't difficult, but it is something you need to manage.
I just want to know if anyone stores their helper classes or methods in a separate assembly and why...just for clean management of them? I've seen so many posts about using a helper folder inside your MVC project and that brings me back to the messy old days in ASP.NET where people were using an App_code folder instead of cleanly separating things out physically like this into its own project.
And likewise nobody doing real architecture is going to put models in some folder in your MVC web assembly. They would go in MyApp.DataLayer assembly or MyApp.Models or something like this.
Yes, but for reasons, which are common to other assemblies as well
Becomes easy to plug into any other project.(might need some editions).
Reusable
Easy to improve
Easy to refractor
As not part of a project, but project
itself, it is easy to document and easy for developers to understand
Clears out some of the mess
But for all that above, your assembly, when ready, should be a "job well done", other wise, it is better to keep the helper classes to where they belong.
We have some helpers in a separate project and some in the web project. I think you'll find that some of your helpers need to use abstractions that you've defined in your web project itself. And that will often force you to put those helpers into the web project, because it's not likely desirable to have some other project that has a reference to the web project. I don't consider it the same as using App_Code. These are files that are compiled at compile time inside your IDE, with no special "magic" that gets applied to App_Code.
I use projects to separate out the different layers in my web or form apps. It allows me to respect the business rules better. Also I find it easier to track down where I need to go if I want to make a change.
But I have seen people use folders that label the layers in the solution but I think that is a little messy.
Yes, because they are part of the Business Layer. Two big payoffs:
Reusability
Testability
Keep in mind that your utility functions and helper classes are likely to be some of the most heavily used components of your entire system. Without full BICEP testing, you run a truly unacceptable risk.
Most helpers that I create are usually layer specific so I tend to keep them with the assembly the base assembly that needs them. I don't see a reason to add in another project to store a large number of specific helper classes.
Flex newbie question: can MXML be generated on the fly, like HTML is generated by a server?
If yes, is it ok to do so or am I missing an important Flex architectural principle.
Sort of... but it still needs to be compiled. MXML is not rendered directly, it is first compiled into ActionScript 3.0, and then into a typical SWF... so, you cannot serve your users with MXML. However, like almost all programmming languages, you can use automatic code generation to ease development tasks.
There is IIS/Apache component given by adobe that can generate your mxml -> html+swf using on the fly compilation, and it also caches the last compiled file.
However its not recommended for bigger projects as it has certain problems that you cant make libraries of your code and organize code accordingly. Namespace usage is very limited.
MXML is just a way of describing user interface layout and scripts. This information is then "compiled" into ActionScript, then converted to SWF format for use in the Flash player.
So, yes, you can generate MXML on the fly, in that you can create a text file that contains valid MXML syntax, then use mxmlc to compile it, but there's no way (that I'm aware of) to create MXML and "add" it to your current movie such that the information appears as it would were it compiled.
It is not officially supported but there is a few similar projects doing stuff similar to this.
as3Query let you create things with xml.
Using createComponentFromDescriptor() maybe can get what you want.
Should be more as I remember, but can't find it out at this moment... Searching for "MXML runtime dynamic compilation" or something like that should be helpful...
I have been in the process of creating a "lite" version of an existing Flex application, and thereby porting many of the classes that are used by both into a library project. As such, I want to easily find all of the "orphan" classes in the original project - those classes that are no longer referenced/used by the project. Is there an Eclipse plug-in, or some other easy way to find these in Flex Builder 3?
Thanks.
MXML Compiler (mxmlc) compiler has "link-report" which will generate all the classes you are using in your original application. From there, with a bit of grep / awk / xsl magic, you should be able to diff with the classes you have in your library project.
Here's what I do sometimes, lets say we've been refactoring, and a class becomes obsolete, I simply move the suspecting file from Flex Builder to the desktop, rebuild the project and see if it the compiler spits out any Errors.
If it doesn't complain, I know I can safely delete it.
If your class is depended on, the compiler will throw some errors in the Problems panel in Flex Builder and give you a fairly clear hint of what's missing.
This won't be fun however if you have thousands of classes, as you have to traverse them one by one.
I would suggest, always keep copies of the old ones in Subversion, just in case you had something re-usable in there, and later you want the deleted file restored.
Can anyone tell me what is and isn't recommended when it comes to mixing in classes from the mx package in an Actionscript only project?
Specifically I want to use AsyncToken, IResponder and HTTPService classes in the mx package in an Actionscript project.
I guess the mixing problem comes when you need to use mx.* classes, but you're on a pure as3 project.
If it's as3, you can still make an actionscript flex project, using the framework.
When it comes to Flash, you can either export a SWC with your actionscript exported (linkage setup) and add that to your flex project.
Again, if your project weighs more on the flex framework than on flash, you might find the Component Kit handy.
But if it's a Flash IDE more oriented project ( as in simple data coming in, mostly design work, not much nerdy stuff to it ), using a few mx.* classes, just for the HTTP service, doesn't make much sense. The problem comes with the fact that flex is a framework, therefore things rely on each other to work well, like a brick tower...brick upon brick, upon brick...
and since it's code you're working with, things are somewhat dynamic, but still not much cement...so you might end up wasting more time finding all the flex dependencies and getting them to work outside the medium they were made for, rather then building some of the functionality by hand.
If you need an as3 only implementation for WebService, Carlo Alducente has one.
HTH
The non-visual mx classes should work fine in a AS3 only project. But they have a lot of dependencies so you SWF will be bloated.