If you haven't already seen our DBWeb controls I highly recommend taking a look at them once Diamondback hits the streets. Our DBWeb controls are a set of data aware ASP.NET controls that allow you to not only manipulate data at runtime but also view the data on your WebForm at design time. If you haven't played much with ASP.NET you might ask "why is that a big deal?" since design-time data has long been available in the VCL form designer. Well, for starters when Microsoft shipped ASP.NET (1.0 and 1.1) their data aware controls required (and still do btw) data binding code before they will render any content which means they only render content at runtime.

For example, when you drop down an you see that it comes prepopulated with some fake data and that's all your ever going to see at design time. In a DBWeb control, once you connect it to an active data source you'll immediately see the data in the ASP.NET designer just like you see data in the VCL forms designer. Again, you might be saying to yourself "that's really no big deal I don't need to see the actual data". Well, picuture this you have a grid that once it's populated with data is going to run right off the righthand edge of the page you've spent so long making look really nice. Wouldn't you rather discover that as soon as you hook up the control rather than having to run the application for each and every control you add to the page to just to see how the control will morph when it contains data?

We first introduced our DBWeb controls in C#Builder and in Diamondback we've continued to improve them and add additional controls for things like sound and multimedia content. Additionally, you can feed the controls data from an XML file so it's easy to quickly prototype a data driven web site without even having to setup a database.

Back when I was working on BorlandC#Builder I made the decision to incorporate the W3C's HTML Tidy formatting tool directly into the IDE.  It has lots of options and does a nice job of formatting and correcting errors.  There are several ways to leverage HTML Tidy in the IDE, for example when editing an HTML file from the code editor you can select Edit | HTML Tidy | Format Document or Edit | HTML Tidy | Check Document for Errors.  Additionally, you can also select to use HTML Tidy as the default HTML formatter for both HTML and ASP.NET pages.  What isn't obvious is that we had to do a tremendous amount of work to get HTML Tidy to play well with ASP.NET controls but even with all the work we did it still won't format certain ASP.NET controls correctly. 

Since ASP.NET tags are not part of the HTML specification it is necessary to provide Tidy with a list of new tags and how they should be formatted.  Tidy has several options allowing you to control how new tags are formatted using either block, inline, empty or pre.  In C#Builder and Delphi 8.0 we automatically discover any ASP.NET tags within an .aspx page and prepopulate these settings prior to formatting allowing Tidy to format the ASP.NET tags as it would any standard tag.  There are lots of ASP.NET tags and subtags and without this feature it would be incredibly tedious to try and use HTML Tidy to format ASP.NET pages.

One problem however is that some ASP.NET tags support templates, meaning that they can contain fragments of HTML which should not be modified during the formatting process.  Unfortunately, HTML Tidy has no way to deal with ASP.NET templates and will in fact reformat the tag and completely change it's meaning.  As you can imagine this is not a good situation and unfortunately there is no workaround.

HTML Tidy does provide support for various web scripting languages like PHP and ASP and I think as the popularity of ASP.NET grows that it would be great if HTML Tidy could provide support for it too.  If the support can't be built into HTML Tidy then there needs to be some alternative whether it's a callback or some other mechanism that would allow the developer to improve Tidy's ability to deal with tags that it's not familiar with.

Over the past year and a half I've have seen a handful of requests for Tidy to support ASP.NET but unless more people speak up and voice their opinion I'm afraid it will be a long time before that will happen.

Here's where you come in, if you'd like to see this situation improve please visit the HTML Tidy website, get involved either by asking the great set of developers who keep this code base alive to support ASP.NET or by grabbing the code, diving in and adding it yourself (of course read all of the guidelines before doing that).

While you're there also make a case for separating how HTML Tidy options are passed so that things like the Borland IDE's aren't tied to the Tidy config file format.  I'd really like to see the command like option handling separated so that IDE's can load options from whereever they store them whether it's the Windows registry or an INI file or whatever.

A few other notes, I'd like to thank the people who work on HTML Tidy for all of their effort.  They do a great job and have been very helpful and responsive whenever I've had questions.  Additionally, I'd also like to point out that we used Jeffrey Pohlmeyer's TidyPas Pascal interface.  Btw, both of these are mentioned in our IDE's Help | About box.

