JavaScript (the language, not the browser bindings for the DOM, etc.) can be either brutally hard or refreshingly flexible. It's difficulty is directly related to how well you grok a couple of core concepts. I'm going to just list them and leave in-depth explanations to Tom's forthcoming book on advanced JavaScript.
Here goes:
- Everything in JavaScript is an Object. Even functions
- Every object is always mutable
- The dot operator is equivalent to de-referencing by hash (e.g.,
foo.bar === foo["bar"]
)
- The
new
keyword creates an object that class constructors run inside of, thereby imprinting them
- Functions are always closures (combine w/ previous rule to create OOP)
- The
this
keyword is relative to the execution context, not the declaration context
- The
prototype
property is mutable
If all of that makes sense to you, JavaScript can be a fun, liberating experience. If not, it's going to be a world of pain and broken expectations as you shed the baggage of less dynamic languages.
Good luck.
Yesterday I had a chance to attend MashPit. After much deliberation over what should be tackled, a "self organizing" team that included Cal Henderson, Matt Mullenweg, and myself decided to wrestle collaborative localization. It's one of those problems that doesn't get much love because when a team (open source or not) has to tackle it, they do whatever minimum is necessary to make the pain go away. Larger companies just pay bucket-loads to make it disappear.
Clearly, we need something better. Something shared, something in-situ...something usable by real, live people.
In just shy of 4 hours, we went from a bunch of drawings to a working, demo-able system that will let people quickly post translations to a central location, (eventually) import from and export to other localization formats like gettext, and provide developers with a straightforward way to generate pages that let anyone donate translations.
We don't have a name for the project yet, so suggestions are welcome, and public (anonymous) SVN is available from:
http://svn.dojotoolkit.org/langp/
We've got a lot of work left to do, but a translation-commons is something that everyone needs. Time to make it happen.
My work on Dojo isn't solely the product of a gigantic sleep deficit. Were it not for the generous support of JotSpot, the application platform cleverly disguised as a wiki, I think Dojo might not be a reality today.
Jot's support has been massive and prolonged, and over the past year we've built multiple features and products on top of the wiki platform that use Dojo in some way. This past monday we took the wraps off of our most heavily Dojo-based product yet: Tracker, a tool for doing lightweight list-like collaboration on the web. Think of each line in a Tracker "spreadsheet" as a wiki page which you can allow anyone to edit and attach things like images and files to. Spreadsheet++, if you will.
As the word "Beta" implies, we know there are a lot of the sharp edges and are working hard on getting them rounded off for you, but please do give it a try. If it doesn't keep you from firing up another instance of Excel for tracking a small list of things, we'd love to know why.
In a previous post I outlined how easy it is to upload files using Dojo's pluggable I/O system. By including the IframeIO package, Dojo makes sending forms containing file upload elements is just as easy as making any other Ajax request.
But what about when you want to send data as though it were a file being uploaded, but you don't actually want to pull a file off the disk? Eugene Lazutkin needed exactly this and worked up patches which are now a part of Dojo. Admittedly it's not something you need all the time. After all, you've been making due without it for years, right? But there are many situations where being able to treat the browser as a file editor for plain-text content makes sense, and sending content pre-encoded as files can help.
The default XMLHTTP transport class supports this unique feature through the file
argument. The system expects file
to be an object with 3 properties:
name
- the filename
contentType
- optional, defaults to "application/octet-stream"
content
- the content of your file as a string
From here it's easy to construct a dojo.io.bind()
request that uploads some content as a file:
dojo.io.bind({
url: "upload.cgi",
// we expect to get JSON back from this CGI
mimetype: "text/json",
// handle the returned JSON
load: function(type, data, evt){ },
// normal properties
content: {
foo: "bar",
baz: "thud"
},
// our file content
file: {
name: "upload.txt",
contentType: "plain/text",
content: "look ma! no form node!"
}
});
From here all of the mime-encoding magic is handled for you.
File uploading without the file: just one more reason to drop that 10-line one-off XMLHTTP wrapper and pick up something better.
If you've got a recent Safari build, give this demo a spin. Being able to do drop shadows without images is a pretty neat trick, but it only works on Safari for now. Firefox 1.5 only has stub functions in it's <canvas> implementation where it's shadow property getters and setters should be.
I'm working on a more portable variant to support FF, which we can then turn into a Dojo widget. Stay tuned.
Older Posts
Newer Posts