Code Information

This is an aspx fired xslt 1.0 web site.

dlgr_FireTheXslt_YYYYMMDD	-	All pages are instances of this class. It is a System.Web.UI.Page.
code_listings.xsd	-	This is the schema for the interim "code" format. I translate to this schema for each individual file. I then just insert the <code-listing> tag into one large in memory file of the same schema in preparation to view the code as xhtml.
code_format.xsl	-	If the code that needs to be displayed is an xml file this is the xslt that does the translation to the interim "code" format. This xslt file is used if the file is xml, xslt or xsd.
code_display.xsl	-	This is the xslt that displays the code for the current page as xhtml. It uses an in memory xml file of the schema defined in code_listings.xsd.
gmap_data.aspx	-	This is the xslt that generates the kml file for the Google Maps VR index. This link views the kml file directly - gmap_data.aspx. If you are viewing this in Firefox it wants you to download the direct viewing of the file. This is not really an error. I assume it because the page returns a mime-type="application/vnd.google-earth.kml+xml" or in aspx lingo ContentType="application/vnd.google-earth.kml+xml". IE does what I want and picks up the "xml" portion of the mime-type. I can't say nor do I believe that Firefox is in "error"... Just not being overly cooperative.
verify_extract_media_type.aspx	-	This is NOT html! Hopefully someone will grasp that it is text/plain to verify App_Code/extract_media_type.xsl which has gotten it's ContentType from App_Code/extract_media_type.xsl. Therefore verify_extract_media_type.aspx?displaycode=true also works. Further this verification only required an aspx or php file... Nothing else required as it MUST be already written. With PHP you will note that I don't actually use the file... I have created an identical in memory DOMDocument that is the xslt. My assumtion is that it is possibly a little faster under PHP. However, note that in ASPX I do use the actual file. This is because it is a COMPILED transform therefore, my assumption is that in order to allow the server to actually compile the xslt it needs a file "placeholder" to compile to. It is an assumption...

When you view code you are viewing the actual code that has been processed and formatted by the above files dynamically. I don't "pre-run" the code files for formatting and then upload pre-formatted files. In fact the maintenance overhead for that would be far beyond my means and way too much work. When you click the link the xhtml output is processed from the actual file in real time.

Caveats and problems viewing code
- Characters like < (less than or opening character for a xml tag). This is most predominant when I'm outputing JavaScript from xslt. I have to use <xsl:text disable-output-escaping="yes"> quite often. Also   (non-breaking-white-space) is often a character of confusion as viewed in these xhtml pages. I am using xslt to view the xslt and while I'm sure(think?) I could figure out an algorithm to resolve the issue I have not spent the time... At this point I leave it up to the reader(you) to have enough sense to figure it out. This is a terrible position to take for "newbies" that are desperately trying to get ideas. But, if you paste the code into any good xml editor these problems will quickly appear and you can fix them pretty easily... A really good editor may fix the problem for you! Anyway fixing this problem might be more "accurate" but, it would also be harder to read, which is the object of the exercise in the first place.
- One of these days(years) I will get around to making a stylesheet that color codes the markup. Just another trivial task... ;) It is hard to read without color coding and I would like to do it. Again, pasting it into your favorite xml editor solves many problems.

All tabs, crs and lfs have been removed.
- I find that everything works much better without the tab, cr or lf character anywhere in files that have to be transported to and then processed by the client browser. Server C# is a noteable caveat but, those files don't go anywhere as a rule. My "web framework" viewing those files is an obvious caveat to that... Oh well. No tabs, crs or lfs is NOT a stratagy to "hide" the inner workings of my web pages. It is only to provide efficient web pages.

Client JavaScript for the various VR Viewers.
- I'm using the MooTools JavaScript Framework to size the <object> tag for whatever vr viewer is current. I like the framework and will probably expand my use of it.
- scripts/dlg_vr_script_20090505.js - is my "extension" using mootools. It doesn't do very much and unfortunatly tabs and crlfs are removed. I just limit the size of the <object> to a minimum of 640px by 480px. I limit the maximum to 1,024px by 728px. I found that the majority of vr viewers had problems going full screen if the <object> was much larger than that. As with all things VR, functional aspects are quirky and vary widely.
- The only other client JavaScript I use at this point is AC_QuickTime.js. I only use this <xsl:if test="starts-with($browser-platform,'Mac')">. I think that on a Mac system QuickTime is an anomaly for plug-in detection schemes because I think it is built in software for the Mac OS. If I were not specifically interested in showing VR's there would be no reason to go through such a rigorous plug-in detection scheme. If the end user has mov files set up to play in another player that player is not going to know how to "play" a VR. However if the current OS is Mac then detection becomes moot because QuickTime is available and will play the mov file. Theoretically... At least so far it works!

Various links that I used for information on valid <object> tag

Flash Satay	-	Set up valid Flash object.
Gillay	-	Set up valid Flash object.
Shayne Steele's	-	This valid java <object> seems to be pretty "bullet proof". I'm assuming that the various browser developers have good reason for making sure Java applets work well in their respective browsers... Which helps the situation dramatically.
Java Tutorials	-	These are Sun's Java pages about applet stuff.

W3C validator
- Because the W3C validator is NOT IE and will never be IE. The W3C validator is not Firefox and will never be Firefox. For the most part when you use the links for validation I have at the bottom of every page this is not overly important. However there are a couple of places, particularly in each of the specific vr-viewer pages, that you may want to verify the xhtml manually... i.e. copy and paste the client xhtml source into Validate by Direct Input. This will show that the exact xhtml you are viewing in your browser is, in fact, valid.
- It's only because I have to "sniff" the current browser for the <object> tag setup. I need a very specific set of plugins to view vrs I can't rely on mime-types. Generally speaking, you won't see any difference in the validation source that the W3C validator validates. It's only the rare case that I have to "adapt" the page for a particular browser to properly "see" a vr-viewer. For instance, the link at the bottom of this page will validate the exact same xhtml no matter what the browser is.

Home
Code