Nuggets for Noppets

When I first started out with NOLOH, I had a requirement to build a fairly demanding web application. Right here and now, I have a confession to make. Currently, my NOLOH development work is my “evening job”. In my day job, I’m a .NET C# developer. I have done a lot of Rich UI development (Winforms/WPF) but in recent years, my emphasis has been more towards component and framework development for a global software development company. So, the obvious web development platform for me is ASP.NET, right? After all, I’m a .NET developer? Wrong!

I can see where MS came from with ASP.NET. It has a “forms” based approach with the ability to drop widget components onto a design surface. I suppose this was a model to allow VB and Winforms developers to use MS technologies to develop web applications. In reality, what you get is all the ASP.NET angle brackets, code-behind in the .NET language of your choice, coupled with an overarching requirement to understand CSS, Javascript, HTML, the DOM and browser quirks. Couple this with the baggage that is viewstate, there is a significant payload travelling from server to browser and back again. Oh, and did I mention those darn angle brackets!

OK, to some extent, MS have tried to make amends in recent times with their ASP.NET MVC framework but, its implementation is far less capable than RoR, and the developer is responsible for hand-cranking the HTML, CSS and Javascript/AJAX in the view layer. Either way, with the MS web-based offerings, there is no easy transition from their rich UI technology stack. You still need to understand all of the fundamental web technologies before you can build anything.

For my requirement, I originally looked at certain Javascript frameworks but I discounted them fairly quickly for numerous reasons. I actually stumbled across NOLOH after spotting a “rant” by NOLOH co-founder Asher Snyder, in the comments section of a blog post. Intrigued by the common sense and passion in Asher’s “rant”, I followed the link back to NOLOH and the rest is history.

The big difference for typical MS developers is that NOLOH is a superset of PHP and that might initially deter .NET developers from using NOLOH. In reality, for your average C# developer, object oriented PHP is very similar to creating C# based classes as PHP is a C-like language. For my money, the main and obvious differences are weak versus strong typing, the need to put a dollar ($) symbol in front of variables and a requirement to use certain functions provided by PHP that in .NET might be part of the .NET framework classes. Other than that, you can think of NOLOH as the .NET framework part of the equation.

Now for confession #2 – in the 1990’s I used MS Foxpro and Visual Foxpro extensively. I loved the fact that VFP was superb with data, fully object oriented, weakly-typed, late-bound and totally dynamic. Also, like PHP, VFP had a voluminous number of built in functions (often as a result of developer requests) making the language rich and diverse, if not a tad overwhelming by providing many different ways to achieve the same things. I really sense more similarities than differences with NOLOH/PHP and Visual Foxpro/C# .NET. With NOLOH and PHP, I have the dynamic nature and OOP capabilities of PHP, and a brilliant, “AJAX for free” OOP superset of PHP in the guise of the NOLOH framework/platform. Additionally “doing” data with NOLOH is a breeze.

So, how does this relate to .NET developers and what has all of this really got to do with ASP.NET? Well, during the day, I am squarely entrenched inside Visual Studio 2008. I have my font set to 11pt Consolas and I spend most of my time developing classes, components and frameworks extensions. When I get home, I fire up my trusty (old) G5 iMac, load the free (and excellent) Netbeans IDE and start all over again with NOLOH. What amazes me is that oftentimes, I forget that I am actually using PHP or that I am on a Mac. Everything I do is totally object based and takes the form of a NOLOH or extended NOLOH class. But I’m developing web applications, right? Correct. So what about the angle brackets? There are none. What about the Javascript? I don’t need it. What about browser quirks? I am not cognizant of them. What about AJAX or XHR? I don’t think about it. What about state? I don’t think about that either. NOLOH handles everything like this for me. All I do is create objects. I pass in arguments to constructors, or set properties on objects. I can specialise NOLOH classes by extending them or build new objects from scratch or more complex objects using aggregation. This is really obvious stuff for anyone used to OOP-based development. Some of the parameters that may be set on a NOLOH object are its display or positional attributes. For example, I might specify an object’s Top, Left, Width and Height values. I may specify its layout characteristics using a PHP constant eg:

$object->Layout = Layout::Absolute;

Most of the time, these kinds of properties are set in the class definition but clearly, they can be re-specified at design or run time.  Then, all I have to do is simply add the object to another object’s Controls collection array:

$object->Controls->Add(new MyPanel(5, 5));

The display and positional properties of the NOLOH-derived object determine how and where the object will be rendered in relation to its parent container, whether that be at the WebPage level or some more granular container lower down in the visual containership hierarchy.

All NOLOH applications are primarily housed in a WebPage object but you mostly work with Panel controls for layout and the extensive library of NOLOH controls. Most NOLOH controls are visual, whether containers of other controls or UI widgets but, there are other non-visual controls like the Container and Group classes that generally contain other visual controls but add collection based semantics, providing additional capabilities and run-time information to your NOLOH programs about the visual objects they contain.

In this somewhat brief introduction to NOLOH from a .NET developer’s perspective, we have simply referred to classes, objects, properties, collections and containers. Nowhere have we used HTML, Javascript, CSS or angle brackets. We haven’t thought about state or how we maintain it between client/server requests as this is totally automatic. This is nothing like ASP.NET but, it is very much like developing and instantiating C# classes. In my view, this is how ASP.NET really should have been.

It’s worth pointing out though that if you really want to get your hands dirty with HTML, CSS and Javascript, you are completely at liberty to do this as and when it suits the use-case (NOLOH has a brilliant class that allow you to do amazing things with HTML and I will dedicate a future post to that topic). The main point is that you don’t have to. Moreover, this means that you can use the NOLOH/PHP superset language for all of your web development whether this be for typical web site or RIA development, or sites that are a mixture of both.

After daily exposure to the MS desktop and development stack including the weighty Visual Studio environment, contrast that to my seven-year-old PowerPC iMac, Apache web server, Netbeans IDE and PostgreSQL database. It’s a lightweight (free) stack that with NOLOH, allows me to carry on developing OOP based web-applications with almost no change of development style to that utilised during my day-job.

Next time, I will tell you all about how I have just transitioned my NOLOH development and the exact same development tools over to a brand new, low-spec, “cheap and cheerful” Windows 7, Celeron-based laptop using IIS 7. NOLOH is so lightweight and powerful, it absolutely rocks, even on this budget hardware/software combination. Stay tuned!