yui

Book status report...the JS UI is alive!

Well that took a while. Back in September I opened a branch of Bookie to try to do some cool Backbone driven UI stuff. I decided that maintaining a separate mobile UI was going to kill me. So I needed something I could tweak to make mobile friendly without dual sites. Between a JS drive UI and responsive design techniques for the CSS, I should be able to make things not suck so much.

So today, the first part of that has gone live. https://bmark.us now has a UI driven by API calls through Javascript. It's using the YUI MVC stuff that's in their 3.5pr. You might have noticed that Backbone isn't in there any more. I started the app with jQuery thinking it would be a bit more friendly to outside contributions. However, after trying to put together jQuery, Backbone, HistoryJS, etc. I kind of got tired of making due and moved to YUI. It's my choice for JS frameworks and since there's not exactly a pouring of external commits, moving to YUI doesn't hurt me much.

So finally, after waaaay to many months I feel like the site is moving forward. An updated UI that needs some responsive love. An API that need some more methods, logging, etc. Phew.

There are a number of bugs and tweaks that still need working on. I'm going through them and to help be transparent I've started a public Trello board for Bookie so that everyone can see exactly what I'm in the process of, what's next on the board, etc. Hey, if you see something on the board that's on your hot button list, feel free to take it and run with it. Patches welcome :-)

CoffeeHouseCoders 11/23/11: YUI Theater group viewing

Just a heads up, this week's CoffeeHouseCoders (CHC) Detroit-ish will be a bit different. One of the goals of moving the location to the new Caribou was that we get access to the meeting room. This opens up the opportunity for us to have some group discussion and such around various topics. We're going to give that a shot this week with a group viewing of YUI Theater video viewings and JavaScript discussion.

Most of us do at least some JavaScript in our work and projects so I think it's relevant and should be fun to geek out before the holidays start up. I'll have a little projector and speaker and with the new videos from YUIConf 2011 going up, it'll be nice to set aside some time to catch up on some of the recorded presentations. Take a peek and set aside one or two "must watch" videos for Wed night! Not all of the videos are YUI specific, so it should be useful for all of us doing JavaScript.

YUI, how dare you make me rethink

So I've been spending time working on moving ahead with my project using YUI. So it's been a lot of trying to port over old jQuery code into YUI, going through docs on the various widgets and plugins, and just trying to figure out how to rearrange how I think with this stuff.

The hard part is that YUI3 enforces something we all consider good practice. Don't pollute the global namespace. What's the bad in that? Well, it presents some challenges with the way I used to do things.

[sourcecode lang="javascript"] MyApp = {};

