Do you know a decent MVC framework for AS3? I am currently looking into PureMVC but I need some reassurance that it's the best choice.
Do I really need to use a framework? or would it be better for me to implement MVC myself?
I'm assuming by AS3 you mean flex/AS3. Cairngorm is the defacto standard and was written by adobe consulting; Hence, you will find a lot of community support. There are a few others including PureMVC. There is an article on the adobe/flex website which gives a good description of all of them.
i followed MVC Design Pattern in AS3
i.e,
The model represents the information (the data) of the application and the business rules used to manipulate the data
The view corresponds to elements of the user interface such as text, checkbox items, and so forth
The controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.
if you have any doubts about implemention of MVC you can refer actionscriptworkouts.blogspot.in
Carnigorm and PureMVC are good choices, but my personal opinion is that Robotlegs is far easier to work with.
http://www.robotlegs.org
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I found lots of HTML5 UI frameworks over there, such as:
Kendo
Wijmo
jqWidgets
Zebra
Sencha
SproutCore
YUI
XUI
Shield UI
I'm kinda overwhelmed with again so much resources out there.
Looked some of them, but almost all seemed like too slow and heavyweight.
I'm getting a bit confused about which one will I learn.
Each of their websites talk about their product as if they were the best on the market. (obvious marketing strategies).
As a beginner on web apps development and client-side JS UI frameworks; you guys, based on your experience which one do you recommend for rapid desktop web apps development considering speed, widget collections, complexity, look n' feel, support, etc?
Which one do you recommend me to start learning?
I know there could be lots of answers and each one could prefer different ones, but this could help to guide me a little and have some critics of some of the most popular frameworks.
There is so much in your question, that the answer won't be easy and won't be definite at all. It'll also be very opinionated. Looking at the list of framework you brought, I see very different things that are hardly comparable with each other. I'll try to group them somehow and add more frameworks to the list.
The main question here is not the pros and cons of a particular framework. The main question is: how much do you want? Did you really mean an application like Gmail or Grooveshark? Or did you mean something like Stackoverflow - a dynamic and not at all simple, but still a website. Let's consider all of these options.
Perhaps, you just want to enhance your website with some widgets, like tabs, dialogs, some draggable/droppable elements, text editing, etc and you are not willing to change your development model. I mean, you use your favourite Java/PHP/Ruby and do not wish to write the a lot of your app's logics and behaviour in JavaScript. In this case, jQuery-based plugin-like solutions will do for you, particularly, jQuery UI and jQuery Mobile.
jQuery widgets follow its plugin system. This generally means, that they are extremely easy to use. In order to create a button, you write:
$('#myButton').button();
Now if you want to disable it, you call a method using following pattern:
$('#myButton').button('disable');
And getting or setting values, e.g. on slider or datepicker, looks like this:
$('#mySlider').slider('value');
$('#mySlider').slider('value', 42);
As you see, jQuery-based solutions have no model. All your data is kept in DOM and is obtained via quirky method calls. If you need to dynamicly process your data, e.g. do some complex validations, load something in background, filter or sort, then you see that this will soon get messy. By the way, this is the problem why jQuery UI team has not provided a grid control yet - they can't do it without a model. In jQuery Mobile you get a nice mobile UI by the means of simple markup, but there is no official way to pass data between pages.
Summing this up: if you have a multi-page website, if you POST your forms, then use jQuery UI or a lighter solution like Twitter Bootstrap.
Perhaps, you want to build something more complex, more application-like (a single-page application?). You know you will need to work with data on client side. What are your options then?
You can use one of many JavaScript frameworks that provide you with models, data binding and probably other means of creating web apps and integrate them with why not jQuery UI. Or you can use a more complete framework like Kendo or Wijmo or jqWidgets. These frameworks rely on jQuery (Wijmo relies on jQuery UI) and provide additional means of data manipulation. They have a data models. Kendo implements its own solution (I think), while Wijmo and jqWidgets integrate with the popular Knockout JS.
So Kendo and Wijmo belong to the group of frameworks that provide both widgets/controls and some backing model. There are other frameworks like these, that are not jQuery-based, e.g. Dojo Toolkit. Add some dynamic data loading and you'll get a somewhat complex web application. What more can you wish?
Actually, the most important thing is forgotten - how do you structure (organize) you application? If you try to build a single-page app that communicates with server in RESTful way, then you will soon get into a mess if your application has no architecture. The features that are usually required for this are some concern separation (MVC, MVVM), templating, routing and module management. This is where SproutCore and Sencha appear. They provide a comprehensive solution for building web apps, where widgets are just a small part.
It may seem like SproutCore and Sencha are the winners here, because they are the most complete solutions that include both UI and the business logics and also structure your application. Despite all the pros, there are some cons. Some say they are too heavyweight or will require to adhere to their development model, which you might not like. For example, in Sencha you describe your GUI in JavaScript and use Sencha's type system. This adds a sort of heavy feeling that there are abstractions and wrappers, while you really like the ease of HTML, CSS and vanilla JavaScript.
But this is not the only way. The power of web is that there are many-many frameworks, libraries, tools out there, smaller and bigger ones, that will help you craft your app the way you like it. For example, consider AngularJS. It doesn't provide a set of controls itself, but combined with Twitter Bootstrap becomes a complete solution for RIA. Or, for example, look at EmberJS, a more lightweight framework from the guy who created the heavyweight SproutCore. It doesn't provide you with a set of widgets either, but is, in my opinion, a very good base for an app.
So here is my final thought instead of conclusion. All those framework usually show you their widget set, nicely looking themes and the other visual stuff. But what really matters is how you will actually develop you application, how you will structure it, where you will implement your logic. Get to know what the framework provides and think through whether you can substitute what's missing.
Infeligo's answer is top notch. My experience may be of interest to some. I use Ruby on Rails as my server platform where the bulk of my business logic resides.
At the front end I use dHTMLX which is a JS library of 'objects' the most powerful of which is their grid object. Most of my apps have business/accounting information processing/display requirements and the grid object is my mainstay there. However their object set is comprehensive including the ability to create additional 'windows' within the single application to provide a MDI type interface to the end user. I typically have a login form which when successfully applied opens a single HTML page with a menu at the top. Based on selection from the menu new windows are opened and closed to display / manipulate information. These windows are within the scope of the single HTML page.
All the objects have very good events associated with them and I do quite a bit of validation at the front end using these events. However I usually duplicate all validation of data within the Rails Model as well. It's additional work but I'm just extra cautious. There are also a number of abstract objects that help to connect data between the front end visual objects e.g. grid and back end server. Most of the data connections can be done using XML or JSON. I use XML over JSON simply because of my experience with that structure and the fact that Rails provides a decent XML builder. So in my case I rarely use any Rails based views as all of my visual objects come from dHTMLX.
The other thing I like about dHTMLX is the speed of their objects. For example the grid object will quite easily handle 10,000+ rows at very acceptable speeds.
The BIG DOWNSIDE of the suite is it's documentation. The company is an eastern European developer and therefore it is often difficult to understand exactly what their documentation means. Also their documentation tends not to document everything completely and so a lot of time is wasted in trial and error type learning.
Hope this helps
I'm still studying OOP designs, so what's the best way to achieve an inventory for a simple flash game ? It seems that more than one design pattern could deliver some kind of an invetory but I would lose the flexibility if I try to adapt it somehow without a good knowledge about the subject.
For money to buy what is available in an inventory I thought of Singleton. If there's enough cash earned while playing the game, then one can buy new skills.
Maybe decorator pattern could list many thumbnails as buttons, and clicking on it applies new features and skills to the character.
I'd like to read standard advices on solving this problem, because I feel I'm on the wrong way. Thanks.
Stay away from singleton if possible
Singleton has its uses, however I believe it's overused in a lot of cases.
The biggest problem with a singleton is that you're using Global State, which is generally regarded as a bad thing as when complexity in your software grows it can cause you to have unintended side effects.
Object composition might be a better way
For games you might want to take a look at using Object Composition rather than traditional OOD Modelling.
A software component is a software element that conforms to a
component model and can be independently deployed and composed without
modification according to a composition standard.
A component model defines specific interaction and composition
standards. A component model implementation is the dedicated set of
executable software elements required to support the execution of
components that conform to the model.
A software component infrastructure is a set of interacting software
components designed to ensure that a software system or subsystem
constructed using those components and interfaces will satisfy clearly
defined performance specifications.
Component based game engine design
http://www.as3dp.com/2009/02/21/design-pattern-principles-for-actionscript-30-favor-object-composition-over-class-inheritance/
Reading over the material in the first link should give you some excellent ideas on how to model your inventory system and have it extendable in a nice way.
Standard way of working on new API (library, class, whatever) usually looks like this:
you think about what methods would API user need
you implement API that you suspect user will need
So basically you trying to guess what your API should look like. It very often leads to over engineering stuff, huge APIs that you think user will need and it is very possible that great part of your code won't be used at all.
Some time ago, maybe few years even, I read some article that promoted writing client code first. I don't remember where I found it but author pointed out several advantages like better understanding how API will be used, what it should provide and what is basically obsolete. I think idea was that it goes along with SCRUM methodology and user stories but on implementation level.
Just out of curiosity for my latest private project I started not with actual API (some kind of toolkit library) but with client code that would use this API. Of course my code is all in red because classes, methods and properties does not exist and I can forget about help from intellisense but what I noticed is that after few days of coding my application "has" all basic functionalities and my library API "is" a lot smaller than I imagined when starting a project.
I don't say that if somebody took my library and started using it it wouldn't lack some features but I think it helped me to realize that my idea of this API was somewhat flawed because I usually try to cover all bases and provide methods "just in case". And sometimes it bites me badly because I made some stupid mistake in basic functions being more focused on code that somebody maybe would need.
So what I would like to ask you do you ever tried this approach when needed to create a new API and did it helped you? Is it some recognized technique that has a name?
So basically you're trying to guess what your API should look like.
And that's the biggest problem with designing anything this way: there should be no (well, minimal) guesswork in software design. Designing an API based on assumptions rather than actual information is dangerous, for several reasons:
It's directly counter to the principle of YAGNI: in order to get anything done, you have to assume what the user is going to need, with no information to back up those assumptions.
When you're done, and you finally get around to using your API, you'll invariably find that it sucks to use (poor user experience), because you weren't thinking about how the library is used (UX), you were thinking about what the library must do (features).
An API, by definition, is an interface for users (i.e., developers). Designing as anything else just makes for a bad design, without fail.
Writing sample code is like designing a GUI before writing the backend: a Good Thing. It forces you to think about user experience and practical effects of design decisions without getting bogged down in useless theorising and assumption.
And contrary to Gabriel's answer, this is not bottom-up design: it's top-down. Rather than design the concrete backend of your library and then force an abstract interface on top of it, you first design the interface and then worry about the implementation.
Generally speaking, the idea of designing the concrete first and abstracting from that afterwards is called bottom-up design. Test Driven Development uses similar principle to what you describe to support better design. Firstly you write a test, which is an use of code you are going to write afterwards. It is important to proceed stepwise, because you have to proove the API is implementable. IMportant part of each part is refactoring - this allows you design more concise API and reuse parts of your code.
Which presentation patterns do you think Ext favors or have you successfully used to achieve high testability and also maintainability?
Since Ext component instances usually come tightly coupled with state and some sort of presentation logic (e.g. format validation for text fields), Passive View is not a natural fit. Supervising Presenter seems like it can work (and I've painlessly used it in one occasion). How about the suitability of Presentation Model? Any others?
While this question is specifically for Ext, it can apply to similar frameworks like SmartClient and even RIA technologies like Flex. So, if you have any first-hand pattern experiences with any other web UI technologies, your input would still be appreciated.
When thinking of presentation patterns, this is a great quote:
Separating user interface code from
everything else is a key principle in
well-engineered software. But it’s not
always easy to follow and it leads to
more abstraction in an application
that is hard to understand. Quite a
lot design patterns try to target this
scenario: MVC, MVP, Supervising
Controller, Passive View,
PresentationModel,
Model-View-ViewModel, etc. The reason
for this variety of patterns is that
this problem domain is too big to be
solved by one generic solution.
However, each UI Framework has its own
unique characteristics and so they
work better with some patterns than
with others.
As far as Ext is concerned, in my opinion the closest pattern would be the Model-View-Viewmodel, however this pattern is inherently difficult to code for whilst maintaining the separation of the key tenets (state, view, model).
That said, as per the quote above, each pattern tries to solve/compartmentalise/simplify a problem/situation often too complex for the individual application at hand, or which often fails when you try and take it to its absolute. As such, think about getting a 'best fit' as opposed to an absolute when pattern matching application development.
And remember:
The reason
for this variety of patterns is that
this problem domain is too big to be
solved by one generic solution.
I hope this helps!
2 yeas have passed since this question was aksed and now Ext-JS 4 has a built-in implementation of the MVC pattern. However, instead of an MVP (which I prefer), it favors a straight controller because the views attachment themselves to the models through stores.
Here's the docs on the controller:
http://docs.sencha.com/ext-js/4-1/#!/api/Ext.app.Controller
Nonetheless it can be made to act more like a supervising controller. One nice aspect of Ext-JS is the global application objects ability to act like an event bus for handling controller to controller communication. See this post on how to do that:
http://www.sencha.com/forum/showthread.php?176495-How-to-listen-for-custom-events-fired-in-application
Of course the definitive explanation of all these patterns can be found here:
http://martinfowler.com/eaaDev/uiArchs.html
Doing a bit of research on dependency injection frameworks for AS3 to retain loose-coupling of classes and boost our re-usability of code. I've been looking heavily at RobotLegs. There's a whole lot I still don't understand about the framework but it seems ideal for our regular Rich Media apps but has anyone used this framework for AS3 games? if so is it a good framework for games or should I be looking for another framework? I've heard that the MVC pattern isn't ideal for game design but would love to be set straight on this :)
I'd love to hear from anyone who's used a dependency injection framework for games, how it faired for them!
Cheers,
Anton
I used RobotLegs for a game that required integration with a few different backend services. One service gave me a multi-player lobby area to allow players to challenge each other, one handled the head-to-head gameplay after a challenge, and one allowed players to access information from their social network accounts.
From the beginning, I planned the game's architecture as if I were building a Rich Internet Application. The game itself was an implementation of a popular turn-based board game. Thinking about how to run a local game vs a network game definitely helped me stay on track with the MVC framework approach to game development. There was a ton of code that could be reused, and the difference between interpreting a local player clicking with their mouse versus receiving a message through the network to indicate that a remote player did something similar helped me see what logic simply couldn't be tied to the view at all. I was able to use models, commands, and mediators very smoothly, and in the end, it made the game's code more maintainable and easier to understand when I delivered it to my client.
I think most games will have a basic model that tracks the "board" whether it be pieces in a grid or enemy ships and asteroids out in space. Once you're thinking of the model as a separate entity from the view, it should be easier to imagine how player interactions through mouse and keyboard could trigger commands from controller to make changes to the model and notify the view of those changes. For some simple games, that might end up being a lot more work. For others, such as those where long-term maintenance or multiple input methods are required, it can save some headaches.
Let's think about the different views in a game for a second. Views can include a title screen, a settings/options screen, a multi-player lobby, high scores/leaderboard screen, and the main game itself (which could consist of many smaller views!). Many of these views can have models, like the list of high scores, the various settings (which should be shared between the options screen and the game views), the list of players waiting for a game, and the current state of the game, etc. By the way, need a way to save the game so that a player can restart where they left off? It's way easier to do that when the data is in a model and not tied directly to the view.
I think that too many Flash developers look at games as hugely different beasts from Rich Internet Applications. An MVC framework can be appropriate for a game, especially for multi-player and for games that you intend to iterate on over a longer period of time to add new content and features. The biggest challenge is making yourself remember the fact that cute, little furry critters running across your screen is just a visualization of data that might easily be displayed in a different way using DataGrid or a chart... though it may not be as fun to play with them that way!
RobotLegs is brand-new, so you'll struggle to find many people who've used it in production. They finally moved from release candidates to a first stable version last week. However, it has been created by a whole bunch of extremely well-respected coders and if your project is across the middle-to-long term, you will see adoption of RobotLegs explode during the lifetime of your project. It is going to be what all the cool kids are using! :)
(I have no stake, other than having occasional communications with some of the authors via Twitter and across the blogosphere).
HTH
AS3 is not my business at the moment, but game-frameworks are ;)
So, yes and no, MVC pattern are not your first choice, because you do not create that much views, controllers and models.
You have something more like an interface, some generic "engine" processing the game mechanic, and some database tables.
I currently use some aspects of MVC but not the complete pattern - "just the benefits".
EDIT:
You "can not say that:" MVC is not designed to be used inside a game (engine), because the MVC pattern only describes a logic, and not something pre-defined, like "the code always has to contain $x and must begin with include($y)".
It is just a design pattern, which does not directly affect the quality of the code, rather the progress and how you go on with your game design.