Web Folder
Services Introduction
As seasoned users we all are accustomed to thinking of folders
as a simple list of files and subdirectories. It comes almost
naturally, then, to look at them as standard system objects whose
behavior has been coded once and for all in some system library.
With the introduction of Microsoft's Active Desktop™ shell update
for Windows 95 and Windows NT 4.0, though, things began to change.
Today, with Windows 98 already in our hands, and as we get closer
to the release of Windows 2000, the folder concept is definitely
evolving toward the more general idea of a content provider. A
folder is a system component holding content that, in its simplest
form, provides a list of files and folders. In general, a folder
can contain anything, including records from a database, registry
entries, e-mail messages, connected printers, scheduled tasks,
and so forth.
Behind the curtain of this general schema pulse two far different
technologies: namespace extensions (NSE) and hypertext templates
(HTT). Both are committed to helping you design, with the highest
degree of freedom, the content and the look of your folders. Both
are tightly integrated in the Windows platforms. For example,
Windows CE Services use a namespace extension to display files
on the remote device.
When Do You Need Custom Web Folders?
To start off, what are reasonable scenarios in which you may need
to create custom folders, and what kind of applications can create
and exploit them? A few years ago I had an application that managed
quite complex documents. The complexity was not so much in the
content itself but in the rendering of the content. It was a collection
of JPEG images stored in a single file and I needed the folder
view to provide a list of thumbnails to click and zoom in on.
In addition, the user was supposed to be able to organize these
files by subject and date. Both thumbnails and images were actually
stored in the same folder. It was my bad luck that all this happened
before Windows 95 came along, because NSE would have been a great
tool to employ. Today I'd design a similar application as an NSE
that reads the documents and provides a thumbnail view.
Another common scenario in which you
might want to consider using customized folders is the following:
Suppose you have
a shared folder that contains valuable data (for example, a database
of bibliography references). Because the folder is shared, all
network-connected users may access it. Suppose, also, that there
aren't access rights problems and that all users are authorized
to see all the content in the database. Typically, they connect
and open the database using, say, Microsoft Access. What they
obtain is the typical Access user interface with all of the tools
available. A time-saving approach, instead, might be to present
the user with a customized folder that doesn't show a list of
files but a table with the records. In this way, the user would
be redirected to the desired link with just a click. Not to mention,
you might make the folder's user interface smarter by adding fields
to accept and execute queries. (This is demonstrated in my "Active
Desktop: The Shell and Beyond" article in the March 1998 issue
of MIND magazine.)
The former scenario demonstrates namespace extensions in action,
while the latter relies on folder customization and hypertext
templates. In both cases, you can arrange to make the user interface
totally Web-oriented. This is possible due to the HTML support
built into the operating system with the advent of the Active
Desktop interface. In this article, I'll focus on how the folder
customization mechanism works and which windows layout it leverages.
Next, I'll discuss which additional features can be made easier
to use and how you can make your application's folders more user-friendly.
In particular, I'll cover custom icons, descriptions, and infotips.
Windows Folders Internals
Active Desktop changed something in the internal hierarchy of
windows that Windows Explorer employs to show you the folder content.
Figure 1 shows two different Windows Explorer views of the same
folder. The topmost is a Web view, while the other is a classic
view.
Figure 1.
A Web and a classic view of the same folder In Figure 2, with
the notable help of Microsoft Spy++, observe the internal structure
that lies behind such views. Highlighted in green are the main
windows of Windows Explorer. The first corresponds to the Web
view. The second relates to the classic view. The different windows
employed in each case are outlined in red.
Figure
2. The hierarchy of windows
that provide the folder views shown in Figure 1. The core of the
view is a window of class SHELLDLL_DefView. You can obtain such
views by switching on and off the View|as Web Page menu item.
Notice that you might have a slightly different name for the shell
embedding control if you aren't running Windows 98—this screenshot
has been taken from a Windows 98 machine. The window that provides
the shell view, namely the list of all the files and subfolders
that appears in the right panel, belongs to a class called SHELLDLL_DefView
(shell default view). It works as a container for another, more
specialized window that is actually responsible for providing
and displaying the folder's content. This latter hierarchy of
windows changes quite a bit according to the status of the View|as
Web page menu item. For this reason, the default view is also
known the shell view router.
If the item is not checked, you're displaying a classic Windows
95 view with the usual four options: large icon, small icon, details,
and list. (After all, these options have a direct correspondence
to the view styles of a Microsoft Win32® ListView control.) Otherwise,
when the item is checked, you get an HTML-based view of the folder.
In other words, the container hosts a WebBrowser control to display
a templatized HTML page that includes the usual file list through
a Microsoft ActiveX® control.
Figure 3 illustrates this. Figure 3.
How Windows Explorer switches between classic and Web views
Figure 3 shows the content of Windows Explorer's right panel.
In the classic view, the shell reads in the files from the current
folder and fills the ListView. In the case of a Web view, the
same task is accomplished with an ActiveX control. This is not
surprising, because with Web views what you actually perceive
as being the folder's content is just an HTML page viewed through
the Internet Explorer browser engine. Hence, employing an ActiveX
control is a good way to isolate the complexity of the file search.
I'll have more to say on HTML templates and the WebBrowser engine
shortly.