Programming is a wonderful mix of art and science; source code is both a poem and a math problem. It should be as simple and elegant as it is functional and fast. This blog is about that (along with whatever else I feel like writing about).

Sunday, December 16, 2007

I Finally Discovered Flex

Just a little while ago I was considering the possibility of pre-built PHP Display Components, which would allow me to build applications faster and re-use a lot of the boilerplate code that I currently spend too much time on. And once those components are built, they could be improved individually, which would make all my applications better without having to do anything.

It seemed like a good idea, and while considering how I might go about doing it, I discovered Adobe Flex. I'd heard of it before, as "Flash for developers," but had never been that curious. Having investigated Flash before, I was not interested in having to purchase a visual development environment and then messing around with timing, tweening, layers, and all the other crap Flash puts you through.

But Flex isn't like that at all. In fact, it's essentially just a set of visual components you can use in building a visual interface, along with a slew of classes for connecting to web services and easily binding XML data to the visual components. Additionally, ActionScript appears to be what JavaScript wishes it were ... which is nice.

Best of all? They provide a free SDK with a command line compiler. So as long as you're willing to actually write the code (rather than drag-drop-connect, which seems to be the direction the IDE companies want programming to go), you don't have to pay a dime and can check Flex out. So I did.

I decided to write a quick program to calculate quarterback ratings. Since the ratings formulae are different in the NFL and in college, I figured I'd have it calculate both.

Here are links to the app and the source code.

The first thing I did here was set up the visual interface, which is at the bottom. I used Flex's Label, TextInput, and Button components to build a simple form. I used absolute positioning because it's supposed to be better for performance (and because all the examples on Adobe's site use it, which means I haven't learned much about their automatic layouts yet -- I certainly would like to).

These components should be pretty familiar to anyone who's used HTML and Swing ... the tags seem to be a mix between the two, which is pretty interesting.

After writing the interface (and compiling and testing it to make sure it looked the way I wanted it to), it's time to add the functionality itself. The calculations will be done by ActionScript, in the <mx:Script> tag. It's a lot like JavaScript, except that you can define strong types and public/protected/private status, both of which are nice additions. The functions in here are simply designed to pull the data from the input fields, convert to Numbers, apply the formula, and set the label.

The one slightly non-basic feature I used in this program is NumberFormatter. Flex claims you can instantiate any component either with tags or in the script code, but the only way I got this working was to make an <mx:NumberFormatter> tag and reference it from the script. It's actually pretty interesting, and once I get used to having to do that, I may grow to like it.

I then went ahead and compiled it, and it worked quite nicely. Flex looks like a promising way to build web applications -- it's even possible that I could grow to prefer it to PHP + AJAX for my own applications.

Saturday, December 08, 2007

PHP Display Components

Just about every GUI language/framework has standard classes for displaying common datatypes. There are datagrids, sortable datagrids, paginated lists, searchable lists, input forms, display forms, etc. You instantiate them, set up some information about them, and connect them to your data source. Then you call some sort of display() method on the object, and it displays everything on the screen.

The reason I mention this is because PHP has nothing like this (at least not that I know about). In PHP, the View part of MVC is merely an HTML-based layout file with some markup in it to display your data. But isn't is possibly to create a set of components that generate the HTML on their own?

Obviously, we could all just continue to code the HTML in our Smarty templates, recreating the same functionality over and over again in "low level" HTML. On the other hand, we could create components at a higher level of abstraction, and when we figure out a better/cooler way to do that searchable+paginated list (maybe adding some Javascript), we do it once -- in the component -- and it works everywhere we're using it. That's much better than having to change HTML code everywhere we're displaying a list of data (um, a lot).

So what are the goals of these display components?
  • Define a set of reusable components that handle the display of data on a web page and generate the HTML
  • Concentrate the HTML/JS of your application in component code, out of sight
  • Ability to easily create new components, or edit existing ones as needs arise
  • Skinnable -- either set CSS values in the code, or assign a CSS file to the object (also allow for a default CSS file to be set sitewide)
  • Allow you to stay at a higher level of abstraction, so you can get more done with less code
These seem like reasonable goals. They're not trying to shoot the moon ... and they don't seem to demand that you develop a certain type of application if you use these components. However, the problem of defining what components are necessary then quickly arises.
  • Lists of data
    • Paginated
    • Searchable
    • Sortable
  • Header
  • Footer
  • Sidebar
  • Input form
  • Display form
  • Calendar
  • Date selector
    • Single date
    • Date range
  • Time selector
    • Single time
    • Time range
  • Popup dialogs
    • Modal
    • Non-modal
  • AJAX
    • Periodical updating
    • Response to user action
    • Connect a URL-defined data source to a component
That's a start, anyhow. More components are probably necessary.

There should probably be a general Page class, or something, that you would attach the other components to. The point of that would be to set pagewide CSS and only being required to call the display() method once per page.

In the interest of separating this from the concept of "scaffolds," I think the way it should work is that each component has a standard/default HTML template that it draws from, and the file it uses is an object variable. If you want, you should be able to create a brand new HTML template and make your component use it instead -- it would be nice to have that kind of flexibility.

Right now ... I don't know if this is feasible. I don't even know if it's a good idea. I'm sure people have tried to do this before, and I've never heard of the results. At the moment, my plan is to think about it for a while longer, and if I continue to think it's a good idea, it may be worth spending a bunch of time on to see what I can come up with. Could be interesting. (Let me know your thoughts, if you have any.)

The First Week -- Mostly Waiting

I just finished my first week on the job. I don't know how typical an experience it was, but I'll run down a quick overview of how it went for me.

It was "Team Week," which means that everyone who works in offices around the country all get together in Chicago for a week of project planning (during the day) and partying (at night). As a general rule I would have jumped on the partying train after work, but I'm adapting to a new lifestyle -- one that involves waking up early and commuting to work -- and have been pretty tired. I don't want to throw a hangover on top of that process. It's already hard enough to prevent myself from drinking coffee.

I really like the team I'm working with, so it's a bit of a shame that they've now all gone back to their respective homes and we'll have to work remotely. But they've been successfully doing it for a while, so I'll just have to slide right in and contribute.

And on that note, I was completely unable to "slide right in." I expected it to take a day, maybe a day and a half, before everything was set up and I would be working. Alas, no. There were numerous problems with waiting for IT, and one entire day was lost because the one guy who knew what we needed to take a step forward missed a day (spent it with his son in the ER -- apparently everything's okay now). I spent most of the week reading source code, but with no access to the repository or a development server, nor any direction on what to do. Finally, on Thursday, I was assigned projects, and on Friday, I was told what they actually want. But I'm still waiting on CVS access.

In my first week on the job, the vast majority of my time was spent on non-work tasks. I don't think that's very unusual, but it feels weird to have to "wait" like that after you've started the job. From the reactions of the rest of the team, they seemed to expect that it would take 2-3 days. By the end of the week they were getting as frustrated as I was that I still couldn't work.

Hopefully everything gets set up quickly, and next week goes a bit better.