To start off I'd like to address the issue of why we need a formatter at all. Our ASP.NET/HTML designer leverages the MSHTML control as its design surface and as a result we have to deal with the fact that this control discards any/all formatting including whitespace preservation when working with HTML. If you'd actually like to see the effect of using MSHTML without a formatter (trust me you won't be happy) simply rename htmlfmt80.bpl in your Delphi 8 bin directory, start the IDE and answer Yes to the "continue to load this package" error and start editing an HTML file. This package contains our HTML formatter and without it you simply get back the raw HTML from the MSHTML control.

One decision we made in Delphi 8 was to format only the content of the file starting after the first tag. There were several reasons we did this but the main reason was that we wanted to format as little of the file as possible and since many pages have sections that contain stylesheet and scripting information we thought this would be a good idea. As it turns out this wasn't a very good idea and in some cases can result in HTML being either mangled or duplicated neither of which is good. It is possible in Delphi 8 to undo the changes made in the designer using Edit|Undo but that's not always acceptible either.

In Diamondback we've completely fixed this problem and not only improved our formatter but also have relaxed the rules for creating non-HTML documents using the ASP.NET designer. For example, if you want to create an ASPX page that returns only XML (like an RSS feed) simply start a new ASP.NET page and delete all of the contents except the @ page directive at the top of the file then start adding your markup and the designer won't mess it by trying to turn it into an HTML page. As a side note, we've continued to monitor the progress of the W3C's HTML Tidy open source project and have worked to keep our libtidy.dll up-to-date.

Diamondback, like Delphi 8, supports code completion on ASP.NET server controls from within the code editor as well as the tag editor.  This makes working with ASP.NET tags much easier and helps prevent mistyping tag and attibute names helping keep your development time productive.  In Diamondback we've changed the loading of schema files that describe ASP.NET server controls such that third party companies that produce ASP.NET controls and make their controls work like first class citizens in the Diamondback IDE with full support for code completion and HTML Error Insight (a topic for another day).

To take advantage of this feature all you have to do is create a .xsd file that looks like the ones provided with Diamondback and place it in the “..\schemas\asp schemas” under your Diamondback root directory.  When the IDE starts it loads all of the schemas from that directory for use with various IDE features like code completion.  If you are a vendor who already has a schema file for VS.NET then typically just dropping that file into the above directory will add first class support to the Diamondback IDE.

In continuing my posts on new ASP.NET features in Diamondback today I'll mention ASP.NET template editing. Several ASP.NET controls support what are called templates which are small fragments of Text/HTML that the control uses are runtime. Controls that support templates like or template columns within a require a special template editing mode necessary to edit the template in the WebForm designer. Basically, template editing is a special sub-edit mode of the control used within the ASP.NET WebForm designer, something that wasn't supported in Delphi 8.0 but fully supported in Diamondback. In Delphi 8, you can use the code editor to manually edit control templates and in Diamondback you'll be able to use the template editor right within the WebForm designer which supports drag/drop and direct editing of the template. Additionally, with the tag editor, the small edit window at the bottom of the WebForm designer, you can immediately see the code within your templates which is a feature unique to Diamondback. Template editing is one of the many improvements to ASP.NET development we'll be delivering in Diamondback.

Now that the 1.0 preview release of Firefox is out I just gotta say again how nice it is to have a browser that keeps getting better and better.  Some of the new features that I really like are incremental search and the highlighting of the address bar when you browse to a secure site.  Firefox has really made me look forward to getting each new release.  My thanks go out to everyone who works to make Firefox the great application that it is today.

In Delphi 8 we didn't really provide any support for developing CSS/stylesheets which any web developer knows are an important part of web development.  Well, fortunately Diamondback (the next release of Delphi) supports CSS syntax highlighting as well as CSS code completion making it easier to build stylesheets where you don't have to constantly refer to reference material in order to create a new style.  I highly recommend familiarizing yourself with CSS so that you can leverage the many advantages it provides.  Here is a great site that has lots of information to help you learn CSS.

Another issue in D8 was that the designer wouldn't always resolve relative file locations for things like images and stylesheets correctly which has been fixed in Diamondback.

Here are a few pointers regarding how relative paths are resolved in the Diamondback IDE:

• If the file is part of an ASP.NET project then it's references will be resolved relative to http://localhost allowing for use of virtual roots to refer to global image and stylesheet locations.
• If the file is not part of a project (like a standalone .htm file) then any relative URLs are resolved relative to the directory path of the .htm file.

Basically if the file is part of an ASP.NET project then any relative URL references in the file are resolved through http://localhost rather than the file system.