This Blog

Home
Contact

Syndication

Not Necessarily Dot Net

Real World Dojo part One: Form Validation

Real World Dojo, part One (Basic Validation)

The Scenario:

I’ve kind of been nibbling around the edges of Dojo for a while, but I’m at a place in this project where I really need to buckle down and learn it. Since I’m having so much trouble finding real-life examples of the basics, I figured I’d share what I’m coming across.

I have a very simple proof-of-concept form that shows the basics of the one that forced me to buckle down. It looks like this:

<head>
	<title>Validation Test (raw HTML)</title>
</head>
<body>
	<form action="/beta/test/client_validated" method="POST">
		Name: lt;input type="textbox" name="Name" /><br />
		URL: <input type="textbox" name="Url" /><br />
		File: <input type="file" name="File" /><br />
		<input type="Submit" value="OK" />
	</form>
</body>
</html>

(For now, the server action just verifies that the Name and URL fields have values).

In the real-world example, there’s a required field that’s very easy to forget. And it’s easy to forget that the database is picky about URL’s.

If this were an ASP.NET application, I’d just toss in a couple of validators and move on. That isn’t an option for the platform we’re using, so here we go.

Switch to Dojo Fields

My first stab was just blindly following the tutorials I could find, adding in the Dojo infrastructure and marking a couple of fields as required:

<html>
<head>
	<title>Validation Test (switch to Dojo)</title>

	<link id="themeStyles" rel="stylesheet" 
 href="http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dijit/themes/tundra/tundra.css">

	<script type="text/javascript" 
 src="http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dojo/dojo.xd.js"
	djConfig="parseOnLoad: true, isDebug: true"></script>

	<script type="text/javascript">
		dojo.require("dijit.form.ValidationTextBox");
	</script>
</head>
<body>
	<form action="/beta/test/client_validated" method="POST">
		Name: <input dojoType="dijit.form.TextBox" type="textbox" name="Name" 
		required="true" trim="true" intermediateChanges="true" /><br />

		URL: <input dojoType="dijit.form.ValidationTextBox" type="textbox" 
		dojo.regExpGen="dojox.regexp.url" required="true" name="Url" /><br
		/>

		File: <input type="file" name="File" />

		<input type="Submit" value="OK" />
	</form>
</body>
</html>

Switch to Dojo Form

Sadly, it wasn’t that simple, so I took the next step and switched everything except the file element to a Dojo widget (a.k.a. dijit):

<html>
<head>
	<title>Validation Test</title>

	<link id="themeStyles" rel="stylesheet" 
 href="http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dijit/themes/tundra/tundra.css">

	<script type="text/javascript" 
 src="http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dojo/dojo.xd.js"
	djConfig="parseOnLoad: true, isDebug: true"></script>

	<script type="text/javascript">
		dojo.require("dijit.form.ValidationTextBox");
		dojo.require("dijit.form.Form");
		dojo.require("dijit.form.Button");
	</script>
</head>
<body class="tundra">
	<form action="/beta/test/client_validated" method="POST"
	id="TheTest" encType="multipart/form-data" dojoType="dijit.form.Form"
	validate();" onReset="return false;">
		Name: <input dojoType="dijit.form.ValidationTextBox" type="textbox" 
		name="Name" required="true" trim="true" intermediateChanges="true" /><br />

		URL: <input dojoType="dijit.form.ValidationTextBox" type="textbox" 
		dojo.regExpGen="dojox.regexp.url" required="true" name="Url" /><br />

		File: <input type="file" name="File" /><br />

		<button dojoType="dijit.form.Button">OK
			<script type="dojo/method" event="onClick">
				console.dir(dijit.byId("TheTest").attr('value'));
			</script>
			<script type="dojo/method" event="startup">
				var form = dijit.byId("TheTest");
				// set initial state
				this.attr("disabled", !form.isValid());
				this.connect(form, "onValidStateChange", function(state){
					this.attr("disabled", !state);
				});
			</script>
		</button>
		<button dojoType="dijit.form.Button" type="reset">Reset</button>
	</form>
</body>
</html>

I snagged the actual validation pieces from Dojo’s online unit test suite (non-automated). The important pieces were at Dojo Test Form Validation State. That portion of their website is one of the best resources I’ve found as far as seeing how to actually do something. (If all else fails, read the source code...Dojo’s source code is extremely well-written and -commented, but it’s lacking when it comes to usage examples).

The URL regular expression validator isn’t working correctly (it’s accepting anything I input), and the Reset button doesn’t do anything. But it’s getting closer.

Change the Reset button’s declaration to:

<button dojoType="dijit.form.Button" type="reset">Reset
	<script type="dojo/method" event="onClick">
		dojo.byId("Name").value="";
		dojo.byId("Url").value=""; 
		dijit.byId("Submit").attr("disabled", true);
	</script>
</button>

(I don’t know why that didn’t work automatically...I’m probably declaring the button wrong) and the regular expression part of the URL input to

[http|https|ftp]://[A-Za-z0-9-_]+\\.[A-Za-z0-9-_%&\?\/.=]+

(dojox.regexp.Url is in the development trunk, but it didn’t make it into 1.2.0 apparently), and we have something. (Yes, that regexp is pretty weak. But it’s good enough for what I’m doing).

The final version looks like:

