The clear vision today is XHTML data traveling only one way from Office Word and InfoPath—from these Office clients to the service/server. There is no round-tripping for my sequences:
The Office Word sequence. Extract standards-compliant XHTML from Office Word and store it in a database as new data or an update of existing data. The only data returning from the database that would be necessary is some kind of identifier used to locate existing data for updates. Everything else is one way.
The InfoPath sequence. Open a blank form with multiple XHTML fields, fill it out and submit the root node to a Web service. Almost useless without rules to identify uniquely the data being submitted—not a show stopper but time consuming.
It seems obvious and tempting to expect InfoPath to query the Web service to return the new data through one “web method” for any additional editing but this is annoyingly inconvenient in the SP1 version of InfoPath. Why? InfoPath cannot ‘discover’ XHTML nodes ‘inside’ of an XML node emitted from one Web service member. The Web service has to provide multiple “web methods” that ‘tell’ InfoPath it is about to send XHTML. This means that instead of, say, sending one XML node with four XHTML child nodes, you would be forced to expose four “web methods” for each XHTML child node in addition to the other, un-rich text you wanted to send in the first place.
There is a Funky Knowledgebase article about this serious setback at SonghaySystem.com. I really did not know how serious this is until accepting my expectation that building XHTML editing into Microsoft applications is not a premium thing (worth several hundred from 3rd-party vendors) but an essential thing—like a browser with tabs. What the InfoPath team calls “rich” text is treated as a special, edge case, while the ‘real’ InfoPath users send bare naked text strings around just like in the days of DOS-based data entry systems. I assume that they are downplaying the importance of editing “rich” text (XHTML) until the technology catches up to my very valid needs. Okay, I’m drawn back into the XStandard.com ActiveX stuff.
The picture at left is a picture of the .NET Framework. It’s a folder full of ‘stuff’ on your hard drive. In fact, it’s the old version of the .NET Framework (the latest release is in another folder, sitting right next to the one shown). I show this folder to remind myself of when I started living with the .NET Framework: the create date shows Monday, March 11 2002, 9:36:40 pm. So over three years is my time with the .NET Framework. (We can subtract about six months from the three years because after it was installed back in 2002 it just sat there being ignored by me.) By the way, one could argue that the 1.1 version of the .NET Framework is the ‘useable’ version of the Framework and this did not appear on my primary development machine until 4/10/2003.
Let’s confine ourselves to about two years of me actively implementing my ‘personal’ technology plan to divest from VB6/ASP, COM-based ‘linear prose’ (spaghetti) and move into the ‘abstract-morphic’ world of the .NET Framework. The technology plan in bullets:
- Define representations of physical data stores in the abstract world of the .NET Framework. Achievement here is discussed in “Founding the Songhay.Data.Components Namespace.” Nothing moves in my world of publishing without a data management framework. So obtaining these definitions is essential and fundamental. There was not much ‘divestment’ here: the SQL Server stored procedures built back in my ASP days are still useful (although I do wish that .NET SQL Data adapters could easily ‘see’ multiple data sets in one stored procedure at design time in Visual Studio .NET).
- Develop Web services to increase the surface area of data access. Every time I attempt to work here, I discover that another fundamental data representation problem has to be addressed. Web service stuff is still new stuff—so not much here. I’m not building from scratch kids; I’m trying to drag along mountains of legacy data and legacy procedures with me.
- Develop human-readable “smart” (and thin) clients that consume end points of data access. I have already said that Windows Forms 1.x suck (—nevertheless, I use them). So this is where Scott Guthrie and ASP.NET code-beside designs emerge in relevance.
My recent ASP.NET epiphanies finally reveal to me why ASP.NET 2.0 added or removed (based on the Beta you are fruggin with) the code-beside model to its design. But let me be clear about what I mean by “code-beside” patterns. I mean creating an ASPX page and loading it up with Web form controls and script blocks running at the server. These script blocks sit beside the controls—hence code beside… (No dependencies on partial classes here.) This is nothing new: the tutorials on asp.net have been using this pattern from the beginning. Why am I so late to the party? Because the current RTM version of Visual Studio .NET is almost entirely ignorant of this pattern. You have to work against Visual Studio .NET to build code-beside pages (which, to me, is why The ASP.NET Web Matrix Project has been so popular). Now that years of writing C# and VB.NET code under the tutelage of IntelliSense™ have gone by, I can break the fetters and drop small blocks of code directly into script blocks. I stress the word “small” because:
When you are writing ASP.NET pages that require inheritance and hundreds of lines of code you are probably on the DotNetNuke.com portal team or you are cramming code into your client that should be in another layer of your application (like a “business rules” or data access layer).
- You might not be taking advantage of pre-compiling complex, user-interface experiences into custom server controls.
- You might not be using XSL templates with the Xml Web Server Control to declare complex, user-interface experiences.
- You might not be taking advantage of running “traditional” HTML tags at the server (like the HTML
title element) and processing them in code as
When you can redesign your code-behind ASP.NET pages such that almost all of the code resides in the
Page_Load() event procedure, you are probably wasting your time (like I have been doing for at least a year) trying to define a formal namespace and class name for these pages and compiling it into a DLL. I would prefer to throw it all in ASPX files that compile dynamically and treat it like my ASP files I hate so much. The opinion here is and will be vindicated by the following:
- The ASP.NET team will not discourage using dynamic compilation and will address concerns with performance (starting with caching).
- The ASP.NET team will continue to tout its zero-lines-of-code (ZLOC) design goal and ‘accidentally’ do the work the SharePoint portal team has been struggling with for years (before the SharePoint team, the FrontPage team still writhes in anguish).
- I’m almost sure that the next release of Visual Studio .NET no longer ‘forces’ developers to define projects that compile a DLL—along with no longer being forced to associate Web forms projects with IIS.
- The presence of IntelliSense™ in ASPX-page script blocks in the next release of ASP.NET will encourage us to use this kind of “code-beside” pattern.
Scott Guthrie produced a motion picture Web cast at Microsoft showing off ASP.NET in the future release of Visual Studio.
This is not the first time new material has not appeared at kintespace.com in over two months. It is the first time, however, that the creator of kintespace.com is writing about it openly. Isn’t Blog authoring so wonderful?
What’s the deal? Well, I’ve been trying to buy this new life of technical dominion. I’ve been trying since 1998 to make publishing easier. This is like a road trip that feels like it’s going on forever but the strange feeling is that once the destination is reached the ride would have been worth it. So, driving along here, I have ramped up research and development in data management at the expense of ongoing production. The last few Blog posts should suggest that the R&D (and lab equipment failures) have overtaken ongoing production. It feels miserable but I keep telling myself that this is the “big one”—once this trip is over, we will be in the place to be.
I interpreted my own buying decision egocentrically: I bought two hard drives for the server (pictured at left) because modern Microsoft operating systems don’t ‘really’ support drives larger than 120GB (127GB to be exact). I was angry about this and did not ‘trust’ Windows Server 2003 on my brand new 160GB Western Digital drive—so I angrily stuffed the price of an 80GB Western Digital drive on my already stuffed credit card. So this angry guy—pissed off with these bizarre limitations in billionaire operating systems—ended up with a system hard disk (80GB) and a data disk (160GB—limited to 127GB).
When my system ‘failed,’ I thought I lost my data files as well. But it turns out that since my data files are located on a different partition, the OS can be reinstalled to mount the partition. It still may seem extravagant to non-nerds to have two hard drives. But remember folks, I’m the guy who cut the motion picture Ramona Africa: 1992. Work like this is just the beginning—so I’m really going to need the drive space—more in fact. No ego-dominion is respected here.
ieSpell—A Spell Checker for Internet Explorer
A spy-ware-free promise from the website: “Completely standalone spell checker for your web browser. Does not require Microsoft Office or any other third party components.” I am slow to promote more COM-based stuff but it’s not going away soon.
To enable Undo Disks for a virtual machine
As a MSDN guy, I found it novel to cite something from TechNet. But I had to since I am playing around with Virtual Server 2005.
C# Edit and Continue support for Visual Studio 2005
For you Tom Slick fans: Hooray. Microsoft is making a Thunderbolt Grease Slapper.
Dsofile.dll lets you edit Office document properties without Office
“You can use this in your custom applications to read and to edit the OLE document properties that are associated with Microsoft Office files…” More here.
“VBScroll solves the problem with mouse wheel scrolling in Visual Basic IDE and VBA editor…” More here. I do find this a problem in the VBA IDE—but I expect never to work seriously with VBA ever again!
Microsoft Office Project
This page appears to have collected all of the useful articles about Project. Nevertheless, the last time I checked Project Server still uses ASP files! This Office team is mired in technology from the late 1990s. I am sure that they do not find this situation pleasant.
Office 2003 Update: Redistributable Primary Interop Assemblies
Since I am writing .NET code against VSTO 1.x, I may have to keep this download in mind.
Windows 2003 Terminal Services
Another operations article! I often forget that Terminal Services Licensing is installed separately—not from the Manage Your Server thingy.