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.