<html>
<head>
    <title>Validation Test</title>

    <link id="themeStyles" rel="stylesheet" 
    href="http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dijit/themes/tundra/tundra.css">

    <script type="text/javascript" 
    src="http://ajax.googleapis.com/ajax/libs/dojo/1.2.0/dojo/dojo.xd.js"
    djConfig="parseOnLoad: true, isDebug: true"></script>
    <script type="text/javascript">
        dojo.require("dijit.form.ValidationTextBox");
        dojo.require("dijit.form.Form");
        dojo.require("dijit.form.Button");
    </script>
</head>
<body class="tundra">
    <form action="/beta/test/client_validated" method="POST"
    id="TheTest" encType="multipart/form-data" dojoType="dijit.form.Form"
    validate();" onReset="return false;">
        Name: <input dojoType="dijit.form.ValidationTextBox" type="textbox" 
        name="Name" id="Name" required="true" trim="true" 
        intermediateChanges="true" /><br />

        URL: <input dojoType="dijit.form.ValidationTextBox" type="textbox" 
        regExp="(https?|ftp)://[A-Za-z0-9-_]+\.[A-Za-z0-9-_%&\?\/\.=]+"
        required="true" name="Url" id="Url" /><br />

        File: <input type="file" name="File" /><br />

        <button id="Submit" dojoType="dijit.form.Button">OK
            <script type="dojo/method" event="onClick">
                console.dir(dijit.byId("TheTest").attr('value'));
            </script>
            <script type="dojo/method" event="startup">
                var form = dijit.byId("TheTest");
                // set initial state
                this.attr("disabled", !form.isValid());
                this.connect(form, "onValidStateChange", function(state){
                    this.attr("disabled", !state);
                });
            </script>
        </button>
        <button dojoType="dijit.form.Button" type="reset">Reset
            <script type="dojo/method" event="onClick">
                dojo.byId("Name").value="";
                dojo.byId("Url").value=""; 
                dijit.byId("Submit").attr("disabled", true);
            </script>
        </button>
    </form>
</body>
</html>

I’m tempted to take out the intermediate steps, so this isn’t so
long. But I think they might be useful to anyone who was having the same
problems I did.

Of course, this form doesn’t actually do anything. I’ll save that for next time...this bad boy’s too long as it is.

Posted Oct 14 2008, 05:18 PM by JamesAshley with 2 comment(s)

Filed under: coding, Not Dot Net, open source, javascript

Manipulating the DOM with Dojo

This is the area where jQuery rules the roost. Or so everything I've read tells me. So, how does Dojo stack up?

Still running this in parallel with Kyle's series:

Setting the contents of an element

// Convenience function to hide query details
var element = dojo.byId('whatever');
element.innerHTML = "Change to this";

Or you could chain it jQuery style:

dojo.byId('whatever').innerHTML = "Change to this";

Really just a matter of personal preference and what you find more readable.

Adding a new html element

var l = dojo.byId("list");
var li = document.createElement("li");
li.innerHTML="Three";
l.appendChild(li);

Removing content

li = dojo.byId("garbage");
dojo._destroyElement(li);

