Scripting: ActiveMenu script update

There was a problem with the ActiveMenu script when an image in the story detail was not square. Up until now the height of the image was used to calculate the height required by the story. Unfortunately this would cause the calculation to be either too much or too little when the image was not square. To more acurately calculate the "area" used by the image, and thus the height used by the story, I modified the script to use a line bisecting the image diagonally as the basis for the calculation (currently 45% of that line's length). This is easily done using the classic hypotenuse calculation.

The code library has been updated with the new script.

Scripting: Win2003 IIS and SSI

Ever since upgrading to the new web server the page survey has not been functional. Upon further inspection it appears that a script accessed via SSI #exec in Win2003 has a number of problems when compared to Win2K:

• no access to the originating page's query string
• SCRIPT_NAME returns asp page rather than originating page

The former problem causes a page to not know that the survey has been submitted.

The latter problem causes a page to never display the survey in the first place (surveypage.asp is on the list of pages that are to not have the survey shown).

So far I have been unable to find much useful information regarding SSI in Win2003. SSI doesn't seem to get much attention these days beyond the basic how-to. I've posted a question to one of the Microsoft newsgroups, hopefully I'll get a useful answer.

See my post for more info: SSI #exec and querystring passthrough

Update 2005-11-28:
Of the two options I noted in my post linked above I've decided that the quickest method of addressing this problem is to associate the HTML files with the ASP processor. I'll test on the development server for the next week then implement on the live server.

Update 2005-12-05:
A response to my newsgroup posting confirms that there was a change in the way #exec operates. I've seen no major problems using the ASP processor on the development server so I've gone ahead and implemented it on the production server.

IERI: Revision thoughts

Just a quick post on some thoughts for the architecture for the revision of the utility.

Architecture
One of the purposes of the rewrite is to make the utility more flexible. Currently a user is required to have a fairly modern browser with JavaScript enabled and the RealPlayer plugin to use the utility to it's fullest potential. Ideally the utility should have a base level of functionality even in the most crippled of browsers. One way to get to this level of functionality is to use progressive enhancement to add enhanced functionality through JavaScript on top of an already functional HTML core.

The way I envision modeling the utility so that this can be acheived is to go back to a classic three-tier system: presentation, logic, data. By further extracting the functions that handle data processing from flow control and interface presentation I hope to be able to create a functions that can response to requests from a variety of sources (rather than using conditional statements to determine the output). I imagine the easiest way to do this is to develop the functions as discreet scripts that process requests and return XML over HTTP (similar to web services I suppose). That way the interaction of the front end to the back end does not depend on the the source (browser vs. server script), allowing the backend to be simplified somewhat while allowing the front end to branch out.

I also think that modeling the utility in this way will make updates simpler. The difficulty of editing the processing page gets worse over time.

Video
I've posted recently on problems with the timecoding, so no need to go over that again. Another issue, though, is that I'd like the video portion of the utility to be less restrictive. The utility should be able to handle formats other than RealVideo and players other than RealPlayer. If the security issues can be addressed and the object model of the players determined then it should be fairly trivial to determine which player to use at runtime.

Security
One of the biggest problems with the current utility is it's security. The authentication system is ugly and not too secure. The user rights assignements are too broad. There's no way to sandbox users beyond limiting their rights (e.g. limit the Deleware group admins to administration of their own users).

I'm thinking that to work around this I'll create a permissions table that stores information on who can perform what functions. This should allow a finer level of authorization control. One area that I hadn't originally thought about until just now is the sandboxing of users ... something I'll definitely need to consider.

IERI: Forums updated

I needed to update the compatibility information for the utility. While testing is not difficult, accessing the wide range of browser/OS combinations is. I decided that rather than trying to maintain a list myself I'd try something new and post compatibility information in a forum. In this way the users could post their own experiences so that broader compatibility information could be obtained. Also, in this way I could also post specific compatibility problems as related to a browser/OS combination plus any work-arounds that would address the problems.

While this could have been acheived with the older forum scripts, I decided that it would be a good time to update the scripts with modifications I've made since the IERI forum was initially released. Most of the updates are fairly minor.

• Previously a different set of scripts had to be written for each forum. Now, each forum is given an index which the scripts use to determine which database tables to access.
• The authentication of the forums has been better integrated with the utility's users table.
• Users now have a setting that will trigger a notification when a new post has been added (currently a universal setting).
  

I made a few modifications to the scripts as well to accommodate some special options that were requested for the activity level forums. Actually, the request was for the ability to add notes to the analysis. I made the decision that the forums would sufficiently address this need by adding the ability to record whether a post related to the activity analysis as a whole or to a specific sighting analysis. These do require some specialized code that target a specific forum, but I think this trade-off is worthwhile in this particular case.