MyApp.home_page = {

'init': function () { // do some stuff here // like load some social content or crap MyApp.home_page.bind_stuff(); },

'bind_stuff': function () { // hey, we have fancy events we bind/catch // woooo } };

// and then in the page onReady I just MyApp.home_page.init(); [/sourcecode]

So that's how I have been doing things. Parts get abstracted out, shared, but basically each page tends to have an object for each page and any extra handling of events or whatever that requires.

However, YUI3 does this cool thing that breaks that. When you use YUI3 you have a YUI().use() and everything gets encapsulated within that bit of code. So if I were to just move the MyApp code into the YUI block I'm no longer able to access it from the page of content I want to run JS on. So this is good, no JS globals, but it's bad...not the way I've been doing things.

So I've had to figure out how to adjust my old code to the new YUI3 way, and I came across this great video on structuring your code a bit better. It makes some sense, but it seemed to just scratch the surface. Unfortunately, his example is a single page application so it's a bit simpler than what I needed, but it got the point across for me.

So what's the new stuff look like? It looks like YUI3 modules

[sourcecode lang="javascript"] YUI.add('myapp', function (Y) { var MyApp,

MyApp = function (config) { MyApp.superclass.constructor.apply(this, arguments); };

/** Static **/ MyApp.NAME = 'MyApp'; MyApp.ATTRS = {

};

Y.extend(MyApp, Y.Base, { initializer : function (config) { },

destructor : function () {},

/** Public Methods **/ 'some_page': function () { var that = {};

that.init = function () { // do some stuff that.bind_stuff();

};

that.bind_stuff = function () { // and we're doing stuff };

// return the page object with all the controls/method return that;

}

});

Y.namespace('MyApp'); Y.MyApp.Window = MyApp;

}, '0.1', { requires: ['base', 'node', 'my-ui', 'yui2-datatable', 'yui2-button'] });

// and then I use it from my page with YUI({ }).use('myapp', function (Y) { win = new Y.MyApp.Window(); my_page = win.qcontent_admin() my_page.init(); });

[/sourcecode]

So this has me creating a module for my application code. It allows me to specify versions, requirements, etc. It keeps the YUI3 way of not polluting any global namespace for the application, and while a bit more verbose, seems to be working out. I like this since it's getting to what I was talking about back before when I was looking at moving to YUI from jQuery. This feels more like treating the JS code like application code.

I could split up the code into different modules based on different logical sections of the application and I might be able to reuse bits of this down the road. For instance, we use a common base bit of application code for our authentication across apps. I could break out the JS code for the auth pages into their own module, version it, and reuse it much easier.

What do you think? Am I heading in the right direction or am I just making life more complicated than it's supposed to be?

Howdy YUI, looking fine...ish

I subscribe to some RSS feeds and I've seen some cool videos/posts about YUI3 and it looked kind of interesting. I've always felt like I should be using/checking out YUI more. Everything seems very well thought out, tested, and I love that they have a whole package. Everything from DOM tools, Ajax, CSS Grids all the way to ui widgets. I've always thought they had the best autocomplete widget around from the demo. Tab should complete the current selection, it just should. So I picked up a copy of YUI2.8 Learning the Library and while it's not YUI3, it's a good view into the minds of things and how they fit together. So I decided to port over a work project I'm working on to YUI. It's kind of CMS-y so I want to setup grids just to help flexibility as things go on. (Although...I'm a grid hater for the record) I also want to take advantage of the UI collection for auto complete, progress bar, text editor, treeview and possibly datagrid.

Today was day one and so far so good. It takes a bit of work to get your head moved over from jQuery. I've been using it for a while and really the thought process in jQuery is different. Go find about any tutorial and you'll see things like:

[sourcecode lang="javascript"] // find all the instance of class="important" // and then make sure they're marked with a bolder font $('.important').css('font-weight', 'bold'); [/sourcecode]

This view is kind of against the ideas of mixing logic and template, in a way. I mean this is all view information here. Instead I think I should have things more like:

[sourcecode lang="javascript"] var highlight_important = function (identifier) { var default_id, id;

default_id = '.important';

if (identifier !== undefined) { id = identifier; } else { id = default_id; }

$(id).css('font-weight', 'bold'); }; [/sourcecode]

Now, ideally this would take more config options for just what class property to set and what value to set, all optional of course. And you have this reusable component with a sensible function name you can reuse throughout the app.

This is probably a bad example, but the point is that jQuery comes across as 'find the html and do stuff' where frameworks that come across more verbose/complex, like Dojo and YUI, seem to present things as 'write JS logic' instead.

For instance, I love the idea of the modules in YUI3. I used to just have a custom namespace object like:

[sourcecode lang="javascript"] mystuff = {

'ui': { 'zebra': function () { ... }, },

'form': { 'init': function () { ... },

} [/sourcecode]

This is fine, but I like the idea of the modules you can treat like other YUI modules. For instance my form code turns into something like:

[sourcecode lang="javascript"] YUI.add('myform', function (Y) {

Y.myform = function () { // private property to track the forms we've processed forms_formatted = {};

var that = {};

that.init = function () { Y.myform.maxlabels(); },

that.dosomething = function () { ... }

return that; }(); }, '0.0.1', { requires: ['node'] });

// and use it like var login_page = function () { YUI().use("node", "yui2-button", 'myform', function(Y) {

var Y2 = Y.YUI2;

//YUI 2 implementation code var button = new Y2.widget.Button("submit");

// init the form ui tweaks Y.myform.init(); }); }; [/sourcecode]

This also shows off how I can do things like include the YUI2 widgets.

So people are asking "Why use YUI over jQuery" and it really comes down to 'total package' with the overall completeness of things, 'well thought outness' of the library. In reading things I'm always hitting points like "man, that's a really good way to do/handle that". Finally, I want to try out and seem to like how it makes you 'think' when writing the code.

Will it stick, who knows, but I've learned enough JS to want to try out something a bit higher up. I consider it a bit like going from webob to Pylons. They're both JS underneath and all, but one includes a lot more bits than the other at the cost of some framework complexity.