Setting css properties (actually, there are a ton of helper functions for setting individual styles, but here's the generic case):
```
node = dojo.byId("whatever");  // or use dojo.query
dojo.style(node, "color", "salmon");
```
Iterating over the matched set
When you use a dojo query (using CSS3 selectors), you can manipulate all the results automatically:
```
l = dojo.query("li");
l.style("border", "medium double black");
```

jQuery wins this one hands down. But you probably wouldn't be doing much of this sort of thing with dojo anyway. You'd be too busy working with higher level abstractions.

Posted Oct 08 2008, 07:46 AM by JamesAshley with no comments

Filed under: Not Dot Net, open source, AJAX

Selectors in Dojo

Selecting elements in dojo is really a very tiny piece of what it does. It uses CSS 3 selectors. If you haven't looked into them, check out CSS 3 selectors explained. It's a little disheartening, because IE still doesn't support most of these features (the IE 8 beta seems to have limited and buggy CSS 2.1 support), but dojo does.

Actually, anything I write about dojo selectors would be redundant. Glance over the list at Dojo Selectors to get an idea of just how flexible and powerful this approach is. Some of the comments on the page tell you that it definitely isn't 100%, but it's still pretty impressive.

Just to stay parallel with Kyle's post, though, here are a couple of examples:

// Set the text color of the element with an id of "one" to blue:
var one = dojo.query("#one");
one.style("color", "blue");

// Give all div elements with class foo a red background
var foo = dojo.query("div.a");
foo.style("backgroundColor", "red");

/* Take everything that has an attribute custom with a value of whosit and give it a border:*/
custom = dojo.query("*[custom='whosit']");
custom.style("border", "medium double black");

There really isn't much significant difference between dojo and jquery on this front, except that jquery uses its magic $ function, and dojo loops through selected elements automatically, when you're using it this way.

Edit: It strikes me as a little ironic that I decided to write this just now, because I just found out that dojo released version 1.2 today.

Posted Oct 06 2008, 03:09 PM by JamesAshley with no comments

Filed under: Not Dot Net, javascript

VB.NET vs C#

If you're familiar with a wide variety of programming languages/environments, C# and vb.net look like pretty much the same language. C# looks a little lower level, a little grittier, because it uses brackets instead of begin/end (or whatever vb.net uses). It does tend to get new language features first, while the vb.net team seems to focus on extra, friendlier libraries (which you can then turn around and use in C#, AFAICT). Big whoopty deal.

For that matter, Java is pretty much the same language, too. (I know, saying that's just begging for flames).

Far more important than minor syntactical differences is the .net runtime which they share. You used to be able to get a job as a programmer by learning some given language (or even just parts, if the language is as big and scary as, say, C++). Now, in an asp.net shop, you really need to understand things like HTTP, SQL, COM, asp.net's page life cycle, SEO, HTML, javascript, Active Directory, TCP/IP, MSMQ, SOAP web services, XSLT, some complicated CMS...the list just goes on and on. Plus you need a solid grasp on the .net framework library, and I don't think I know anyone who can claim to be an expert on that monster.

Most programmers will learn the pieces of that they need to use every day, and look up the rest as needed. (OK, tony can probably tell you off the top of his head that there's an abstract LicenseProvider class in the System.ComponentModel namespace, and here's how you use it, but most mere mortals have probably never even heard of it...I hadn't, until I googled for something obscure just now to use as an example).

This is why projects like Iron Ruby, Iron Python, and F# are so exciting. They're bringing higher level languages to the table, *with* that massive class framework. But that's a different post, that I've probably already written.

The real distinction between vb.net and c# is the programmers who choose one over the other, the teams they build, and the architectural mind-set they tend to have.

C# programmers are mostly coming from the C/C++/Java world. They tend to architect heavily up front, be really anal about the way their code looks, and think about things like design patterns, loose coupling, code optimization, and maintainability. They also have tendencies toward elitism and snobbery (though nowhere near as bad as the common lisp fanatics).

VB.NET programmers tend to come from (surprise!) the VB world. Or they're newcomers who get intimidated by the way C# looks. They tend to be more of the "get 'er dun" school of thought. They're usually too busy actually writing/testing/debugging code to, say, make sure that all the equal signs in a block of assignments line up nicely.

There's nothing wrong with either approach/mindset. It just depends on your customer's needs at the time. Someone who can switch gears from one approach to the other, as needed, can be an invaluable asset to your team.

Like all generalizations, there are always exceptions. I've known C# guys who came from a C background who believe copy/paste is the best kind of code re-use, because they thing inheritance is confusing. I've known programmers who prefer VB.NET because they just think brackets are ugly, but they're still doing solid enterprise-level software, dealing with COBOL back-ends and programming in assembly language for some of the embedded front-end stuff.

A programming language is a tool. Microsoft has really upped the ante with .net, creating an entire platform. If you're willing to tie yourself to them (and it's a safe bet that windows will be around for a long time), you have an amazing amount of power at your fingertips. If you choose VB.NET, you might be missing out on some of C#'s whiz-bang syntactic sugar (it's been a while since I actually looked. I'm pretty sure VB.NET supports generics now. Does anyone know how its LINQ support stacks up?), but that isn't going to keep anyone from doing amazing things with it.

All programming languages/platforms have their warts. Except maybe scheme (unless you're Larry Wall <G>), and its standard library is so tiny that I just can't find a practical use for it. But every time I check out the different implementations, it gets more attractive.

Who's the real winner? The programmers who work in shops where they actually let you pick and choose the right programming language/platform for a given job.

Who's the loser? The guys who have to keep up and deal with all these different platforms.

Posted Aug 03 2008, 02:07 PM by JamesAshley with 1 comment(s)

Filed under: best practices, coding, theory, newb, VB

Net Neutrality

Net Neutrality advocates tell us that, if ISPs are allowed to pick and choose what kind of bandwidth they throttle the most, they'll, of course, discriminate against their competitors. Being the giant, evil, corrupt corporations they are (this is Microsoft and Google talking, BTW), they can't be trusted to play fair. They've already proven this by discriminating against people using P2P services.

The ISPs in question answer that those are evil people who are illegally sharing copyrighted music (every one of them), so who cares? Besides, if they didn't discriminate against those pirates, you'd never get your email. So they need to set up a special premium service where they can sell you enough bandwidth to actually watch high-quality video over the 'Net. Video that they'll sell, of course.

The problem with this particular smoke-and-mirrors round of this fight is that anyone with some sort of broad-band is already paying for premium service.

The problem with their new "super broad-band" level of service is that their infrastructure can't support the bandwidth they've already sold.

They've built their infrastructure on a sharing model. Take 1 pipe, that can handle 1,000 thingies (whatever a "thingie" is) a day, and hook it up to 4 different houses. Tell each home-owner that I'll let them use 1,000 thingies a day. It works, because Milton works from home during the day, then turns his computer off, Mildred uses her computer in the evenings after work, Martha always works late and uses it late at night, and Michael wakes up early in the morning and uses it before work.

That is, it works until Michael (the evil fiend) starts sharing his home movies on some P2P network. Now he's connected and using bandwidth (that he's already paying for) all day long. This interferes with Mildred, Martha, and Milton.

A big part of the fight is about the "last mile": where the lines snake out from the telephone poles and go to your house. That seems to be where "the pipes" get clogged up. Even if you have a ton of other companies push into the picture and add more options there, you'll still have congestion where all of their "pipes" meet to connect with...whoever their ISP is. Ultimately, everything's running through huge "back-bone" lines, most of which are owned by either AT&T, Verizon, Sprint, or a company named Level 3.

We probably don't have to worry too much about them throttling down on your music sharing so the cable companies can sell their customers smoother video. But do you want to bet that they won't take the money, if the cable companies offer?

Here's the flip side of the coin: ISPs can charge (for example) YouTube a premium, to let their videos stream faster and more smoothly. Their competitors (do they have any?) can't afford to pay that premium. They go out of business.

To a web company, the internet is basically just a public utility. If that company uses more bandwidth, it also pays a premium already. If a company bases its business model upon a particular technology, and then ISPs start penalizing that technology (because they weren't foresighted enough to realize that, someday, people would be presumptuous enough to actually expect to use the premium bandwidth they were paying for), it can destroy that business.

That is the situation, as I understand it. ISPs want to charge a premium for something we're already paying for. Google and Microsoft want the government to add new, unworkable regulations that will almost certainly be obsolete before the ink finishes drying.

Posted Jul 21 2008, 04:20 PM by JamesAshley with no comments

Filed under: theory, Not Dot Net, Completely Off Topic

Some Open Source Ajax Frameworks

Introduction

I've finally had a chance to look at AJAX again. Step one (for me) was to do some research into the different frameworks. The project this is for has nothing to do with .NET, so I still haven't had a chance to look at ASP.NET AJAX. (Well, nothing worth talking about. I helped a coworker do some debugging once, when it was in beta).

I have even less experience with most of these other frameworks. Still, maybe the research I've done so far will help someone else skip over the first steps that I took.

The first thing I found is that the vast majority of articles along these lines are ancient history, but you have to actually dig through the article to find any dates or version numbers. I did this research on Prototype/Scriptaculous 1.6, jQuery 1.2.6, Dojo 1.1.1, and MooTools 1.2.

Market Share

According to jQuery's author/owner, this breaks down as follows (not sure when he gave the presentation these numbers came from):

Prototype: 35%
jQuery: 25%
Dojo: 20%
MooTools: not mentioned (don't blame the messenger)

The Basics

Prototype

Prototype's been around quite a while. A lot of people have been hammering on it a long time. It's solid and reliable. Apparently they've put a lot of effort into bringing JavaScript's object-oriented abilities more in line with what Java/C# people think of as "object-oriented." It's also fairly minimalistic.

I used Prototype a little on a Ruby on Rails project. Its seamless integration there makes it pretty much a no-brainer in that environment.

jQuery

Even if it's not as popular as Prototype, it has a huge fan-base. I see more books and articles about jQuery than probably every other javascript library combined. As far as I can tell, its feature set is very similar to Prototype's.

Its basic design approach seems to be the exact opposite: base everything around this magic global $ function. I have friends who are big fans, mainly because it's just dead-simple easy, but the $ reminds me of Perl. (Not to say anything bad about Perl...I know it's a wonderfully good and powerful language, and a lot of people have done a lot of amazing things with it).

Looking at all the samples of what people have done with it, it's obvious that you can do some really impressive things with it.

Dojo

This bills itself as a full-stack framework. They organize things into several different namespaces, and the basic API is dead simple. It comes out of the box with most of the bells and whistles anyone will ever need. I've read complaints about the friendliness of the user community. A commenter in one blog post said that "Dojo's just insane," but he didn't elaborate. (Sorry, I've lost the link back to that article).

One of its more attractive features (that I've seen so far) is a "toolkit builder." Basically, you pre-process a few files, and they spit out one single file that contains only the pieces that your app actually needs. Or you can point to a file that contains everything, served up by AOL. This is extremely important when you're on a platform like Google App Engine, where you're limited to 1000 files and blob entries in the database. (This limitation will go away when they let people start paying).

MooTools

MooTools is a minimalist, heavily object-oriented library. It has very dedicated fans. That's really all I know about it. By the time I discovered it, I'd learned that it wasn't what I'm looking for right now. When I'm working on a project where I'm going to be doing a lot of pieces that are radically different than what everyone else is using, I'll take a much longer, deeper look.

I mainly mentioned it because I didn't want the fans to flame me in the comments because I left it out. ;-)

My Thoughts

This is where things pretty much get totally subjective and based on current project needs.

Prototype

It's hard to turn your back on market share this big. You know it's solid, and it will be here tomorrow. It just never seemed like the right fit for this project. Making engineering decisions based on gut reactions isn't exactly an industry best-practice. But, when you have to make a decision now and get busy writing code, you have to rely on experience and instinct.

jQuery

jQuery has what could be a vital feature that none of the others seems to: it makes it incredibly to modify the DOM. The others let you modify a node's attributes or swap out its contents, but jQuery seems to let you make that sucker tango. Adding items to a list was one of the examples I ran across.

If it's hard to say "No" to the market leader, it's even harder to turn down the #2 guy.

Dojo

But Dojo comes with pretty much every visual effect I'm likely to need. Check out the Dojo Feature Explorer. Not all the demos work in all browsers...that's why they've broken those pieces into a package that they've explicitly marked as "experimental."

MooTools

Any library whose fans love it this much is worth paying attention to.

Wrapping Up (I know...finally!)

All these toolkits are great. They make the basic AJAX thing simple and easy. I spent a lot of time torn between jQuery and Dojo. I've been digging through Dojo's manual, trying to learn enough about it to make an educated decision. I've also been trying to dig through jQuery's documentation.

Every time I start, I get a "Man, this is ugly," reaction, and I find something else to do instead.

And that's my answer. If I hate the way code looks, I'm not going to enjoy working with it. It may be the greatest tool since the bread slicer, but if there's something inside me that doesn't enjoy using it, then I won't use it as effectively as something less powerful that I enjoy.

Besides, Dojo comes with pretty much everything I need built in.

All frameworks have warts. All abstractions leak. When you're learning a new programming language because it's a way to expand your horizons and view of the world, pick the one that strikes you as the most worthwhile (or that someone you respect/admire recommends). When you get through, there will be parts of it that you hate.

When you're picking out a new framework to learn, because you need it for a tight deadline, sometimes you have to go with your gut.

At least, that's what my gut's telling me right now. We'll find out later whether it was right.

I fully expect that there will be a few places where I'll need jQuery's DOM-manipulation abilities. And I'll use it then. Other than that, I'm predicting MooTools and Dojo in my future.

Posted Jul 19 2008, 05:17 PM by JamesAshley with no comments

Filed under: Not Dot Net, AJAX

Linq to SQL Designer Weirdness

The Linq to SQL designer that's built into Visual Studio 2008 is pretty, and a huge improvement over what Microsoft's provided before, in terms of data modelling. I haven't used enough other OR/M's to really have an opinion about how it measures up to other products.

But it does have its issues. For one thing, it seems to magically cache its schema somewhere internal. So you better have your database design pretty much set in stone before you start actually doing any data access. (Yes, I know. Have your product designed before you start writing code. For some small projects, especially when the real point to them is to learn a new technology, design-as-you-go and incremental development have their place).

But that isn't the point. If you change (by this I mean add/remove columns) your database schema after you do the drag-and-drop thing to have the designer generate the data access layer code for you, the only way I've found to get that data access code to match your changes is to update the generated code by hand.

This, of course, is a Bad Thing (TM), Should Be Avoided At All Costs, and is a general pain in the ass. But even deleting the table from the designer, rebooting, and re-adding it didn't work for me. (I didn't go so far as to delete the DBML file, because I've spent several hours tweaking it...maybe that would work).

Actually, tweaking the dbml by hand isn't that big a deal. Just tedious, because you have to change several things in several different places, and the compiler errors are useless if you forgot to dot a t or cross an i. But the designer has an annoying tendency to want to overwrite your changes, so use caution. (It's so much easier to not actually look at your changes with TFS...)

Sometimes, though, even that isn't enough. I realized at one point yesterday that a bigint field in the database really should be an int, to match up to where that field connects to everything else. So I changed it, then dutifully changed the matching dbml.

Then general distractions slipped in. By the time I got done juggling and back to testing that change, I'd really forgotten about it. And got a "Specified cast is not valid" SystemException (not an InvalidCastException as I'd expect) every time I tried to query that table.

I verified the data types of all the columns (especially the bigint vs. int). Did everything I could think of to get it to regenerate it with the correct column types. Finally, out of desperation, I switched the column specifications in the dbml (OK, you can do this with the designer) back to long/bigint.

And it started working again. I think this is the first "just let VS 2008 magic, even though it's blatantly wrong" thing I've run across, but I really haven't had a chance to hit it hard yet.

If anyone has any work-arounds to add/remove columns (maybe there's something obvious hidden in a context menu that I'm just missing?) I'd love to hear about it.

Posted Jun 24 2008, 10:01 AM by JamesAshley with 1 comment(s)

Filed under: coding, newb, Linq, code generation

Linq to SQL with multiple databases

I think I've mentioned that I'm working on a project that dips its fingers into databases all over the place. Its main goal is to eliminate all the systems we have around that are also doing this. If it has to be done at all (and, really, it does), it should only happen once.

One of the biggest issues I've run across while doing this is that Linq to SQL just does not play nice with multiple data contexts.

If you're working with 3 different databases, that's 3 different connections. Linq to SQL will not let you do any joining etc.

You can't pull the results of one query into memory and then join against that (well, you can in some really isolated circumstances, but it's mostly a crap shoot).

The only Linq to SQL solution I've found so far is to run a query on the first database, do a foreach over it, and query the second database multiple times. This, of course, is usually brutally slow.

I worked out a compromise with our DBA. He added something he calls variously "data links" or "linked servers" or "server mappings" to the central database I need. They now show up as read-only tables there.

Performance is still spotty, and I'm not sure it's even vaguely something that could be considered a best practice. I suspect it's some sort of gaping security risk. But apparently that's the way they've been doing business for years: "Need data from our database? Here, let me set up the views we'll let you see in your database."

If I cared more about dba stuff, I'd look up what was actually done, give technical details and analysis, list pros and cons, etc.

But, if your organization's anything like the one where I work, where security's a combination of swiss cheese and flaming hoops, you're trying to work with multiple teams who all have their own opinions and philosophies (and no one's willing to concede that they're all pretty much equally valid), and you're supporting a wide range of technologies, sometimes just finding a solution that works is enough.

Posted Jun 18 2008, 03:49 PM by JamesAshley with no comments

Filed under: best practices, coding, theory, Linq, database

Some Initial Thoughts on Google App Engine

More like observations, really. There's nothing here that's new or interesting, if you've been following it at all. But, if you've been mildly curious and haven't taken the time to really read anything at all, this may be worth your time.

I was really excited about the app engine beta. But that's mainly because I like messing around with new tools and technologies. And, unlike a lot of people I know, I consider it valuable to branch out into areas which most likely won't lead directly to a pay increase. Call it personal development or stupid hippy nonsense, depending on your personal preference.

Anyway, I've been playing around with the app engine for a couple of weeks now. Nothing serious or meaningful; really just trying to get my head around some of the differences. So a little toy apps (I still think of them as homework assignments) here or there to try out some concept, trying to keep up with the mailing list, that sort of thing.

Anyway, here are some random thoughts so far:

Python's still an incredibly fun and easy language. No, it isn't as powerful as ruby. But it's so much more intuitive that it's just silly. I thought I was just biased, but a couple of friends who have tried both agree. For you die-hard .NET fans, I highly recommend checking out Iron Python. Being able to open up an interactive interpreter and dink around with various classes is a great way to learn how to use those classes. (Or, for that matter, just to observe what they're doing and why something breaks. It's a lot faster for me than using a debugger).

App engine is still definitely in beta. There are some huge bugs on the bug list. But they're also cleaning bugs and adding features at an astonishing rate.

Some of the basics they left out will be deal-breakers for a lot of people, if alternatives don't appear quickly. One that I keep running across on the mailing list is the lack of XML support. I'm really shocked this hasn't been fixed. I think XML's way over-used, but it definitely feels an important niche.

The data model seems to be a huge learning curve for anyone who's ever done any database design/theory. For one thing, writes and joins seem to be ridiculously expensive. The "best practice" that I've seen most often seems to be "run one query, against one table, for each request. At the most." Since I tend to try to normalize everything, unless there's a reason not to, that's a little difficult to accept, deep-down.

They aren't really targeting the enterprise. Which is kind of ironic, since one of the biggest saling points (in my mind) is scalability. I suspect they're getting a solid basis with individual developers.

Have I mentioned the scalability? What they've given independent developers just blows my mind. You accept the limitations of their sandbox, and your app runs on their server cloud. I can't think of anyone besides amazon who's even close to that league. And, with their EC2 offering, you have to waste time setting up and configuring the server.

With google's offering, you run a little command-line app, it uploads, and possibly re-indexes (when that happens seems to be a little fuzzy, and it can be *brutally* slow...like I said, definitely beta) your database. You start getting tons of hits in Australia, they load your app onto servers down under and process requests there.

Anyway, it's a nice change of pace from SQL and C#.

EDIT:

Oh, yeah. The whole reason I started this post. With the latest SDK release, they've added a bunch of image processing functions. These seem to be based on the Python Imaging Library, because the local server complained about that being missing when I started it the first time. That was the only place I've seen this mentioned. I'm familiar with it from way back, but I thought this little hint might help some of the newer people who seem to be drifting in from PHP. So, if you get that error and the Image API doesn't work, go to that link, install the library, restart the GAE server, and you should be good to go.

Posted Jun 05 2008, 08:19 PM by JamesAshley with no comments

Filed under: Not Dot Net, python, open source

First Impressions of Web2py

It kicks ass.

There's a video that demonstrates web2py and Google appengine that pretty much says it all. If you're like me, and you'd rather read a set of step-by-step instructions than watch a video, this is for you. (OK, this is actually for me when I start a new project 6 months down the road and have forgotten how to do this stuff).

Go to the Google SDK Download page. Get the Linux/Other Platforms one. Doesn't matter what platform you're actually running. I've seen weird stuff happen with the Windows installer. Unzip it wherever you feel like. (If you're a python geek, feel free to put it in you PYTHONPATH. If not, it really doesn't matter). Just somewhere that's convenient for you.

Download web2py. I recommend the source code version, because it gives you more flexibility about where to put stuff. But whatever floats your boat.

After you've extracted/installed web2py, run it. If you're on windows, it's web2py.exe. If you're on linux, the command is "python web2py.py". It opens a server controller dialog.

Enter an admin password. Doesn't matter what it is. But, if you don't enter it, you won't be able to get to the admin control panel. Click the "Start Server" button.

It should open up a browser window that is looking at its home page. There's a link to the admin interface (if you gave it an admin password) and another to a set of examples.

Go to the admin page. Build your app there. (This is the fun part...seriously, check out that video). There are some limitations about what you can do with the models. These are actually due to limitations in appengine. Don't try to get too fancy, and you should be fine.

When you're ready to move forward, update your models. If you've been sticking to the default sqlite (and I can't think of any reason to change), comment out the first line that imports that. Replace it with

from gluon.contrib.gql import GQLDB
db = GQLDB()

Stop and close the web2py server.

There's an app.yaml file in the root of the web2py distribution. Update it to reflect your application's name.

Open a command prompt in the folder that contains your web2py directory. Start the appengine server with python dev_appserver.py [web2py directory]

Test your app! (I know that seems like a no-brainer, but some people...)

Update the version in app.yaml, and upload with python appcfg.py [web2py root directory].

NOTE: This leaves all the "extra" stuff that web2py installs. Examples and such. And the root of your app is still the default web2py greeting page. So the URL to your app is something like http://[appname].appspot.com/[appname]. That may be what you want. I need to dig deeper and figure out how to change that behavior, because that is not what I want. (It may be a matter of just replacing the welcome application with your own). I'll blog about that as soon as I figure that out (unless someone wanders across this and leaves the answer in the comments). It also uses up around 382 files, which could/should probably be stripped down immensely. The command line stuff should probably be replaced with .BAT files (or whatever's the equivalent on your OS).

UPDATE: Massimo Di Pierro was kind enough to inform me that, to make a specific app the "default" one that gets shown as the root, just name it either init or welcome.

So far, I've introduced two friends to web2py. They both had previously tried to get into Ruby On Rails, but they didn't like dealing with all the command line stuff. They both agree with me that python's more intuitive and simpler than ruby. They don't really care that it isn't as ~~powerful~~high-level, because they're really coming from lower level languages like C#.

Of course, there are all sorts of other frameworks out there, and web2py seems to be pretty young. There are things about it I don't like, but that's true about every framework. I've only begun to scratch the surface with it, but so far I'm extremely impressed.

Posted May 13 2008, 08:51 PM by JamesAshley with 1 comment(s)

Filed under: coding, Not Dot Net, python, open source

Initial Thoughts on Google App Engine

If you haven't heard of Google App Engine by now, you've probably been living under a rock. I won't try to explain it, or even include any links. Go check out what google has to say about it: it's intriguing, at the very worst.

It's really the first step toward the distributed web as a viable application platform.

Sure, the web's been an application platform for years now. I ran across an article (sorry, I don't have a link to it) about a year back that predicted 3 phases of web apps. Phase 1 was, really, Web 2.0 (whatever that means). You have rich applications that run on your server (or one that you rent). Phase 2 was where we've been heading for a while: you write "controls" that people embed in (say) their MySpace page. Those controls call into apps that reside on your servers, and the content appears on pages hosted wherever they were added. Phase 3 is where you get real control of apps that are truly hosted on someone else's servers ("in the cloud," if you will), using their SDK.

Conceptually, maybe not all that different that just renting a shared host and running CGI scripts there. But it's really a huge paradigm shift. This is the start to that.

In a lot of ways, web apps are (for what they are) at the same sort of maturity level that PC apps were back in the DOS days. Google's doing what Microsoft did with Windows 3.1. "See how much easier it is to develop on my platform, using my SDK, than it is when you have to worry about things like scalability, database maintenance, proprietary user authorization and authentication, etc, etc."

In a lot of other ways, Microsoft's already done most of this with things like ASP.NET, Active Directory, etc. And they've taken things several steps further (in the direction they want to go) with Share Point. Those things are great, if you're part of an IT team writing "enterprise applications." But, let's face it. That isn't the fun stuff. Cowboying out useful apps that people (even if they're just a few of your friends) will actually want to use...that's when software development is cool.

