I just uploaded a new zip archive of the Members onTap plugin that resolves the missing region input issue.

So I was working on my contact system and I wasn't entirely happy with the performance of a particular page and started timing portions of the page to figure out where I could tune it to get the response time down. It turned out that one of the bigger sources of the overhead was in the display of region names. It's part of the Members onTap plugin, there's a RegionManager object which manages geographic regions from the country down to as small an area as you want. Probably most folks will use it for Country > State > City -- but there's nothing keeping you from entering US > Northwest > Oregon > Portland > South East -- or even more specific if you really wanted to, though it'd probably become pretty cumbersome. Once those regions are in the database however, you get to display the whole region path with the xhtml syntax like this:

And that would create something like this:

So on the page it looks like

But this whole nested set model thing is always kind of a pain in the ass, and the method was more overhead than was really needed. Plus unless it's a menu and the individual region names are linked (which is another option in that tag), it doesn't really need the individual spans in the middle, so I was able to get some better performance out of it by changing the display code as well as retuning the RegionManager object so that it stores 2 queries internally with all the data from both of the tables that store the region information - one for the region and another for the nested set info. So now it uses query of query to get the ancestors or descendants for a particular region. Also eliminated the caching for individual region record structures since it's caching those queries now.

Incidentally, screw Joe Celko -- I learned how to do nested set on my own, before I'd ever heard of Celko. Never read his book either. Just another in a long list of things I've learned on my own only to later discover that even though people looked at me funny when I explained them, they happened to be powerful design patterns written up by someone else, which usually become popular some time after I learned them. :)

I also realized that when I'd implemented the auto-increment code recently apparently I got the sample code from somewhere else and hadn't thought to check the documentation. So I didn't realize that the column name for it wasn't consistent across platforms, so I had to update the framework core to use the different names for different databases. Would have been nice if Adobe had provided an extra key like a cf_autoincrement or somesuch maybe in addition to if not in place of the individual values for different databases. Which is essentially what I did in my code, so I guess at least if I get to use my own development techniques then the issue is moot.

Anyway, this means two new builds today. One new build of the framework core and one new build of the Members onTap plugin.