Basically we have two divs – #dragme and #dropme. We include “dd-drag” and “dd-drop” in the use statement to pick up the drag-and-drop functionality. This goes without saying that you need to include YUI:

Note we also can listen in on what’s going on with these drag and drop elements – they emit all kinds of interesting information (see the docs) as you move your drag element around and move it over the drop element. For this demo I simply added two event listeners – one for when the drag element is over the drop element (making the div turn yellow) and when you actually drop your element in the right place (making the drop div turn orange).

As I said, there’s a lot of things going on behind the scenes, and you can do all kinds of great tricks with drag and drop from YUI – including things like constraining the element’s field of movement, and having a drag “shim” – meaning a semi-transparent element that “stands in” for the real one so that the browser does not slow to a crawl when you try to drag some complex component around.

The way drag and drop is implemented in YUI really show’s off the power of the library. You can even dynamically make something “draggable” by just using a “plugin” – which is a snippet of reusable YUI code that enhances whatever node it is attached to.

My version of this code changes very little except that we will use YUI – and dispense with the quote removal aspects, because YUI takes care of that for you.

Start out by making a spreadsheet like this one.

You can try out the YQL query yourself with this link.

Now publish it as a web page like the linked article describes and get the CVS share url.

Check out the code below and replace the spreadsheet url that you have created with the default one of mine:

Hit run and you should see your spreadsheet data showing up on the fiddle!

This is very powerful and way moreso than the linked article suggests. First of all you can also link a FORM to a spreadsheet. You might do this to allow certain users to input data into your spreadsheet in a way that insulates them from actually seeing the spreadsheet, or accidently making destructive changes. You might also create a very simple blog this way by creating a spreadsheet form that includes the title, content, etc. When you submit the form it would update your spreadsheet. You then have a website that grabs the output of that spreadsheet and displays either say the list of titles (a certain YQL query) or say the page details. You could get pretty elaborate with this.

Another use-case might be say a data-drive web game. You have all the monsters’ images, hit points, colors, locations, etc defined in your spreadsheet. Then you could consume that information on the fly with say a canvas-based web game.

The key idea I want you to get here is that you can now easily do: Form->Spreadsheet->YUI+YQL->JSON->Website with basically no complicated server database. Huge idea!

Back now? Great. I enjoyed that short break.

This week it’s about getting back to the basics. I’ve been trying to get this app built for quite a while now, and I’ve managed to distill down the concepts I want to create for the first version. Essentially, you will have a set of “cards”. These cards represent the games that you might want to play at any given point in time. Each card will have a brief description as well as some stats about how many times you’ve played this game (if you launched it through Thwakr). You will also have a concept of a profile, which will allow you to set up your name, perhaps store user ids if you want (no passwords though).

For now, that’s it. Sign up. Log in, see some cards (that are games), click to play them, and record the play stats. This may seem like a trivially small feature set, but we will see just how much work it’ll take to get this far. For today I basically created the base HTML page with some markup for the cards, the profile, the about panel, and.. that’s about it.

You can see the source here.

What I am hoping to do is get the functionality working first. Before I even think about the UI, and getting it all prettied up. The first step in this is working on the HTML semantics. If you do this first, it helps you to think about the logical groupings in your app. What things are related, what kinds of clickable elements you want, etc etc. If you can get this down first, you will be a long way toward making your app a reality. Dont try to think about all the fancy CSS, or javascript interactivity. Think about how you want things to relate to one another, and how to organize them.

I’ve also decided to no use an special framework outside of just plain YUI + some gallery items for convenience. Perhaps in a later iteration but for now I really really just want to get it to “work”. Also, we havent talked much about the Chrome app aspect of this at all yet. That will come later, as it actually is only a small part of the overall development thanks to browser makers working to make extensions to their browsers work as regular HTML, CSS, js pages. We’ll also cover some promising sites like Crossrider which is kinda like PhoneGap only for cross browser extensions.

