Just put out JavaScriptMVC 2.0’s 2nd Alpha. It has Selenium testing integration. If you aren’t using models, now is a good time to switch.
Expect a fabulous beta out next month.
I’ve long considered testing to be the biggest problem with developing large JavaScript applications. Everything else JavaScriptMVC does, you can hack it yourself. It might be painful, but it’s still possible. Testing was an exception. It’s just too painful to setup, author tests, and run them.Creating a comprehensive and solid testing suite is goal #1 for JavaScriptMVC (especially after solving most problems with 1.5 anway).There are 3 big problems with any JavaScript testing solution:It’s not comprehensive.It’s painful to author tests.It’s slow to run tests. With 2.0, JavaScriptMVC combines the in browser test suite from 1.5 with selenium and rhino. Developers will be able to EASILY author tests with the browser, then RAPIDLY run unit tests in Rhino, and THOROUGHLY run all tests in each browser with selenium. Of course, rhino and selenium are tightly integrated with JMVC so there is no setup.
Simply use the generators to create a new empty application:
js jmvc\generate\app myapp
And run the resulting tests
js apps\myapp\test\run_unit.js js apps\myapp\test\run_functional.js
JavaScriptMVC’s blended testing approach provides the delicate balance between ease of use, comprehensiveness, and speed. For quick sanity checks, you can use Rhino based tests before checkin to ensure an application is fundamentally sound. For comprehensive nightly testing, use selenium to run your tests in each browser. When authoring or debugging, run your tests in the browser directly, one at a time.
To see this in action, check out JMVC’s latest. Run jmvc’s big tests like:
js big_test.js
You’ll need to be in windows with FF and IE installed.
I’m not sure if I will have time in this release, but very shortly, you can expect a Selenium like IE for authoring tests, but much better as JMVC’s delegators know every event to which you are responding.
Check it out here: http://javascriptchicago.com/blog/?p=65 I look sexy in a headband.
Yesterday we (Brian and Justin of JavaScriptMVC) officially released the Jabbify Comet Service, a long time in the making!
Jabbify Comet Service is the only Comet solution designed for easy development and quick setup. Here’s why its different.
Rapid setup
Download a script and you’re developing with Comet in 30 seconds or less.
Scale easily
Jabbify scales to thousands of users per domain with no additional maintenance on your part.
Simple to use
Its easy. Really really easy. All you need is the JavaScript API or GET requests, technologies most developers are very familiar with. Simply connect and send your message.
Comet made easy
Jabbify makes Comet as simple as possible, only the bare necessities. The diagram below shows how the Comet service works:
The code below connects to Jabbify with the simple JavaScript API and pushes “hello world” instantly to all users visiting this domain.
<script type=’text/javascript’ src=’jabbify.js’></script> <script type=’text/javascript’> // subscribe to incoming Comet messages OpenAjax.hub.subscribe(“jabbify.message.create”, function(name, results){ alert(name) }); / connect to the server Jabbify.connect({name: “Brian”}, function(){ // send hello world to all connected users Jabbify.send(“message”, “create”, { message: “hello world” }); }) </script>
Or, to push data from a server, such as to stream stock prices live to users, invoke a GET request with an API key for your domain:
https://jabbify.com/message_push?key=123456&name=StockTicker&type=GOOG&action=update&message=250.23
Running this demo from the filesystem is the quickest way to get started. Any pages running from file:// are treated like they’re on the same domain, and no registration is needed.
More info
Jabbify’s Comet Service is currently in beta and free for anyone to use. It will always be free for websites with a small number of concurrent users.
We’ve tried to make it as easy as possible to get started with plenty of docs and demos. There’s:
We’d love to chat with people to see what they think about a service like this. What do you think? Feedback welcome!
Probably the best free demo of JavaScriptMVC available is the Jabbify Chat Client, the same one in the lower right corner of this very page. It is a JavaScriptMVC application that connects to a Comet backend for instant communication with all users on your domain.
The code is open source and can be downloaded as an engine. This guide walks you through some basics of adding your own functionality to the chat client, recompressing, and distributing your own chat client.
I made some good progress today with JavaScriptMVC 2.0. Here’s what I accomplished:
I completely refactored test (as I want tests to drive JavaScriptMVC 2.0 … test-driven development … ahem). Test now makes much better use of the new Class. Each test case runs as an instance of the Test class. This makes the internal code much cleaner, and consistent with everything else (especially controllers) in JMVC. Have a look:
Save to Browser Favorites
Ask
backflip
blinklist
BlogBookmark
Bloglines
BlogMarks
Blogsvine
BUMPzee!
CiteULike
co.mments
Connotea
del.icio.us
DotNetKicks
Digg
diigo
dropjack.com
dzone
Facebook
Fark
Faves
Feed Me Links
Friendsite
folkd.com
Furl
Google
Hugg
Jeqq
Kaboodle
linkaGoGo
LinksMarker
Ma.gnolia
Mister Wong
Mixx
MySpace
MyWeb
Netvouz
Newsvine
PlugIM
popcurrent
Propeller
Reddit
Rojo
Segnalo
Shoutwire
Simpy
sk*rt
Slashdot
Sphere
Sphinn
Spurl.net
Squidoo
StumbleUpon
Technorati
ThisNext
Webride
Windows Live
Yahoo!
Email This to a Friend
If you like this then please subscribe to the MVC.Test.Unit.extend("Test.Delegate",{
init: function(){
$('#testarea').html({view: 'views/delegation'});
},
destroy : function(){
$('#testarea').html("");
},
test_document_click: function() {
var self = this;
var fn = function(event){
self.assertEqual(9, this.nodeType)
self.assert(event.target, $('#first')[0] );
}
$().delegate('','click', fn );
$("#first").synthetic('click')
$().kill('','click', fn );
}
});
Delegator is updated to work very similar to jQuery’s live in how you detach delegated events. Now, you can simply call kill:
my_callback_f = function(event){ ... }
$().delegate('','click', callback); //delegates from the document
$().kill('','click', callback); //removes callback
$('#nested').delegate(".todo",'click', fn); //delegates from the element with id=nested
I added the ability to use a view from the basic jQuery modifiers:
// works with prepend, append, insertBefore,
// insertAfter, replaceWith, text, html
$('#testarea').html({view: 'views/simple',data: {something: 1}})
You can dispatch synthetic events on elements with:
$("#first").synthetic('click')
Note: this is different than $(”#first”).click() as it creates a real event.
I just completed an interview (via Email) with OpenSource Release Feed. I talked mostly about my plans for the next version of JavaScriptMVC and how it will relate to jQuery. The site describes itself as:
Everything open source, from release announcements, to custom feeds that help you stay up to date with all of the latest releases you are interest in, articles, interviews and more. OpenSource Release Feed is linking the open source community
If you are into OS like I am, you might consider adding it to your RSS reader. Thanks for chatting with me Schalk!
It’s offical. I opened my heart to the jQuery community to have JMVC become part of jQuery. Now that jQuery supports event delegation, it only makes sense. If you agree with the idea, please let them know!
I’m very excited to let you guys know about our JavaScriptMVC 1.5 release. As you know, JavaScriptMVC’s purpose is to provide direction to JavaScript developers. We’ve done this in two ways: build tools (testing, compression, etc) and a maintainable architecture that provides separation of concerns.
JavaScriptMVC now includes Rhino. Having a JavaScript interpreter handy enables several very useful command line abilities that don’t exist together in any other JavaScript framework:
/**
* @constructor
* Constructor overview, what this functionality does.
* @init What the constructor function does
* @param {param_type} param_name description of a constructor function param
*/Starting with the best event delegation library and Model-View-Controller architecture pattern, 1.5 provides developers with more ways to reuse, organize, and package code:
TasksController = MVC.Controller.extend('tasks',{
dragging : function(){}, // callback for when you drag a 'task'
selectover : function(){}, // callback when you lasso a 'task'
mouseenter : function(){}, // custom mouse event that handles element layering
hoverenter : function(){} // callback when you hover an element
})Despite the many open-source JavaScript libraries, there’s a lot of work to be done for JavaScript development.
Besides the lack of integrated build tools, developers have to choose between customizing rigid high level widgets or building from the ground up with thin DOM abstractions.
JavaScriptMVC provides structure and organization to create, extend, and share functionality from the middle up. JavaScriptMVC 1.5 encompasses the entire development lifecycle with utilities for testing, compression, documentation, sharing components, and a maintainable architecture. It’s aimed at large or custom JavaScript projects that benefit from development rules, separation of concerns, and build tools.
This 1.5 release also comes with demos and complete API documentation. To get started we’d recommend the Getting Started Guide and the Learning Center.
For this edition of developing JavaScript, I was lucky enough to get a response from a rising young star in JavaScript, Juriy Zaystev - a.k.a Kangax. He is a prototype contributor and his work is often discussed on Ajaxian.
Living in Russia for most of his life and dropping out of college, he has an interesting background. Even more suprising, he’s only 23. I asked him to share how he got into JavaScript:
About 2 years ago, me and my friend were “making” our first website for a local high school hiking club. My friend somehow bought a “Professional AJAX” book by N. Zakas, but eventually ended up doing back-end in PHP. AJAX was kind of a “new big thing” back then and I decided to see what it is. Since I had zero experience with Javascript, AJAX book was pretty confusing, and so I started digging more into the Javascript language itself. Short after that, I read an article by Sitepoint about Javascript “frameworks” where author recommended Prototype.js as the best option at that moment and so I started digging into Prototype.js. About a year after, me and that very same friend “hakunin” decided to make a little website that would serve as a repository of all Prototype.js-based extensions. That’s how Scripteka was born. I also started writing Prototype.js tutorials on my blog. A couple of months ago I became a core member of Prototype.js and still serve my daily duty through the numerous tickets on Lighthouse : )
Here’s a taste of what he works on:
Scripteka (http://scripteka.com) was one of the first app-like websites that we have built. Then there was a Wehike (http://wehike.net), but that wasn’t an application - just a plain, very minimal, website. I recently worked for Aptana (http://aptana.com) together with Ryan Johnson (http://livepipe.net/), implementing front end of some of their redesigned sections. Other than that, my full time job involves intranet-based apps, and none of them are publicly available : (
His most visible work is prototype’s changlog.
Question 1: What programming paradigms do you use - Class / Prototype based inheritance, AOP, Functional Programming, etc?
I’m a bit of a performance freak and this, of course, reflects on the way I design applications. I try to stay away from patterns that provide “real” private members, since memory consumption is usually more important. Pseudo private members (i.e. those that begin with underscore and are documented as being private) work pretty well for us even in large applications.
Functional programming is definitely handy and often makes for quite elegant solutions. I absolutely enjoy it once in a while.
Other than that, proper “class”/object hierarchy and overall architecture definitely needs to be thought through. In my experience, any kind of inheritance emulation usually makes application simpler to understand and maintain.
I asked him to elaborate where functional programming has been useful:
Prototype extends `Function.prototype` with plethora of useful additions - `bind`, `curry` and `wrap` are one of the most helpful. Both `bind` and `curry` allow for a partial application - when different functions can be made out of one - by “currying” original with different arguments. Bind, of course, allows to specify within which “context” function should be called. `wrap`, on the other hand, allows to program in AOP style - “wrapping” functions with “before” and “after” behavior. `wrap` is also useful for monkey-patching core methods without ever touching library source. I’m always cautious when using these “helpers” - additional level of abstraction is useful but deceiving, and can easily kill performance pretty badly.
Question 2: What architectural patterns do you employ - MVC, SOA, Layers, Components / Widgets?
Service oriented architecture works out quite nicely for us. I wouldn’t say it affects client-side design much, though. I haven’t tried MVC approach on client-side either. Perhaps our systems are not large enough to fully take advantage of all aspects of MVC. Widgets, on the other hand, are a great way to encapsulate distinct pieces of functionality. I think DOM would be a great foundation for widget-based systems if it wasn’t designed and implemented so poorly; Instead of taking advantage of it, DOM usually needs to be thought of as a quite hostile and unpredictable environment - all for achieving maximum compatibility.
I asked him to follow up on what is implemented poorly in the DOM and how he would improve it:
- Careless resolution of “named” elements via document or global objects (i.e. when `form` with name=”getElementsByTagName” shadows native `document.
getElementsByTagName` method, etc. I’m still not sure how they managed to f*ck-up like this. ) - Verbose API, lack of relatively basic functionality (which HTML5 is trying to fulfill now), methods are not “chainable”
- Gaps in specification (and vague explanations here and there)
Question 3: How to you manage event handlers and responding to them?
I use event delegation where appropriate, of course. Also, having some kind of way of simulating “mouseenter”/”mouseleave” is a must.
Question 4: Dom Building - how do you build HTML?
I use templates often - chunks of markup presented as strings - which are then interpolated with proper values at runtime. I find this to be the most maintainable way to deal with DOM creation/modification.
Question 6: Testing - what level of testing do you do? What tools do you use?
I should definitely be doing more testing : ) I find it hard to test applications that change often and usually resort to just unit-testing separate widgets/scripts.
Question 7: Compression & Build - Do you compress your JS files, what do you use?
All assets are pretty much always gzip’ed; I don’t see a reason not to do so. Everything else depends on a project. Rails, for example, concatenates all .js files when set up properly so we take advantage of that. Minification, on the other hand, is usually not much of a high priority.
Question 8: What development methods do you use - Waterfall, Agile, V, Story based, Requirement based?
I work in a very small team where we have a very transparent and flexible communication process. We try to stay more on a side of “agile” than that of a “waterfall”.
Question 9: Documentation - Do you document your code? What tools do you use?
I try to document as much as I can. jsdoc is a perfect tool for that. I’m looking forward to using PDoc in the future (developed by one of Prototype.js members - Tobie Langel)
Question 10: File Structure - Do you have a standard file structure? What does it look like?
No standards really. Usually depends on the server-side framework in use.
Question 11: Performance - How do you tackle performance issues?
I constantly experiment - try to test alternative methods of doing things - finding more efficient solutions. It’s a lot of fun. I try to build apps with performance in mind right from the scratch. I’m not a big fan of “build first - optimize later” way of thinking. While it certainly has its advantages in building something fast, I think there’s a danger of designing a system with poor core components - something that could be really hard to “optimize” in the future. Oh, and reading ECMA specs are an absolute must and gives an amazing understanding of what kind of beast Javascript really is!