Over the last few projects I've been doing a lot of interesting development tieing together the Typo3 CMS and RIA modules, mostly Flash but recently Ajax too.

Typo3 is a nice PHP based CMS, it has been around long enough that there isn't much direct support for RIAs or Flash but it is flexible enough that it is a good platform for custom coding them. Of course, someone might wonder why not just use a platform that does have better support for RIA development like Ruby on Rails. I think that is a good question and I have been putting a lot of time into getting familiar with tools like Rails and Flex. While apps like Basecamp or an online mail reader should be built in tailor-made platforms like that, my work has been built around existing CMS projects where using Typo3 has huge advantages. I didn't want to be running multiple environments to support different aspects of the same content, that seemed like it would be less efficient and probably lead to maintenence problems. Additionally, by keeping the services in PHP I can leverage information in the php sessions that Typo3 is already using.

For example,since Typo3 already manages user logins, I could leverage that so my Flash and/or Ajax code was aware of the typo3 login. This turned out to be fairly easy. The typo3 session is stored in a cookie called fe_typo_user.

$id = isset($_COOKIE['fe_typo_user']) ? stripslashes($_COOKIE['fe_typo_user']) : '';

will give you that value or a blank string if it is not set. This SQL will give you the uid of that user from the fe_users table.

SELECT uid FROM fe_users JOIN fe_sessions ON fe_users.uid = fe_sessions.ses_userid WHERE ses_id = '$id'

It may seem easier to just send the uid to the flash movie and let it send the uid back with whatever requests it has. The extra database hit to get the uid (or username etc) is worthwhile because the other opens you up to easy spoofing of the user. I make it a point to never send ids for tables to avoid that kind of risk.

In this case, I made a simple base class that has a getUserId method so all my classes can call it. This has worked great for both my amfphp and ajax services.

Refresh Dallas

I went to Refresh Dallas last night. "Refresh is a community of designers and developers working to refresh the creative, technical and professional aspects of newhttp://www.blogger.com/img/gl.link.gif media endeavors in the Dallas area." Last night's meeting was about Rails. Adam Keys did the presentation. He also runs the local Ruby Brigade. Since Refresh is front-end focused group, Adam focused mostly on the templating and Ajax features.

I have been going through the Agile Web Development with Rails book so I am pretty familiar with most of the ideas behind Rails but it was still good to see the templating in more detail. I am a big fan of using templating engines and have worked with a wide variety of them. I mostly work on marketing oriented sites or CMS driven sites and design control is a big deal.

Templating engines like Velocity (Java) or patTemplate(PHP) make a big deal about having no code in the templates at all and controlling the templates externally. The Rails approach uses embedded Ruby which at first concerned me. Seeing some simple layouts layered minimized some of that. Despite the embedded code, the approach seemed very readable and flexable. I could still see an advantage to moving to something a little more "pure" HTML with code controlling from the outside. An approach like Tapestry's where the markers are valid HTML seems like it would work also but could be a performance issue in a scripting language like Ruby.

The Rails approach would be very comfortable for the average PHP or .NET coder but might cause problems for the average Dreamweaver-only designer. On the other hand it's been a while since I've seen designers working directly on these kind of projects. Especially considering the Rails sweet spot is apps rather than content sites. Considered in that light, I guess the Rails templating is the "practical compromise" approach, which is pretty much what Rails is all about.

The Ajax demos were surprising to me as well. I have been doing a lot of Ajax lately but within Typo3, a PHP CMS. Since I am using OpenRico and Prototype, I really don't have to write near as much code as I would thought to create some really slick things. The Rails approach drops some of these down to one line.

I've recently started using FlashObject as my preferred Flash embedding method. For a long time I've either just used the Macromedia standard nested or used a "sniffer" swf for circumstances where I really needed to know version numbers.

I kept an eye out for alternatives and seriously looked at the Flash Satay method since it seemed to favored by many Flash experts. It was also promoted on the A List Apart site which has very high credibility. I didn't really care for it though because of the issues with streaming. Flash satay uses a small swf in an object tag that then loads the full content. This can create problems for larger flash movies where they don't play until fully loaded. A lot of my work lately involved pretty large media-centric swfs and I didn't want pay that price.

I had been skeptical of Javascript oriented methods because I used to be a lot more conservative about how much Javascript I used. But the march of progress has led to a much better browser ecosystem and combined with the Ajax stuff I've loosened up on that front.