Next steps will be to begin building up some basic javascript objects which we will subsequently be using to harness together our application. I am conflicted about this because I know of a way that is “comfortable” to me, and I know of the way that is more “right”. (Via YUI Base). I’ll keep you posted as to which way I go with this.

Previous article: Part 1.
Next Article: Not yet.

Basically, if you want an easy way to insert dynamic web fonts on to your page, you can simply find the names of the fonts you want, and drop a variation of this code below into your site. Of course you need to do some CSS styling as well – but it takes out much of the tedious boilerplate code you may have had to write. Before using this code, however you should read up a bit on the Loader Library details, so you understand what’s going on and potentially set it up to better suit your needs.

Why not indeed. So starting today I’ll begin posting a kinda developer diary / tutorial as I try to build an application called “Thwakr”. What does this app do? Well, as I build this app, it will become pretty obvious. So, for today I simply have a few links for you:

Recipe for a YUI Application
Building Reusable Widgets with YUI3
Alloy UI

I’m basically in the planning stages. I will need to use localstorage, drag and drop, and several things like toolbars, etc. This has led me to consider using Alloy UI for the intial version. I can get pretty far with this, as well as maintain my own code in YUI3.3.

I’m also going with a concept of “it always works” – though I don’t know the technical term for it. But what it means is that no matter what I check in, the basic premise always works and you do not see broken links, or have dead-end behaviors.

If you want to follow development of the SRC for this app, then bookmark this github link: https://github.com/triptych/thwakr/tree/master/src/alpha/web

Regardless, you can take advantage of it Today, given that you can just .use() it. Here’s some code:

Now for a brief explanation. There are several config settings that can simplify most of how you’d want to create an iframe. Y.Frame goes beyond this however an allows you to include CSS, linked CSS, set the DOCTYPE, insert some initial HTML and fire an event back when it is finished. You can even set it up so that any events that are triggered in the child iframe get sent up into the parent YUI instance so it can do interesting things like mess with the DOM, etc.

I’ve only barely scratched the surface of this component myself, but it already will replace a bunch of my own code. Note that it’s still in “beta” and even has some bugs (for some reason the “name” ATTR is supposed to set a classname on the iframe, but right now does “nothing” However the beauty of YUI is that you can file bugs since it is OSS). I encourage you to take a look at the source, and of the editor source as well to see an example of how this is being used, and I encourage you to take advantage of this component yourself instead of hand-coding because it takes care of many IE specific problems.

Have you found a “hidden gem” in YUI? Let me know!

One of his recent projects is something called YUI-REPL. Essentially this is a command-line instance of YUI that you can use to test code, debug issues, and try out lots of interesting features of YUI without having to deal with a browser or having a page hosted somewhere. In order to try this out, you need to get node.js working as well as npm. Node.js is essentially a “server side” version of a javascript runtime that can load documents, do complex tasks, and lots of things outside the scope of this post. Suffice to say, if you have not been reading about Node.js you need to spend the weekend getting up to speed. NPM is a package manager that allows you to load cool utilities and features that Node.js uses and can take care of all the dependancies each of those utilities may need in order to run.

YUI-REPL is very similar to the REPL in node.js. You launch it via calling “yui3″ and you now have an interactive command line that lets you load in websites, load in YUI javascript code, call other YUI modules into your code via “use” statements, and all kinds of other interesting things. For instance here is a call to YQL that I created in my previous post — it works flawlessly here and actually represtents another use case for this REPL — debugging your web services. Mind blown yet?

Here is a snippet from @davglass that highlights the load feature of YUI-REPL:

Which loads this script:

And here is a screencast of YUI-REPL in action.

In terms of what sort of future YUI-REPL will have, I have heard that there may be plans to fold it back into the core YUI library somehow – so that you’ll be able to use it anytime as well as having more developers taking a look at the code and adding new features. One in particular may be to allow you to pipe info into and out of the app like any other UNIX command – so you could imagine writing some interesting shell scripts or QA testing of your site via a single command line.

I encourage you to go grab a copy yourself and check it out!

