June 2003 - Posts
Java SDK 1.5 (code named Tiger) is going to support variable length argument lists. In C#, this is accomplished via the params keyword. In Java, they are going to use an ellipsis token.
Posted by Keith Wedinger on Fri, June 6, 2003 @ 6:07AM
[sellsbrothers.com: Windows Developer News]
Yeah it's pretty lame because, as far as I can tell from reading the specification, you can't strongly type it. So it's always going to be an array of type Object as opposed to .NET where the params argument can be strongly typed.
So let me start my own little possee here and cry: Say No to inline schema definitions in WSDL! Import is your friend....
[Commonality]
I'm with Tomas on this one. Schemas should be written as standalone documents and then be imported into the WSDL document. Not only is this easier to manage for the developer writing the schema and WSDL, but it's also easier for those who have to grok the two.
Besides, the service you're writing the WSDL for probably isn't the only thing that's going to need access to the types you define in the schemas.
This was posted to the DOTNET-CLR list this morning. MS has released some Power Toys for VS.NET 2003. There are two that jump out at me as extremely useful:
- Custom Help Builder: Enables you to integrate your XML comment documentation into the IDE so that it comes up with F1, Dynamic Help, etc.
- VBComments: Yup, you guessed it! VB.NET people can rejoice at having support for XML comments in their favorite language.
Anyway, be sure to check them out. Naturally they're unsupported, but that shouldn't be a problem for most people. Also, some of them come with source code so you can learn how they integrated with the IDE and even make modifications if you like.
Update: Just noticed this entry about the VBComments Power Toy being a little flakey. Once again, use at your own risk.
This has come up on the DOTNET-WEB mailing list a couple times lately and I figured I should make an entry about it to help people out in the future. I was actually surprised that this wasn't covered in Fritz's book.
Unlike Windows control resources where it usually makes the most sense to package your icons, format strings, images, etc. into an assembly, Web controls have to deal with emitting URLs to their resources so that the browser can go fetch them. The ASP.NET people at Microsoft realized this and provided support for it within the System.Web.UI.Control class.
The problem:
You're about to write a control that needs to emit HTML that has an img element in it. How do you generate the value for the src attribute such that if the control is hosted on a web page located at the URL /foo.aspx or the URL /someApplication/bar.aspx the control still emits the proper URL?
The solution:
Luckily the ASP.NET developers at Microsoft were smart enough to catch this potential problem and they supplied the Control class with the TemplateSourceDirectory property and the ResolveUrl method.
Using these properties it is possible to solve the external resource problem in an elegant fashion that requires the same xcopy deployment as your control might. First, you can override the TemplateSourceDirectory property to return the following type of URL for your control: ~/Company/Controls/SomeControl. The ~ is a special indicator that tells ResolveUrl to prefix the rest of the supplied URL with the current HttpContext's HttpRequest::ApplicationPath value.
Example 1
If the control is hosted on a page /foo.aspx, then / is your ApplicationPath and a call to ResolveUrl for ~/Company/Controls/SomeControl would simply resolve to /Company/Controls/SomeControl.
Example 2
If the control is hosted on a page /someApplication/bar.aspx, where /someApplication is explicitly configured under IIS as a standalone appication, your ApplicationPath is now /someApplication and a call to ResolveUrl for ~/Company/Controls/SomeControl would resolve to /someApplication/Company/Controls/SomeControl.
Now, you might be tempted to forgo using the ~ in your TemplateSourceDirectory URL and instead make the control's resources global for the entire server on which it's installed. By all means this can be done by forcing the control's resources to be installed at the root site and returning a URL like /Company/Controls/SomeControl (note there's no ~ prefix). The major problem with this is versioning as sub applications might need to use different versions of the control and then you would be forced to come up with a versioning scheme for your control's URLs (i.e. /Company/Controls/SomeControl/v[Major].[Minor].[Build].[Revision]). This would also defeat the whole xcopy deployment scenario because now you can't just pick up a whole directory and move it somewhere to deploy the application. Instead you have to worry about moving the control's resources into an entirely different directory. As a final deterrent to using this method, consider the web farm scenario where the person that might be using your control doesn't have any control over the machine and can't get resources into the root application.
On a final note, in the above example scenario I used an img element's src attribute as a example where a URL might need to be resolved, but obviously this goes for any external resource (i.e. stylesheets, scripts, etc.). Also, since the System.Web.UI.Page class ultimately derives from Control, it also supports these features. When might this be useful? Well, consider the scenario where all pages in an application may derive from a custom base Page subclass which might render some portion of the HTML itself, this can be just as useful since the base Page subclass has no idea what the URL of it's subclasses may end up being.
Ok, I admit I've been slippin' with the whole weblog as of late. I was pretty busy for the better part of last month putting together our first web service which went live just about a week ago. I called it the Mimeo Simple Order Request (SOR) API. It exposes only a small subset of what is truly capable within our system's internals. As the name suggests, the API enables authorized accounts to place simple orders with our system and query the status and package tracking information of those orders. This project came around rather quickly and needed to be finished in a short amount of time. I literally had the WSDL and XML Schema for the project done in about two days, with only minor tweaks over the course of the next two weeks. We used ASP.NET, of course, coupled with the WSE SDK for the implementation. The WSE SDK was leveraged mainly for its implementation of WS-Security, although some of the other features (e.g. tracing) also came in quite handy. I chose WS-Security over a custom authentication scheme because I wanted a standard that I could just point developers from other companies at when they need to write clients to communicate with the service. Plus, why re-invent the wheel?
It was a super smooth experience. There's one thing that I just have to make a point of and that's that I completely agree with the whole "WSDL First!" movement. The best thing to do is forget about (ASP).NET when you're designing the API and think in terms of pure XML messaging. Once you've got that nailed down, then you can worry about how it maps into (ASP).NET.
More Posts