So now we have FlashObject which hits that sweet spot of features and complexity. Flashobject works by replacing the innerHTML on a div on your page. This really fits with how I've been putting pages together lately and also allows you to have really good alternative content for situations without flash or even for search engines to index. The resulting HTML will also validate as XHTML which was always a problem with the object/embed combo.

Another advantage is the fact that this results in just one object or embed tag so you don't have problems with two things with the same name. I've recently been doing some DHTML tricks involving the flash movie and was having to either write more complicated code to figure which tag the client was using or I was having issues objects having the same name. These sound like problems that aren't too hard to work around but a lot of my work is in CMSs and I won't necessarily know which swfs are in which pages. FlashObject makes it a lot easier for me to package this functionality within my site templates.

FlashObject also supports passing parameters and variables in a nice way. Everything I've been doing lately has needed that to tie in with other CMS content. FlashObject's approach of adding them with methods really helps me keep that organized since it fits in with the templating approach much better.

One trick I'd like to try soon is to actually have the alternative content rendered in a plain html way from the CMS so that the indexing is very accurate. This will also possibly allow the site to be usable on phones, especially since I've moved to a lot more CSS driven approach. Probably won't be pretty but if you've surfed on your phone you are probably surprised when things work at all.

I found another interesting Javascript library. JQuery is a javascript library that is similar to Prototype. At first pass the most interesting feature is its support for chaining functions together like this:

$("p.surprise").addClass("ohmy").show("slow");

So like Prototype, you can grab and object with the $() function but then call the "addClass" method on that and call "show" on whatever that returns. This is more like how you would write Java or C# code and while it could turn into a visual mess it often makes things very clear.

JQuery is pretty small, only half the size of Prototype. Not that it does all of Prototype's features but if you are mainly using Prototype for features like $() then this might be a good alternative. You can use them together, but make sure you include Prototype first then JQuery.

JQuery also handles fading objects up or down. While not the full set of something like Scriptaculous or Rico, it is the probably most common effect and combined with the size savings may be worthwhile tradeoff.

I've been really conservative with Javascript in the past but have been jumping on the Ajax bandwagon and using a lot more features. My Javascript chops are still pretty good since I've been using the very similar Actionscipt in Flash. All these new libraries are making it a pleasure to execute even really complicated ideas.

Flash Forward Austin

Just heard that Flash Forward is adding an Austin show. I'm only 4 hours away in Dallas so I'm looking forward to it. The conference will be September 11-14. If you're not from Texas, it's actually very warm in September but not still in the 100s like July and August. Should be really nice and Austin is a fun town.

Dallas Ruby Brigade

I went to the first Dallas Ruby Brigade last night. I was surprised at how many people were there. I think I heard that the count was 38 which is bigger than any of the Macromedia User Group meetings were last year. I was even more more surprised at how many people were using Ruby (and not just Rails) for real world projects. It was good to see the group off to such a start though. Combined with other recent Dallas area web development community successes like Barcamp, it seems as if the Dallas scene is very healthy.

I've just been going through the Agile Web Development with Rails book, no real world use yet. I like a lot of the Rails ideas and I'm glad to see how influential it has been on other frameworks especially in regard to minimizing configuration. I do a lot of web development that is right in Rails' sweet spot so I could see using it soon.

It is nice to have everything in one place, instead of like Java where you have to decide among all the choices for similar functionality. Hibernate or ObJectRelationalBridge? Tapestry or Spring? Oh, wait! Having everything decided for me was one of the things I didn't like about .NET! I guess Rails just makes most of the decisions the same way I would have so I'm okay with it.

Microsoft would like to convince developers like me to check out ASP.NET 2.0. So they launched Microsoft® ASP.NET 2.0 Webcast Series, a set of webcasts sponsored by Microsoft, Dr. Dobb’s, and O’Reilly. They have 3 tracks; a .NET for JSP developers, .NET for PHP developers and .NET for Cold Fusion Developers.

By "developers like me" I mean people who aren't using .NET 1.x but are open-minded about it. Of course I have used .NET before. The admin and Flash remoting code for NRANews.com are in C# and I built an extranet site for Greyhound shipping in DotNetNuke, a VB.NET Portal/CMS. But I haven't used .NET for any real development for almost a year. I'm not biased against it, but most of my recent projects were better handled in Typo3 and PHP.