Here’s the YQL console command:

For your copy/paste ease:
http://developer.yahoo.com/yql/console/?q=use%20%22https%3A%2F%2Fgist.github.com%2Fraw%2F908359%2F3809546edb9241be39cb7cb10b9c2534e4ef4efc%2Fxplevel.xml%22%20as%20xpl%3B%20select%20*%20from%20xpl%20where%20basexp%3D%22100%22%20and%20numlevels%3D%2210%22%20%3B

Please see my previous article about the details of that service, and how to create your own. The crux of what I want to mention is this:

Which is part of this gist.
Do you get how amazing this is? With literally no server of your own, and with a few carefully set up YQL statements, you can build a complex web service that you could share with anyone to do literally “anything” with other services, pages, data, etc.

I hope you go from “whatever” to “WTF!” as fast as I did.

If you want to imagine some more mind-blowing things — check out the API docs for the javascript you can execute in your open data table.

http://developer.yahoo.com/yql/guide/yql-javascript-objects.html

Why are not more minds being totally blown by this?

For the attention impaired amongst you, here’s the code up front:

So, to try things out, click to the Result tab, move your mouse into the tan area (the little green box should turn blue) and use your arrow keys to move the little box around. What do you think? No big deal right? Well, actually it was surprisingly involved .

First off I would like to thank Luke Smith for his work on the YUI Gallery item: Arrow Event. Without it, this would have been much more involved, and to be honest I built some keyboard controls for a canvas based rpg I created, and as soon as you have to deal with different browsers, things get complicated quickly.

The purpose of this code is to show you how you might create a movable element in a web game using the browser’s arrow keys. YUI has this amazing feature that allows you to create your own “events” – called synthetic events. I encourage you to check out that example as the example is not only very useful for games, but learning how to create your own events will be a handy tool for wiring up your game logic.

If you look at the modules I included, you’ll see node, transition, event-mouseenter, and gallery-event-arrow. Let’s run through these quickly. I use node, obviously, because I want to access elements on the page. I often wonder why node just doesnt come “for free”, and I remember there’s SimpleYUI which does that for you (it includes most of the very common modules you’d need for most of your javascript needs). I use transition because I want my little box to move around smoothly. If you look at the code, for every “move” event – we transition to a new location vs just setting the XY coordinates directly.

The two includes left are event-mouseenter and gallery-event-arrow. I use event-mouseenter to try to force “focus” on the outer view. Focus is something that is a problem with events that you’ll have to deal with when you create games. I try to force focus on page load, and whenever the mouse moves over my game area. I try to avoid having to click into the play area, because there may be other elements in that view that listen for a click event, and may interfere with the action of “getting focus”. Note, you could also have used “hover” which is a rollup of mouseenter and mouseleave.

The real meat of this article is related to gallery-event-arrow. Luke has abstracted out the work needed to accept arrow key presses, as well as listening across browsers for holding the key down vs just tapping the arrow key. There are some gotchas that I ran into that I want to mention here. First off, I had to add a tabindex to the little box (of ID=”a”). This allows things that normally would not get “focus” and therefore events to actually get sent to the right element. Secondly once that element has focus, it has this convenient little focus box around it. I don’t know about you, but I don’t really want to have a little focus box around my game elements, unless there’s a specific reason, so in my CSS I added an #a:focus which does two things. It changes the box color to blue, so you know your box is movable, and I also suppressed the “outline” attribute. Thirdly, I ran into a bug where things would not work at all in Chrome. Initially I did not set the top: and left: attributes in CSS to the #a element. This resulted in Chrome trying to get the left and top attributes from getStyle() and getting “NaN”. You could probably find another way to get around this limitation in Chrome – and I encourage you to do so. As a matter of fact, I encourage you to go fork this “fiddle”, find some cool way to use this code, and let me know what you come up with!

If you have any questions or comments please let me know! I wrote this while also attending a conference, so if something is goofy or my sentences seem to kinda run into nowhere, please feel free to ding me and I’ll fix em right up.