So I applied for a spot as a beta tester, downloaded the SDK, and promptly started procrastinating.

I got my notification that I had a spot in the Beta test yesterday, and I got really excited. So I actually started messing with stuff and reading the emails I was getting from the google group.

Here are some of my initial thoughts:

The basic SDK is nice, and you get most of the built-in python libraries. But they "sandboxed" a lot of the functionality: you can't access the file system, open a socket, or get to low-level OS pieces. Shouldn't be that big a deal. But a lot of the libraries that many people take for granted also get banned from the sandbox, as a result. Several of the libraries that I've investigated will not work as-is because of this restriction.

Python web development has changed a lot since the last time I did anything with it. Back then, they had just published the WSGI specs (don't know what those are? They don't really matter...except the basic Appengine SDK has a lot of references to this that are really cryptic unless you're familiar with the history). Now there are more web frameworks (reminiscent of Ruby on Rails) than you can shake a stick at.

The most popular (because one of the oldest) is Django. It really appealed to me when it first came out, but it's always felt kind of...meh. Google has decided to support it as part of its official SDK. So I looked into it again.

I'm still very torn. It's much higher level than the basic appengine API calls at the root of the SDK, but it still doesn't feel right to me. And google has gutted much of the "convenience stuff" that makes it so attractive (because of the whole sandbox thing). I may still decide to go with it, just because it's the default. That, and Guido was probably the one who chose it. At least for now.

I've also looked into pylons. Much more to my taste. And much more difficult to port/support. As I understand it, there's currently a limit of 1000 files per app. If you add pylons to your app, it sucks up something like 980 of those. And I don't particularly care for what I've seen of its templating engine. While I've been doing research, I ran across the cheetah templating engine. I've been highly impressed by what I've seen so far. If you do any code generation, it would probably be worth your while to take a look at this. But that would be yet another library to take precious space away from my files. (Okay, space isn't really the issue...but I prefer to have small classes, with small methods, in small files. That just seems easier to organize, to me).

