Powered by discountASP.NET
referal ID: sdtref
Why recommend discountASP.NET?

Archives
Steve Trefethen Steve's RSS Feed Subscribe or via email
What's this?
Contact me Send mail to the author(s)
About Me
View my LinkedIn profile

Add to Google
Subscribe with Bloglines
MCP Microsoft Certified Professional

Falafel Software
Online or OnSite TestComplete Training
Blogroll
Recent Comments
My Online Tools
Stats
Total Posts: 472
This Year: 77
This Month: 2
This Week: 1
Comments: 1660
Tags
Disclaimer
The posts on this weblog are provided �AS IS� with no warranties, and confer no rights. The opinions expressed herein are my own personal opinions and do not represent my employer�s view in any way.
My most popular blog posts (Q1 2008)
# Tuesday, September 27, 2005

ASP.NET features in Dexter (the next release of Delphi)

Posted @ 9:44AM

Categories: ASP.NET | Delphi.NET

Tags:  | 

In light of the public display of the roadmap I thought I'd mention a few of the improvements to the product in relation to the HTML/ASP.NET designer. As I've mentioned before a major focus on this release has been quality but there are plenty of new and exciting features as well. Related to the ASP.NET designer we've added:
  • Markup source preservation
  • Tag Editor Error Insight (screenshot)
  • Improved project deployment
  • Improved ASP.NET project management
  • Improved Tag Editor markup editing
  • Improved project load performance
  • Lots of designer performance improvements

# Tuesday, April 19, 2005

Is anyone using HTML Tidy as their default formatter in Delphi?

Posted @ 10:06AM

Categories: Delphi.NET | Tools

Tags:  | 

As I'm working on features for our next release I've been wondering if people are using HTML Tidy as their default formatter for HTML in the Delphi IDE? I've discussed issues regarding HTML Tidy and ASP.NET here before and at this point since HTML Tidy simply doesn't support ASP.NET I'm thinking it's time to remove the option to use HTML Tidy as the default HTML formatter from the IDE. We can still provide the option to format using Edit|HTML Tidy|Format document so we won't completely remove HTML Tidy support.

# Thursday, March 31, 2005

Why do we need to format html in Delphi?

Posted @ 11:09AM

Categories: ASP.NET | Delphi.NET

Tags:  | 

I know this issue has been pretty well discussed but someone recently asked me about it again and I put together a small example to help illustrate the problems that arise when using the MSHTML control and trying to preserve source code.

Here is what we hand the MSHTML control


  
    
  

  

        
  • one
        
  • two
      

  this is
wrapped text
  
    
      

  


we get this back (without editing anything btw):




  • one
  • two
this is wrapped text




Now, to point out the differences...

  1. All tags are now uppercase
  2. runat="server" on title tag is gone
  3. Missing the first closing (notice the last one is preserved)
  4. A single space was added between "two" and
  5. The wrapped text has been unwrapped
  6. The order of the table tag attributes has been reversed
  7. The quotes around the table tag attribues have been removed
  8. The case of the table tag attributes has been changed
  9. TBODY tag has been added
  10. A closing TR tag has been added (but no closing TD??)
  11. All whitespace has been removed (except of course where it was added see above)

So, as you can see when it comes to source preservation using the MSHTML control we definately have our work cut out for us thus we currently reformat the markup to make it readable again. I'll have more on this later.

# Monday, February 28, 2005

Detection of duplicate tag ID's in ASP.NET Web pages

Posted @ 12:44PM

Categories: ASP.NET | Delphi.NET

Tags:  | 

When update 2 of Delphi 2005 comes out one of the additional features of HTML Error Insight (the squiggly error underlining in the code editor) will include detection of duplicate tag ID's. This feature will allow the developer detect and correct duplicate tag ID's without having to run the application and wait for the ASP.NET runtime to flag the error for you. There have been numerous other improvements to HTML Error Insight for Update 2 but I think this is probably the most useful one and thought it was worth mentioning.

# Sunday, February 27, 2005

Like Compact Frameworks the ASP.NET designer is "build your own"

Posted @ 12:45PM

Categories: ASP.NET | Delphi.NET

Tags:  | 

Now that Danny has explained, with this post the real story behind Borland's Delphi.NET Compact Framework (CF) support I'll throw my hat into the ring regarding the ASP.NET designer support.  Basically, it's the exact same story as CF in that it doesn't exist outside of VS.NET and if you want an ASP.NET designer you'll need to write it from scratch.  Well we've done exactly that with Delphi.NET and C#Builder, in other words we implemented Danny's option number 3 (refer to the link to Danny's post above).  As Danny mentioned this is the most flexible option but, as he said, it does come at a high cost.

