We are working on a project where we have multiple modules- all these share a common set of functions like rounding, string parsing etc.
Currently, we have added these functions into the parent container (which calls these modules) and use them in the respective modules. Likewise, if we have to share variables between modules, we add them to the parent module- so it becomes shareable across.
Is this the right approach- both from a performance and structure perspective?
You should create a runtime shared library project (RSL) and have some classes with static functions. That is how we do it. This can be shared between all of the modules, also you can then use that RSL for any future projects as well.
Maybe you are looking about Singletons.
Check my answer here please : use actionscript file in flex library
Related
I am new to ASP.Net MVC. I have a couple of controllers and models. They all use a set of static functions and constants which I call common code.
In my MVC project I have folders for Controller, models and view etc,
Where is all the common code supposed to be put ?
Is is OK to create a Common folder and create new class for my static functions and same for global constants ?
If you reuse this common code often across solutions, you might want to consider compiling it into its own class library and simply referencing the assembly.
Another thing you'll want to consider is the nature of the common functions. Are they truly just helper functions (like manipulating strings and stuff like that) or do they make more sense mixed into your business layers?
Basic rule is to keep it organized be consistent. There's no right or wrong way to structure your application...only hundreds of thousands of opinions.
Exactly you can create Helper folder when you set your extension methods or another common utility.
But for constants suggest you to create Ressource File
Remarks : All text , warning or info messages, put theses elements in ressource and don't write in code, for gloabalization need(It's my case on project)
Maybe there's something obvious that I'm missing or maybe not. Suppose I have a class that is just a representation with getters/setters and no logic. I'm going to use these structures for serialization/deserialization mostly. Suppose I use that object in many, many applications. Suppose I have dozens of these objects. What's my best approach to sharing these objects?
I understand that I can compile an object into a DLL and reference that DLL. But if I have dozens of these objects, do I compile them all separately so I can use just what I need or do I make and maintain a monster DLL with all of these objects in it. Both of those approaches seem bad. I don't want to create a class library for every single class (that's stupid) and throwing them into a giant package just seems like a bad idea.
Am I missing something simple? Doesn't java have a convention where one can create jar files of one to many classes? Does .Net do something like that?
You need a happy middle ground.
You should be grouping related objects into individual namespaces.
You can then compile each namespace into a seperate DLL. That way, whoever is using the libraries only needs to reference a single DLL per group of functionality.
You can have a master assembly containing all objects. Then also create separate assemblies for the different applications where you only add the ones you use as links.
You would then use Project->Add Existing Item, and then on the Add-button click the down-arrow and select "Add As Link" when you add the classes you want.
Having seen several different ways of setting up larger projects in flex, I'm wondering what your opinions are of how to organize projects that are going to require 2 or more different applications. For example a public and private site within the project.
The two main ways that I know of would be first, creating one flex project, and then adding different mxml application files. Both applications would be able to share code.
The other way (which I currently like, but have no way of justifying), would be to create a different flex project for each application, and any code that needs to be shared could be part of a shared flex library. I guess something about the separation of the applications I like more, especially since I'm either working on one or the other at a time.
What are your opinions, and do you have any reasons for doing it one way or the other?
I recommend the library approach. That said, you can still use multiple applications in one workspace (and I do), but it's handy to keep the "one project, one application" rule. My workspace might have 5 projects, each of which has an MXML application, and 4 library projects, which have none.
I have used common library approach, it gives more decoupled code. Common library can also be used by some other projects later. Two applications in one project are mix and poor organisation for me.
One project with per application. I agree with everyone else. I would add that common libs are a good way to go as well. If you are working for a client that is having you build 2 or 10 applications then you will for sure want to reuse features as you are likely going to do this to save time and also so that the applications share common themes and functionality.
I find that a good rule to follow is if you tend to use a feature more than two or three times then it is a good candidate to be placed in a common lib.
I usually structure my projects by features. and example would be something like ... take an MP3 player application.
I would have the following packages
com.yourdomain.applicationname.mp3controls
com.yourdomain.applicationname.albumlistings
each feature would contain commands, model, view packages to start.
then maybe you find that you really like the mp3controls feature and you can use it on some other apps like say a video player application. The mp3controls could then be put into a common lib and then maybe renamed to something like "mediacontrols" or something.
(apologies ahead of time, I only really know Flash; my Flex experience is basically nil. There may be a very standard and obvious workflow solution that Flex people know about)
I have a number of UI elements that are graphically quite complex (they're not components, they're just Sprites). Since it takes a long time to compile them, I've been trying to move them into an external .swc. However, I want to associate some code with these classes, but I don't want to have to recompile the graphical assets every time I make a code change.
At the moment I have it set up like this: UI elements are created in a separate FLA and exported to a SWC. In my primary FLA, I have actionscript classes that extend each of the graphical assets in the SWC. For example:
external.swc:
(some symbol defined in the Library and exported for actionscript in frame 1)
class: com.foo.WidgetGraphic
base: flash.display.Sprite
main.fla:
Widget.as:
package com.foo {
public class Widget extends WidgetGraphic {
...
}
}
This works, but is time-consuming and prone to error. I'd rather be able to avoid having to inherit from each graphical asset, and just define them directly. Is there a better way to do what I'm trying to accomplish?
Note: the main concern here is compile time. I don't have any movies or audio or fonts, just a lot of vector art assets that appear to be slowing down my compilation time significantly. When I'm debugging I'm only making code changes, and would rather not have to keep recompiling the art...
Try to compile your project with Flex SDK. Export your graphics, fonts, music etc. to swc, and compile your project with Flex SDK. If you're on Windows, check out FlashDevelop, it will helps you to start building projects with Flex SDK.
I have a program consisting of multiple SWF's. An AS2-SWF loads a bunch of AS1-SWFs.
It's a crappy program. I'd like to specify the GUI in MXML and perhaps refactor some code to AS3. However, converting all of the 300+ symbols to AS3 or whatever is undoable.
What are my options in converting to AS3/Flex/MXML? The app is very simple, only also quite large. It consists only of buttons, backgrounds and attention-texts. All the button texts are in XML files.
I want to turn this into pretty code ASAP but also controlled so the code becomes:
easily updateable/maintainable,
readable
learnable (so I can have the updating done by someone that can only script AS3 or even MXML).
Of course doing this is on my own initiative, if it'll take more than a week, I won't be able to find the time.
Regards, Jurgen
This might help:
http://flexman.info/2009/03/29/as3converter-an-ant-task-small-collection-of-as3/
It's mainly for AS2 code, so FLA editing is out of the question. But you should certainly look into JSFL.
There are some pretty good scripts out there already dealing with something like this:
http://bumpslide.com/blog/2009/03/07/jsfl-class-generator/
What this command does is that it
looks through your library and finds
all library items that have a custom
linkage class name. If the class
extends flash.display.MovieClip (or if
the base class is blank), it checks to
see if a classfile exists, and if not,
it creates it for you. When it does
this, the script looks at all the
items on the timeline and adds
relevant properties to your class. If
these clips are instances of other
components, they will be typed as
such, and relevant import statements
will automatically be added to your
class. If your component is set to
extend some other class (for instance,
com.bumpslide.ui.Button), no class
will be generated. Class files will be
written to the correct package
location inside the first custom class
path defined in your publish settings.
Jurgen, I feel for you... it sounds like a lot of work.
What sorts of issues do you have? are all the swfs treatable as different classes? is there much overlap in the logic or does each object have a specific role?
I think having so many different SWFs may possibly lead to scoping problems> which swf talks to which. you may be able to set up something with as3 that uses the existing parts and then try making a facade over the existing code > use the existing logic in the swfs and do the visual part through mxml. other than that, all I can advise is a rebuild. you might find yourself in need of a swf decompiler too if you are missing some of the original fla's