|Page 1 of 1||[ 5 posts ]|
I've recently embarked on a project/tutorial series, that illustrates how to create game tools ( a 2D level editor ) in HTML5, documented all the way. The underlying technologies are YUI3, easelJS and handlebars. I know there aren't many tutorials out there that cover how to put all of the pieces together, especially making use of MVC and Y.App. Ideally it will run completely server free when done.
So far the following parts have been written:
Creating game creation tools using HTML5: The basic YUI MVC app framework
This covered a basic overview of the project and goes about creating the skeleton of the application. A simple model is setup, as are some Views, a few templates and a simple server.js for hosting from Node ( not required. ) Most views are simply placeholders at this point. It runs, and shows data in a view, populated by a model and routed by an app, so basically all the basic points ticked.
YUI Topics covered: Y.Model, Y.View, Y.App, Y.io synchronous request, handlebars templates, creating a composite view ( a view composed of multiple views ), YUI.add(), YUI.use()
Creating game creation tools using HTML5: Setting up the EaselJS canvas
This section covers two key features, creating the map view, where the level will be drawn. This contains a canvas tag and creates a EaselJS object. It then wires things up so the drawing surface takes up the majority of the screen and scales as the window is resized ( something canvas makes remarkably more difficult than it should! ). Just to prove easel is working, a simple animation is played across the editor portion of the screen.
YUI Topics covered: integrating a 3rd party library ( EaselJS ) with a YUI view
Creating game creation tools using HTML5: Let there be menus!
We add a menu to our app. We then communicate between the menu and the view by firing events from the menu and handling it in the (parent) view.
YUI Topics covered: Y.Plugin.NodeMenuNav, firing and handling custom events
Creating game creation tools using HTML5: Adding a sprite sheet upload dialog
We add a modal dialog for handling *uploading* (local only using FileReader api ), as well as a new model for holding spritesheet information. We also add all of the code for displaying the dialog when a menu item is selected and handling the resulting data.
YUI Topics covered: Y.Panel
Creating game creation tools using HTML5: Redux
In this section I clean up a series of bugs, hacks and other problems. Based on user feedback and new things learned, I just generally make the code all around better.
YUI Topics covered: Y.bind, YUI_config, other
Each post includes a running version of the app to that point, and a zip containing the complete sources.
I do not pretend to be an expert of YUI, so this is more a "Here is how it works", not a "this is best practice". It is also extremely informal, written as I go, so mistakes will be corrected in future updates, code will be re-written and refactored as features change and problems are discovered.
The application is pretty primitive at this point, but is actually fairly complete and could be used as the basis for a much more complete application.
If there is interest, I can update here as I add additional parts. Feedback and comments of course appreciated. I hope this project proves handy for some of you looking to learn YUI3 HTML app development.
Last edited by Serapth on Fri Oct 26, 2012 1:14 pm, edited 1 time in total.
Looks pretty good so far (even if a bit 'jarring' as you say). And I only say that because my style is patterned so closely after the GitHub Contributors example, 'cause that's how I learned this stuff. (I studied that thing for 6 weeks before writing a line of code.
I just need the structure and control flow handling. But it does show you can wing it if you want to. YUI certainly doesn't lock you in. You made a good choice.
1. It's a bit over-modularized for my taste. Not sure everything needs to be a separate module. Yes, my app is just two bigass modules, one HTML and one CoffeeScript, ~3000 lines so far, and it's only about half done, and I probably should do some more in that regard, but with the framework and a good editor (ST2) it is manageable. And fairly fast.
I do like how clean your main page is.
2. It seems to be under-utilizing the App component and placing too much responsibility in the editorView. Composite view is great, I've got one like that, but I think you're going to find that the app component could be doing a lot more for you in terms of routing and especially event handling.
Not crazy about the Y.Global... stuff. And if you ever decide you need to re-render that view for any reason, you're gonna want the app component to be in charge of that. I've discovered ( the hard way ) that views cannot effectively re-render themselves. Especially if the destructor is doing any heavy lifting. (And you may find you need to use the AsyncQueue or such, just a bit... I've had pretty good luck with it.)
3. Interesting approach in the SpriteSheetDialog module. I just create mine in app event handlers, and then direct the action from there. But, it's just a whole different control flow style...
But it looks very interesting. It's good to get a different perspective on things now and then. Haven't really gotten into HTML5 yet, just doing line-of-business stuff, but I would like to play with that if I get some time.
Thanks for the feedback, it is much appreciated.
In regards to modularity, as you said, that certainly comes down to a matter of tastes. If I am honest, this code is split out a bit more than I would generally have done so, mostly as a resulting of templating, a feature that I am not completely sure is worth the gains. That said, I think I would go insane having a single 3000 line file!
You are certainly right about my App utilization. In fact, in conversation with another user from this site, it is suggested that I simply do not need it at all. See, this is certainly one of the downsides of "winging it" ... when starting out, I foresaw the need to have multiple views handled by the router, but in actual execution, once I went with the composite view, I may have removed any need. Fortunately, routing everything through the Composite should prevent any view from ever having to render itself.
I do have a question to the community though. If you have a single page app built around a composite view, what is the recommended mechanism for communication between views, both directly ( one view to another ) or broadcast ( app wide events )?
No problem. Glad to help.
In regards to the suggestion that you "simply do not need it at all", I was originally going to mention that it looked like you could get by with just the "TodoList" example design, which is just a View acting as the main controller. It's certainly an option for you if you don't need the overhead of the Router and Pjax and all that.
Regarding your question about the recommended mechanism for communication between views, that's an easy one.
By the book, baby. That's how I do it. (I've never been accused of being a great original designer...)
And it would work just as well for the simplified "View-as-main-controller" design.
Thanks to a great deal of feedback and information from Satyam here on the yui forums ( thanks! ), I just finished fixing up a lot of the uglier bits and straight out mistakes, making the code much cleaner going forward.
I basically document the process in this post.
YUI specific topics include YUI_config, Y.bind, passing context to event handlers and more. Now on to adding new functionality.
|Page 1 of 1||[ 5 posts ]|
|You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum