I have just started looking into using Modules in Flex and would like to know how you all go about developing them. I understand how to use them (load, unload, application domains, shared classes, etc.), but I'm wondering what a good workflow is in creating them and using them in multiple applications.
If I were building reusable application components (text editor, image cropper, compass, whatever), and I wanted to reuse them in many different applications, it seems like I would:
1) Create an Application specifically for one of those modules
2) Create a Module inside that Application
3) Develop the Module by itself, make it work right
4) Link shared libraries to it somehow (like library projects I would use between all of the modules)
5) ... then I'm unclear what's next. I now have lets say 10 Module/Applications, and I want to start mashing them together into usable applications. What's the best way to do this? I would like to not have to copy-paste code and swfs, using something like git submodules if an equivalent is possible.
Thanks so much
I think you're looking for SWC files.
Related
I am trying to think about a web application development framework for our product development. I want to build an ASP.NET application which has many sub-modules in it. My requirements are like:
The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
Each Module should have their own DLLs.
One project should be for the external container of the application (like the framework) and this project should bring all other modules (of type web application) in the solution to the external container. (Some thing like we have Frames in HTML). So we will publish the external container web application only at the end of the day and all other web application projects will be accessed via that.
I would like to have separate DLL for each module so I don't need to fear about the application breaking when I am deploying my single DLL which controls the entire suite.
I am not sure whether my thoughts are in the right direction. The end result I am looking for is a well-maintained, organized, and modular web application suite.
It is ASP.NET web forms, not MVC. I will use VS2010 for development.
What are the best approaches to do this?
Edit:
The term external container means it acts like a master page which has links to various modules and the various modules are not always in the same project. They can be separate project under the same solution. And I am under the impression that, by the end of the day, I will publish that project only and it will bring the various modules to it.
I actually think the best approach would be one that does not over-architect. I'm concerned that it seems you are producing an overall architecture without sufficient reason.
Are these all new modules? Then just start writing the first one. Use best practices that apply to single modules.
Then write the second one. You'll find you want to use things you already wrote in the first module. Great. That's what refactoring is for. Refactor these things out into one or more "library" projects, re-run all your unit tests, then proceed with the second module.
Repeat until all modules are done.
At the end of this process, if you needed the kind of architecture you've outlined, then you'll have it. If you needed less, then you'll have less, and you will not have spent time creating an architecture which is not tied to real-world requirements.
I'm not going to say this is a "best approach" but I would recommend looking over Dot Net Nuke (DNN) to get some ideas. This started as the old "I Buy Spy" starter web project that Microsoft distributed to show ASP.NET projects, and it took off from there.
edit:
1.The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
You can do this with DNN. They're also called "modules" in DNN and Drupal.
2.Each Module should have their own DLL's.
Yes, this is a good idea. And you'll see this sort of thing in several content management systems like DNN and Drupal. This way not all implementations of the same website need to have all modules installed.
We have a significant website that is used to host a "service as a solution" application that we charge for (if you aren't an actuary or accountant you won't have heard of it). The lead developer for the past couple years used an earlier version of DotNetNuke as a model for how to refactor the parts of the application that he was allowed to change.
Like others have suggested DNN would probably work for what you're trying to do. If you want to completely roll your own naturally I would turn to some sort of combination of a container "Framework" and a bunch of user controls (.ascx). The container could be as simple as a master page with a menu. Depending on how flexible you want your design you can prefabricate many different pages, each hosting a different control (separate dll as you wish). If you want it to be a little more dynamic you can have one content page that will dynamically load at runtime the desired user control into it. Again this is just a general approach, probably a 30000 feet view into how DNN is implemented anyway.
Name the main project after your company/product and keep it short and simple. You will probably need one or two library projects to support it - these will contain everyday, common logic for such things as error reporting, Web utility methods, etc.
Next, pick one of your intended sub-projects (I don't like the term module in this particular context) and add that to your solution. Whether you are reusing an existing project, or preferably starting from scratch, you will eventually have any common logic in this project moved out to your libraries.
Rinse and repeat. Perhaps take a look at something similar like the Sueetie project which includes several sub-projects like CMS, Blog, Calendar, Forum, etc.
The following article is marked as "outdated" on MSDN but I still think you should take a look at it:
Structuring Solutions and Projects
Also, something similar from the Patterns and Practices Group:
Structuring Projects and Solutions in Team Foundation Source Control
I'm working on a pretty big application for Flex/Air. We are using GraniteDS and Tide to interact with the model from our Java EE server.
I've been reading about modularization and Modules in Flex. The application has already been built, and I'm figuring a way out to re-design some classes and parts. From what I've read so far, I understand a Module is a different swf which can be dynamically load. Most of the tutorials/documentation are oriented to Flash "programmers" who are using Flex or Air instead of real developers, so that makes online resources harder to get.
What I can't understand - yet - is how to encapsulate ActionScript classes or MXML views under this module.
I've separated some of the code into libraries. For example, the generated code from Granite is in a "server" library. But I would like to separate parts of the logic with its Moderators, Controllers and Views. Are modules the way to go? Is there a "modules for dummies" or "head first Flex Modules for programmers" like tutorial in order to get a better perspective in order to build my architecture? When to choose libraries and when to choose modules?
I'm using Flex 3.5, and a migration to Flex 4 is way far into the future, so no Flex 4 answers please, thanks!
Modules are the answer for encapsulating UI into different sections that do not depend on each other. Think of them like applications inside of applications.
If you want to encapsulate "code", meaning non-ui actionscript, then you really just want classes and packages of classes. You could also package that code into a swc, which is just a compiled version of that code that you can include in multiple projects (I think this is what you meant by libraries).
You wouldn't want to create a module just to contain non-ui code. You wouldn't want to use modules for separating out the model/view/controller in your application.
If you have part of your application, that for the most part runs completely on its own, with no real dependencies on the rest of the application except for maybe a little bit of information passed in, then it makes sense for modules.
Where we use modules mostly is for an application that has different sections to it where you are only working in one section at a time. There is no need for the other sections to be taking up resources, so we have the different sections in modules and load/unload them as necessary.
Does that help?
Edit in reply to the comment below:
By libraries I meant Flex Library
Projects, where you encapsulate
classses and use the swc. Can you have
these libraries inside a Flex Project?
(I use a separate Library Project for
each new library).
Yes, you can use these swc's (Libraries of code) inside of your flex projects. Just drop the swc in the lib directory in your flex/flash builder project and the code is automatically added to your classpath. Just make sure that everything that the code inside a single swc needs is inside that swc. Don't make a swc rely on another swc to function.
Do you have one solution with the web application project, class libraries, database project and tests? Or, do you segment it into multiple solutions? Why?
I'm asking because we're trying to streamline this scenario for Visual Studio 2010 and I'd like to get input from the community on how you'd prefer to work.
I tend (but not always) to have one solution per job, but I import existings projects from other solutions, such as my WebControlLibrary where I keep common user controls and classes, etc.
My actual solution for the job I then tend to break down into the Web Application, Business Logic Layer, Data Access Layer and Entity Layer, i.e.:
Solution
...MyCompany.WebControlLibrary
...Project
...Project.BusinessLogic
...Project.DataAccess
...Project.Entities
...Project.Scripts
...Project.Testing
...Project.Deployment
If a project requires something such as a mobile device, I'll always put that in a new solution, but it may perhaps share some projects of the current solution, i.e.
MobileSolution
...MobileProject
...Project.Entities
...MobileProject.BusinessLogic
The more 'stuff' you have combined, the slower Visual Studios becomes at building. You can obviously stop certain projects building by default, but that's when you have to start creating your own build configurations. If you are going to be creating large applications, I'd suggest breaking down into multiple solutions. I find it much easier to flick between solutions that to keep changing build configurations.
Another option is that when you build your projects you can reference their DLLs. I prefer to import said projects into my solution as you never have to worry about referencing the creating build configuration i.e. selecting the DLL from the Debug or Release folder.
Stand alone libraries can be their own solutions. References for those libraries can be made into the project that you're working with. Related items like the web application, the test setups, and specific libraries such as data access or business rules can be setup as projects within one solution. It really all comes down to how much you want to break things out for resuability.
This depends a little on the job the project performs.
For ease of use it's simple to have a solution that just contains all the projects required. If it's a large solution this can hamper you later on when the IDE starts to get slow and build times rocket through the roof.
Let's say one of the projects is a library used by your company to take card payments and interface with 3d secure. You present you're own GUI page to take the details etc.
If you had numerous sites that all take card payments you would greatly benefit by having this project in a separate solution and referencing the compiled dll. Any changes you require you would need to open up the solution, make the change, build it, go to the solution you're working in and test it. Sounds like a pita and you find it's just simpler to have it all in one big solution. But then if you have this library in every solution and make a generic change to it you need to repeat that change through out.
So you just need to make a decision on wether you're developing a separate project in the same solution or something that might be used elsewhere. If you needed more functionality than the library provides you could implement a partial class in your project and extend the library in that way. Or perhaps a wrapper class will suffice. But then you know you're not affecting the other sites that use this library and you are keeping your solution smaller and more manageable with a smaller memory print during development.
I am the CTO and sole developer for my company. I'm getting ready to hire our first developer and possibly a second within the next 6-12 months. I'm embarrassed to say that I've never used source code control as part of my workflow. I guess being a 1-member development team has allowed me to be a bit lazy. It's not that I haven't wanted to, I just have a bit of a mental block about how to get started with it.
We have 5 web applications that I build and maintain. We use ASP.NET, and each web app references a single .NET Class Library (DLL) that has been copied into the "bin" folder for each app. I've been developing with a single Visual Studio "solution" that includes the class library and all of the web apps. A bit bloated, I'm sure, but this method has made it easy for me to minimize mistakes by enabling me to do global find and replace operations on all of my apps (and the class library) at the same time.
I realize that implementing source code control is a big change to my workflow by itself, but also introducing another developer into my process has me a bit overwhelmed. I'm looking for some assistance on how to develop a workflow that will enable my small team to move quickly without cumbersome processes. I'd like to avoid discussions about which SCC system to choose (we're going to use Mercurial). I'm more interested in discussing the structure and workflow aspects of this.
Here are the questions I need help with:
Should I split up each app into a separate "project" or keep them all together so we can continue to benefit from global find-and-replace operations when necessary. I'm worried about splitting them up because of the class library situation (see #2).
If splitting up the apps into separate projects, I'm not sure how to proceed with the class library that each project needs a copy of. For example, let's say that the changes to one of the apps (call it "project 1") requires a change to the class library... if the class library is in a separate project (call it "project 2"), it seems "messy" to me that project 1 would be dependent on the latest changes in project 2 in order to work properly. Or, do you simply make your changes to project 2 (the class library), check them in, and then copy the newly compiled dll into project 1 (but shouldn't the new copy of the dll being copied into project 1 be recorded in the SCC somehow). I'm getting confused even as I write this...
Thanks in advance for your help.
First, congratulations on deciding to finally use source control. I know changing your habits can be frustrating but in the long run I'm sure you'll see the benefits.
There's nothing wrong with a solution that has multiple projects in it. I generally keep mine to about 10 but that's simply to improve load times. If keeping them together works better for you, leave it that way. Usage of source control won't have any affect on this.
As far as the class library, I think what you need to do is change the way you go about making changes to the library project rather than how you use the projects that reference it. Implement unit testing on the library project to enforce backward compatibility so you know that dropping the latest version of the library won't break your app. You'll likely find this won't be true a few times but as you develop more unit tests to handle edge cases this will happen less and less.
You can have multiple projects in a single Visual Studio solution. What I've done in the past is to have both the ASP.NET project and the class library project in the same solution. You can have your ASP.NET project reference the class library project (Add Reference and then go to the Projects tab to show other projects in the same solution). That way, whenever you change the class library, the ASP.NET application will be build using the latest version of the class library. You can setup multiple solutions - one for each ASP.NET application with each solution including the class libary project.
You could also setup one large solution with all of your ASP.NET projects as well as your class library but that may get a bit hard to work with, especially with multiple developers working on the different ASP.NET pages.
I am trying to create a large flex project. This Project consists of a CORE application, and other sub-applications.
The CORE application should contain information that will be shared by all other projects (e.g., link to database, data manager which loads data from the database, application information like height width colors fonts... etc.).
The sub-applications each has a certain task. Each sub-application is a large project by itself so I don't think its a good idea to put all code inside one HUGE project.
The CORE project should run the main application, and through a navigation menu, I should be able to click and run other sub-applications.
Is there a way to created the CORE application to reference those sub-applications so that I can run them inside of the CORE. At the same time, those sub-applications should reference the CORE applications to get the NetConnection to the database and other important information that they might share?
What is the best way to structure this project?
Thanks,
There's two factors to consider.
Where does the code live
Where does the compiled output of that code live.
It likely is a good idea to have all of the source code live in a single code tree. It's way easier to maintain like that. You could put each sub-application in a separate AS3 package.
It's also likely a good idea to separate the compiled output of that code. Make your core application the main flex application, and then make each sub-application a Flex module. The core app can load modules and manipulate them like any other AS3 based class. A great thing about this, is during debug time you can choose to only build the limited set of modules that you care about at the time.
I would highly suggest building your releases through some kind of automated ANT build script and not through Flex Builder.
We have one project that exceeds 150k lines of code that is managed exactly like this. That's not huge in terms of software-engineering, but it's pretty big in the Flex world.
Your best bet would be to put the CORE stuff you're suggesting into a library project. Keep the front end of the application in a Flex Application Project, but all of the data and methods that need to be shared would be easily available to the main application and all of the other modules or applications.
Then in the project settings for your main app and the other applications, you can link to the library project.
If you're planning on using a framework you can also look into the PureMVC Multicore library. It's a bit more complicated than the solution I provided above, but is built specifically to allow the sharing of data and notifications between separate applications.
It sounds like you want to use Flex modules to keep your sub-applications self-contained but still able to interact with the core application.
http://livedocs.adobe.com/flex/3/html/help.html?content=modular_2.html
This will allow you to keep your core application SWF fairly small and load the subapplications on demand.
Typically modules are stored in the same project as the main application but each app / module is compiled into a separate SWF either by Flex Builder or an automated build tool such as Ant or Maven.