I'm working on a project in Flash CS4/AS3 and I have a document class set up but I am wondering about using that, as opposed to frame-based scripting. Most of what I have seen so far deals with how to create them, but doesn't offer much about why or when to use them.
I know I can also pull in other classes beyond the document class but, again, why and when?
Could I get some input from you fine people out there on usage/best practice, etc?
Thanks
If this is just a simple demo or a movie, you can use the time line.
But if you're going to make a program, with classes, you should have a document class.
A document class is the main class of your programs. it's actually your initializer of all the program's processes and components, and it's simply more proper and similar to other programming languages.
Plus, it's in a different file, and it is easier to edit it this way.
Also, your doc-class will be a class and not just code in the air.. it also has auto-complete in CS5.
Related
So, I was just wondering if anyone could give me a succinct answer on why exactly it's better to code mostly in an AS3 file as opposed to most on the timeline?
I've heard a lot of people answer questions with a cop-out "don't put so much code in your timeline". I've tried both ways and found some pros and cons on each, but it just seems silly to me for so many people to parrot the general good coding practice techniques.
Another thing about that is that a lot of times I'll be searching for help on coding, and people will give such complicated responses, and half the time I'll use little snippets of code as well as incorporate a small portion into my projects. Also, the AS3 API site also gives waaaay overcomplicated coding examples. Why do people do this? I could figure out some of my issues much more quickly if people just simplified the code examples.
Three good reasons not to put it on the timeline:
Your code will be stuck inside a binary file, not allowing you to use version control nor review changes to it.
You're going to hide code behind menus, making it hard to review in an instance. When it's all in one place you can easily refactor it, and change it.
By putting code on your timeline, you're making your code be dependent on the Animate compiler. (Animate is going to take your code and inject it into your document class using the undocumented function addFrameScript to make things work). The code isn't easy to migrate in this form, if you ever feel the need to re-code in another language.
Please use an IDE when coding. It will help prevent mistakes and even suggest ways to make your code simpler. (To name a few IDEs: FlashDevelop, VSCode, IntelliJ Idea Ultimate (paid).)
To clear up any confusion, writing code in an AS3 file instead of the timeline doesn't mean make things less organized or put code where it doesn't make sense to put it.
What you should be doing is creating a new AS3 file for every MovieClip that you need scripted, then going into the Symbol Properties of your movieclip and selecting Export for ActionScript and set the class name to your AS3 file. The runtime will automatically declare the instances in your file at compile time. What you can do is actually declare them yourself in the file, to have full completion capability in your IDE.
What I like doing is first setting the movieclip to export for actionscript, publishing my project, then opening the compiled swf using Free Flash Decompiler, and copy paste the generated class into a new AS3 file. (You'll want to only copy paste the class and generated instance variables.) Then you can code in your AS3 file with all the symbols contained within the MovieClip already referenced.
First off I apologize for the slightly vague question.
I'm a self-taught coder and the more I work, the more I find myself wanting to invest in the whole process (and God knows there is room for improvement).
I'm looking for very "basic" material (books recommendation if you can!) about things like how to structure code and comments to make things clear, how to structure a project directory (How far should I divide my stuff into packages? How to properly name classes, subclasses, make it all understandable and clear?), this kind of stuff. Not the actual how make things work, but rather how to make things clean, understandable and well structured.
I've been reading a lot on design patterns, good software design and things like that, but there is this "gap" in my knowledge where I can think of a good solution to my problems, but the execution itself is pretty messy and ugly.
I've always worked solo, and chances are I will soon be working with other coders on my projects. Right now I sometimes have trouble understanding my own code, so there is no way others could dive in and help me.
I'm coding in AS 3.0, should anyone wonder.
Thank you very much :)
Depending on how new you are to coding, I'd recommend looking into why 'encapsulation' makes sense.
When I was new to object oriented programming I couldn't understand the appeal of encapsulation, but now I see how it really can help keep your code 'clean' - and I strongly suspect it's fundamental to a lot of other object oriented concepts; Design patterns, avoiding 'tight coupling', composition, code reuse and so on.
Here's the wiki info on encapsulation...
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
..but here's my summary:
I've heard the analogy of a car used: The user doesn't need to know HOW the engine works; they just need to know that, when they turn the key, the engine WORKS. Encapsulation keeps the implementation of a class's methods secret. The methods themselves are public (to be accessible outside the class) but properties are private.
By making properties private and limiting the number of public-facing methods in your classes you can have your classes operate as independently as possible. It also means you can totally change HOW a method is implemented inside a class (so long as it retains the same name and argument signature) without anyone OUTSIDE of that class needing to know anything about it. Even if that 'anyone' is YOU it can still really speed up development because you're not having to track down multiple references to public variables of the class throughout your code.
So AIM to have your classes perform one function; Think about if a method would, in fact, be better 'hidden away' in another class. Even if you have multiple objects instantiated 'inside' another, your code will be much more clean and you can be more sure about WHERE that specific piece of code you're searching for is - if a class mostly has one function, it's easier to remember what it does.
Other than that, I'd also recommend using only shallow inheritance; Having a complex hierarchy of classes and subclasses can lead to objects that need to inherit from more than one class. Look into 'composition' and interfaces too. (Interfaces are kind of AS3's solution to not having multiple inheritance).
I've been working on the web for quite a long time and I saw the "best practices" evolve. I'm now fairly convinced separating HTML (Content), Javascript (Behavior) and CSS (UI) is the best thing to do.
A few months ago, I started using knockout.js . I did choose it among other similar frameworks like backbone or angular because a chapter in an MVC training I followed was about knockout, and the concept seduced me. Then after a quick comparison on the web it didn't look as a bad choice for my needs, and for a start.
But here's my problem : when I look at my HTML code now, after a few weeks of dev on a project, there's quite a lot of knockout bindings in it, and it makes me think a lot about the old times, when we (or at least I) used to put inline javascript event handling through onclick attribute and so on.
Therefore those 2 questions, which I'm not sure are 100% suited for SO, but I can't find any better StackExchange site to ask it :
Is using knockout (or the other frameworks as they all seem to basically work with the same pattern) contrary to the "separation rule" ? Or is it an acceptable small-step-out of this rule ? or is it even perfectly acceptable because it uses the "data-" attributes ?
In the case this would be a somehow bad practice, is there any possibility to do all the binding through a separate javascript file, using for example jQuery to select the controls and apply bindings to them ? If not possible in knockout, is it with another framework ? I must admit at the time I did my selection, I diddn't think about this kind of implications...
Thank you and sorry if this should be moved to another SE site.
I had the same initial reservations as you, but I have to say that having the bindings in the html and not hidden away in a JS file seems so much better to me, as the link between presentation and functionality is now completely obvious. It massively reduces the possibility of changing some HTML and breaking functionality because you weren't aware that someone had hooked up some javascript to an element using jQuery.
Also, as you point out, the use of the data-bind attribute does, I think, mean that it does adhere to the separation rule, though if you want to stick to it rigidly then make sure all bindings are to observables, computed or functions on your view model, don't use any code (i.e. a visible binding that checks the state of two observables). I'm not sure I'd take it that far though.
I guess everyone started to learn KnockoutJS have the same concerns.
IMHO, there must be some way that connects models(JS object) with views(HTML markup). Then we should have something that says:"When that button is clicked call this function with that arguments." or "Hide this element while you that JS array is empty" and so on. So how we can put/say/state that connection in a readable, reusable and clean way.
If you used another JS file to handle that connection, then you 'll have large lines of code just to put your connection logic and you need to know how to select the DOM element you are targeting. You 'll end up with massive code(probably lot of jQuery) just to make your HTML dynamic and alive(i bet most developers got into that many times). I haven't use other libraries or frameworks but i think they just make your massive code more organized.
On the other hand by KnockoutJS use Declarative Bindings, this is the link between models and views. It's more readable, easy to plug it in/out and it allow you to just focus on writing a good JS model object.
I guess to truly check separation think what if you sometime needed to change your model, how much changes you need to do to your view? and vice versa?
Adding to the rest of the answers, some tips:
Make sure there's no business logic in your bindings. Any logic (which should be minimal) should be "view logic": decisions that only affect how your view looks, not how it works. Deciding how many items to display per screen is view logic; deciding whether the user can add another item is business logic. It's perfectly OK to put view logic in your viewmodel rather than your view, and it's desirable if it involves lengthy expressions.
Keep "magic numbers" out of any view logic in your bindings. If it's a parameter that could be changed (e.g. number of weeks of results to show) as opposed to a true constant (e.g. number of days in a week), make it a property of your viewmodel and reference it in any expressions in your views.
i noticed a very strange way of naming classes in G+ and gmail..
example: a-b-h-Jb a-b-Rf-dB a-Rf-dB d-s-r (see G+'s code for yourself!)
who the hell does that? impossible to keep track of what you did in future.. same for gmail.
it is a known way of doing css that i am unfamiliar with? is it OOCSS? if a googler is reading this, can you please explain? Or if you are not the one who wrote the code, then please share your thoughts or prove that i am a dumb ass and don't know about a fairly common css naming 'good practice' (can i even call it that?)
Google uses something called the Google Web Toolkit (or simply GWT) to compile Java "applications" into their Javascript/HTML/CSS counterparts. GWT was used for GMail and Google Wave and my assumption is that it was also used for G+.
The GWT "compiler" (CS purists would never call GWT a compiler but the term fits) programatically names Javascript functions, CSS classes, HTML form IDs, etc. so they are almost never something legible.
At a guess, they probably have everything written out nicely in full at some point, and then put it through some program to compress it (reduce the length of variables). This reduces readability but also reduces file size, improving load times in theory.
Summary for the impatient:
What I want to know is what you want to have in a new gui language. About the short answers mentioning $your_favorite_one; I assume you mean that, such a language should look like $your_favorite_one. These are not helpful. Resist the temptation.
I'm thinking on the user friendliness of XML based languages such as XHTML (or HTML, although not XML they are very similar), XUL, MXML and others ("others" in this context means that, I am aware of the existence of other languages and their implementations alternative to their original ones, and the purpose of the mentioning only these languages by name is, to give an idea of what I am talking about and I don't feel like mentioning any others and also, I see no point in trying to make a comprehensive list anyway.). I have some opinions about what features should such a language have;
The language should be "human writable" such that, an average developer should be able to code a good amount without constantly referring which tags have which properties, what is allowed inside what. XHTML/HTML is the best one in this regard.
There should be good collection of controls built-in for common tasks. XHTML/HTML just sucks here.
It should be able to be styled with css-like language (with respect to functionality). It should be easy to separate concerns about the structure and eye-candy. Layout algorithm of this combined whole should be simple and intuitive. Why the hell float removes the element from the layout? Why there is not a layout:not-included or something similar instead?
I know that I don't even mention very important design considerations like interaction with rendering engine and other general purpose languages, data binding, strict XML compliance (ability to define new tags? without namespaces?) but these are the points that I would like to ask what you consider important for such a language?
There will always be a tradeoff between ability and simplicity.
Personally I'm happy with the features of WPF (which uses XAML) for MS development. I dont find its complexity to be a barrier to developement at all.
However if your going to target your toolkit/language to a demographic that requires a higher degree of simplicity, you could possibly get away with leveraging an existing framework and provide the end user with a DSL specific to their needs.
Writing a new framework for the dev community as a whole is a mammoth undertaking though, and I suspect you will find that due to the wide range of features required that you will have to deal with a large degree of complexity at some point. Best of luck.
Most recent XML GUI language (not only for GUI actually) is called XAML. It has all that candies: styles, layout definition, objects initialization, etc. But it's a pain to write more or less large XAML files. Auto-completion helps but the core problem - forest of angle brackets - is not solved. Another problem with advanced XML-based GUI langs - they try to serve to several purposes at once, but XML syntax is not suitable for all situations. For example XAML supports data-binding, but why the hell I should write it in attribute string? It's first class feature and should have proper support.
IMO all modern XML-based langs suck terribly. Language intended for humans must not force it's users to write tons of brackets or do deep tags nesting. It must be user friendly, not computer friendly. My dream it to have GUI language with Python-like syntax.
In conclusion I want to say:
Dear XML-based langs authors, please be humane, don't create another language based on XML. Read some good book on Domain Specific Languages and please, don't make me type < and > symbols ever again.
You should have specified whether you mean web or rich client, but either way take a look at XAML/WPF. If you're anti-MS, then look at Moonlight, the Mono implementation of SilverLight.
I would like it to be easy to connect to any database, perform queries that return a recordset, and be able to parse and iterate easily said recordset to display its data in graphic controls, for example pie-charts, bar-charts, timeline charts (stock options like), node graphs with animation effects, all this at run time.
Easy mouse events catching, to implement any action on rollovers, mouseins, mouseouts, clicks, drag and drops, clipboard management, etc. A good infinite zooming capability would be great too.
I don't want to set a "datasource" that establishes a fixed connection between some column in my SQL query and some displayable element at design time, I want to perform any query that I want and show elements tied to any query field, anytime, in run time. I don't want to be only able to bind a datasource and displayable elements at design time.
css style capability for everything. Or something as simple and easy.
resize and layout taken care of automatically. Easy access to local files, to parse, play, display. Easy classes for image management, supporting transparency, resizing, etc. Basic and advanced classes for drawing in the screen: lineTo, rectangle, circle, animations. Even 3D.
Embedded fonts functionality. I don't want to worry about "will the user have this font installed?" Also I don't want to worry about DPI or screen resolutions.
Basic widgets: treeviews, etc.
A good designer. I don't want to add widgets writing the code. I want to place them visually in the screen.
Also, it would be good if it could connect to dlls made in C++ or COM objects in general.