As ASP.NET 2.0 takes shape, in some ways, we've been in a bit of a holding pattern watching and studying the level of support that the new designer provides.  Had there been designer support in the framework that we could have leveraged perhaps we'd have been able to spend our time working on additional supporting features rather than cautiously planning and implementing just the features we feel will truly make it into the final release.  Additionally, Microsoft has all but removed .NET 1.1 designer compatibility from .NET 2.0 by not only deprecating old methods but at the same time making them  stubs so they don't even do what they used to do; two steps forward and one giant step back.  I agree with Danny when he says that he doesn't think all this occurred because malious intent on Microsoft's behalf but I think third parties like Borland could argue that it's perhaps not the best way to get other's to support your framework which we're really working hard to do.

Let's imagine for a second that the ASP.NET and CF designers had been implemented like the WinForms designer.  Had that been the case I think it would be reasonable to assume that third parties could have spent their time finding ways to make developing for the .NET Framework that much more compelling rather than reinventing an already existing wheel.

I suppose it's necessary to ponder the reasons why Microsoft decided to leave these two key designers out of the framework?  Danny already discussed the case for the CF framework so I'll take on the ASP.NET case.  This is an interesting situation because Microsoft has actually implemented two ASP.NET designers themselves: VS.NET and Web Matrix.   Why is that Web Matrix was developed within the ASP.NET team separate from VS.NET?  Did the ASP.NET team not like the implementation of the VS.NET designer?  Was it too different from the way previous versions of ASP worked (code behind vs. inline)?  Was this a way for the framework guys to “twist the arm“ of the VS.NET guys into implementing certain features wanted by producing a competing (ok, perhaps that's a stretch) free product?  Or are these arguments conspiracy related and did the ASP.NET guys just want a free tool to further their platform?  Perhaps we only have to look as far as VS.NET 2005 which includes support for inline pages and the VS Express versions which are free.  Considering that Web Matrix has staggnated with the “reloaded“ version and the last “call for feedback“ on Web Matrix was made in 2002 I sort of doubt we're going to see another update of Web Matrix any time soon.  Ok, so maybe the ASP.NET and VS.NET guys have worked out their differences (if there were any).  It will be interesting to see what happens to Web Matrix when the .NET 2.0 framework hits the streets.  Will Microsoft still prominently display Web Matrix on www.asp.net when it's woefully out of date?

There are also the questions of designer implementation.  In VS.NET, prior to 2005, the ASP.NET designer was based on the MSHTML control which had some obvious pluses but some considerable minuses as well, for example, the the well known formatting issues (which btw, Microsoft recently stated at VS Live took 3 developers 18 months to solve).  In VS.NET 2005 use of (at least the publicly available version and no I have no idea if they are using an internal version of MSHTML or perhaps the Front Page designer or even a completely new designer) of the MSHTML control is no longer part of the designer.  In light of the recent IE7 announcement I wonder if any of the MSHTML editing issues will be addressed since they may not be important now their own designer has parted ways?

There is also the argument that if the WinForms designer had never been released all this would be moot.  Right?  That's hard to say but it wouldn't be hard to believe other vendors would have joined the party if these other designers were available today.  Take SharpDevelop for example, without the WinForms designer it might have been little more than a code editor/debugger then again, maybe not, but the forms designer does make it a lot more appealling.

Where to from here?

Fortunately, since Borland has already made the “more expensive“ decision regarding the ASP.NET designer it will be less work for us to move to 2.0 than it would have been otherwise.  In fact, we've already made some good progress.  Additionally, since we own the designer we've had the ability to extend it with things like the Tag Editor and in the 2.0 timeframe we'll have the same opportunity.  Hopefully, we won't have to make the “more expensive“ decision regarding some of these other designers.

In the long run, perhaps it will boil down to whether or not Microsoft is interested in an active third party tools market with companies really extending the reach of the platform rather than reinventing the various designers required to even play in the same sandbox.  Just as Firefox has pushed Microsoft to update its admittedly lagging web browser, competition in the tools space can equally push Microsoft's own tools and thus their platform, which in the end is their real win.  Let's hope some of the people responsible for the WinForms designer decisions can influence some of these other critical areas of the .NET world within Microsoft.  Avalon anyone?