Anyway, web2py claims to be working pretty much perfectly. Except that you have to use google's ORM. Which means you can't use their admin tools. But you can develop your site using their ORM and web-based admin center, then switch to using App Engine's ORM to deploy. I'm really impressed by what I've seen of this framework so far. It seems to have taken several "best of breed" approaches from several other leadin web frameworks and mashed them together. So I intend to take a closer look at it tonight.

Posted May 08 2008, 07:03 PM by JamesAshley with 1 comment(s)

Filed under: theory, code generation, Not Dot Net, python, open source

Linq to SQL and linked tables

There are several articles about how to do this, but none of them seem to reflect the kind of situations we encounter in the real world. They all seem to revolve around the same tables in the Adventure Works database, and they give you glimpses of "What" rather than "How." Oh, and they all seem to be cases where the database schema actually matches your business objects.

I'm dealing with a fairly simple scenario, but at least it's more convoluted than the "typical" examples I've run across.

Two tables:

CorporateEntity

CorporateEntityId (a guid...and the primary key)
CorporateEntityTypeId (bigint)
CreatedDate (a timestamp)

and CorporateSecondaryEntity

CorporateEntityId (the guid link back to CorporateEntity)
SecondaryEntityId (actually an enum to indicate its type)
SecondaryEntityValue (whatever this "Secondary Entity"...does, for lack of a better term)

There are some more columns and tables involved, but there you have it. The columns I mention for CorporateSecondaryEntity form the multiple-part primary key.

Clear, straightforward, and obvious, right? Don't blame me. I just inherited it and get to try to maintain the beast. Since its original design, we've come up with an alternative way to think about the data which (in my opinio) gets the point across much better.

I deciding to go with that naming convention when I started to write the maintenance apps. We also decided it was a good excuse to start actually using Linq to SQL.

Here's what I wound up with (more or less...it probably won't even compile. But this is the gist)

// It seems like everyone neglects to mention what namespaces things are in
using System.Data.Linq
using System.Data.Linq.Mapping;

[Table(Name="CorporateEntity")]
public class DictionaryItemModel{
        private EntitySet definitions;  // many definitions can be assigned to each item

	public DictionaryItemModel()
	{
		definitions = default(EntitySet);
	}

	[Column(Name="CorproateEntityId", IsPrimaryKey=true)]
	{
		public Guid DictionaryItemIdentifier { get; set; }
	}

	// (This is the column that gave me such fits in my last post)
	[Column(Name="CorporateEntityTypeId")]
	public long ItemTypeId
	{ get; set; }

	[Column(Name="CreatedDate")]
	public DateTime CreatedDate { get; set; }

	[Association(OtherKey="DefinitionItemIdentifier")]
	public EntitySet DefinitionModels
	{ 
		get
		{
			return definitions;
		}
		set
		{
			definitions = value;
		}
	}
}
	
[Table(Name="CorporateSecondaryEntity")]
public class ItemDefinitionModel
{
	private EntityRef item;

	// Figuring how to wire this up was what inspired this post
	[Association(OtherKey = "DictionaryItemIdentifier", IsForeignKey=true,
		ThisKey="DefinitionItemIdentifier")]
	public DictionaryItemModel Item
	{
		get
		{
			return item.Entity;
		}
		set
		{
			item.Entity = value;
		}
	}

	[Column(Name = "CorporateEntityId", IsPrimaryKey=true)]
	public Guid DefinitionItemIdentifier
	{ get; set; }

	[Column(Name="SecondaryEntityId", IsPrimaryKey=true)]
	public long EntityId
	{ get; set; }

	[Column(Name="SecondaryEntityValue", IsPrimaryKey=true)]
	public string Value
	{ get; set; }
}

For the sake of google (and anyone else who might run across this delightful error), I was getting InvalidOperationExceptions thrown when I tried to do a foreach over a table of the Item Definitions. The message associated with those exceptions was (for example) "Could not find key member 'CorporateEntityId' of key 'CorporateEntityId' on type 'ItemDefinitionModel'. The key may be wrong or the field or property on 'ItemDefinitionModel' has changed names."

That's still a bit over-simplified an example (I obviously left out lots of best practices stuff that would have just obscured the point), but at least it gives you an idea about what the attributes should look like and how they should be named.

Posted Apr 07 2008, 03:25 PM by JamesAshley with no comments

Filed under: coding, Linq

Linq to SQL and enums

This is really stupid, but it seems like enough of a stupid niche problem that it might be worth mentioning.

There's an integer column in a database that maps to an enum. Whenever I tried to mark that enum as a column, I got an InvalidCastException (from deep within the Linq reflection-magic call stack). No useful information.

So I wrapped an int property around that enum and specified that as the column. Same result.

After much frustrated googling, I double-checked the schema and realized that the column type was actually a bigint. Even though the value was only 8, it couldn't even handle that much of a cast.

Posted Mar 27 2008, 04:10 PM by JamesAshley with no comments

Filed under: newb, Linq

Empty try/catch blocks

I've seen several people do this, and it's always been a big clue to me that they're very new and inexperienced with .net. There are a few variations.

try
{
    blah;
}
catch
{}

That's probably the absolute worst. Your exception disappears completely, and no one ever knows it happened. I'm sure there are times it's actually the right thing to do, but it's almost always just a big red flag that whoever wrote the code was either in an unforgivable hurry or completely clueless. If nothing else, there should be a comment about why it was done that way.

Another version that one of my co-workers likes goes

try
{
   blah;
}
catch (Exception e)
{
    throw;
}

Maybe he just puts it there in case something wrong turns up later, and he has the framework in place so he won't have to add it later, if he does decide to actually handle an error there. Someday I really do have to ask him about it. Maybe he knows something I don't.

Posted Feb 06 2008, 07:04 PM by JamesAshley with 1 comment(s)

Filed under: best practices, coding, theory, newb

First post in ages

We've been trying to get around to switching to a different CMS for quite a while, but we had a lot of trouble deciding which one. Since I didn't really want to deal with importing posts until we'd officially picked one, I haven't really been blogging.

I could go into the options we tried/considered, but what do you care? Our criteria for this site probably don't match yours.

Posted Jan 24 2008, 05:43 PM by JamesAshley with 2 comment(s)

Filed under: CMS blogging

More Posts « Previous page - Next page »

Corey Roth and Friends Blogs

This Blog

Syndication

Recent Posts

Tags

Archives

Not Necessarily Dot Net

Real World Dojo part One: Form Validation

Real World Dojo, part One (Basic Validation)

The Scenario:

Switch to Dojo Fields

Switch to Dojo Form

Manipulating the DOM with Dojo

Selectors in Dojo

VB.NET vs C#

Net Neutrality

Some Open Source Ajax Frameworks

Introduction

Market Share

The Basics

Prototype

jQuery

Dojo

MooTools

My Thoughts

Prototype

jQuery

Dojo

MooTools

Wrapping Up (I know...finally!)

Linq to SQL Designer Weirdness

Linq to SQL with multiple databases

Some Initial Thoughts on Google App Engine

First Impressions of Web2py

Initial Thoughts on Google App Engine

Linq to SQL and linked tables

Linq to SQL and enums

Empty try/catch blocks

First post in ages