But anyway, I would still say I'm the target market for this site since I am very willing to leave PHP for a more robust or sophisticated environment. I routinely miss the more advanced features of Java or .NET while working in PHP, so here's MS's chance to get me to build my next project in .NET rather than Ruby on Rails or Django/Python or Java/Tapestry/JSF.

Ugh This paragraph used to be a rant about how lame it was that the webcasts were ony available live. But now I see that they ARE available on demand afterwards. The interface didn't really reflect that very well though, they just added links to the on-demand versions afterwards. I can still complain about the AI though! It was confusing! I swear!

OpenLaszlo Goes DHTML

OpenLaszlo is now targeting DHTML as well as Flash as a runtime. I think this is a very interesting development. When I first looked at Laszlo, about the time it went open-source. There was some talk about the future of laszlo being in multiple runtimes. This came up more in a demonstration at the Dallas Cold Fusion usergroup when people were asking about various Flash features not supported by Laszlo.

At the time I thought it was a little bit of a cop-out to say that Flash was just the "right now" runtime and they were trying to stay flexible enough to use others. Then I assumed the obvious alternative runtime would be Java and I didn't see much point in that since Flash was smaller and more ubiquitous. Of course, since then we've had the Ajax revolution/hype-fest.

This could be a great move by Laszlo to further differentiate themselves from Flex. I haven't looked at it yet to see what the limitations are. I would think it would be harder for them to prevent outside access by custom Javascript code like they do with Flash. I'm also not sure how this will work in regards to requiring the server-side components or in using arbitrary server-side code.

As I've posted about before, I'm currently using OpenRico for my Ajax toolset. One reason I'm using that one is the ease in connecting it to the CMS used in this project, Typo3. If Laszlo requires me to use Laszlo tools on the server and the client, that might prevent me from using it in a lot of situations. This isn't meant as a strong criticism, I recognize the value in a unified client/server approach but it can be an impediment when you don't have enough control over the server or if there are legacy issues that make adding java to the server awkward.

Now that they have taken the big step to be multi-runtime, I'd like to see them keep going with it. I think the place that would most benefit from Laszlo style development would be J2ME. This is also an area that could really leverage the dynamic runtime to actually render the app differently to support different devices abilities. Combined with the smooth xml connection between the client and runtime, Laszlo could potentially be one of the best possible platforms in what could be one of the fastest growing platforms. Many of the things that might seem limiting in Flash development would be assets in J2ME and I think their existing widget/component set would be a great fit for mobile apps.

Flash Remoting and AMFPHP

I've been a big fan of using Remoting to connect Flash to servers for a while now. A few years ago I started out using Flashorb when I was building the NRAnews.com site.

FlashOrb is an excellent product that supports Java and .NET remoting. It has since been renamed WebOrb and now supports Ajax services as well. If you've used Macromedia's .NET remoting product you'd love WebOrb. It works much more smoothly and you can skip a lot of the steps that you need with Macromedia's product. It is often possible to just create classes that can move transparently back and forth from the server to Flash without having to create helper classes like you do with the Macromedia version.

If you aren't familiar with remoting it is basically a flash specific binary version of SOAP. It is more compact than SOAP/XML and the data moves across in a native way so you can skip the XML processing on the flash side. The data just comes in ready to use.

Lately I've been doing most of my development in PHP rather than .NET or Java. Most of my current work is CMS oriented and I have been using Typo3, a PHP for a lot of that work. Rather than building the sites with multiple languages or frameworks I switched my remoting to AMFPHP an open-source PHP remoting product. It's been working great and has been fairly easy to integrate in with typo3 managed data. They recently releases a 1.2 beta that adds several new features that are really impressive. Once of the biggest is direct support for the ARP Flash Framework. The other is a new service browser that lets you test your services through simple html forms without having to build a flash app just for testing. I've had problems getting that to work but I have high hopes for it. I suspect it is a configuration issue since the services themselves work fine.

ARP is a MVC framework for remoting driven flash apps. It is a set of abstract classes that you extend to structure your flash app. The new version of amfphp actually generates a lot of the connection code for you to cut-and-paste into a flash class to connect your ARP app to remoting services. The biggest hassle with ARP is getting that all the initial code setup and this makes it incredibly easy. Like any framework, ARP seems like a lot of extra work up front but pays of huge in late development so anything to make those first steps easier is wonderful.

The ARP/AMFPHP connection is still new and in beta but I think this is a huge development that combined with the plans for ARP 3.0 will result in a Rails-like simplicity and speed of development. I'm looking forward to it!