September 2005 - Posts
I just finished packing for my quick trip down to Seattle/Redmond for the MVP and AspInsiders summit this year. I will be back on thursday next week.
Its a short drive for me (luckily), only about 3 hours, so I should be in at around 11am and all checked in for 12.
I'm staying at the W. and will be meeting a few folks in the lobby at noon tomorrow, we are planning on having a quick beer (or whiskey) then head out to the opening day for registration and all the rest of the fun. So if your there get to the W's lobby for noon.
Over the weekend, I threw together a Flickr Gadget for http://www.start.com/pdc It simply pulls out a random image from a random Set from any Flickr account. You are given an option to give the email address for your account when you first load up the gadget into the page.
Follow the same instructions as I put up for the Google Search Gadget here for installation, except use this XML document:
http://www.mscorlib.com/gadgets/flickr/flickr.xml
It hasnt been tested much so if you see any issues let me know.
Since I prefer Google's searching over what Microsoft currently has to offer I decided to throw together a quick Gadget which plugs into MSFT's http://www.start.com/pdc/ portal.
Here is a screen shot of the Gadget.
I wanted to keep things super simple since this is my first Gadget. Here are the steps that you would need to take to integrate my Gadget into your page:
1. As per the "Getting Started" document on the Developer site, you need to change the setting on how IE access data sources across domains. Here is the excerpt:
"Note: In order to develop locally hosted gadgets within IE ensure that you have set the 'Access data sources across domains' setting to 'prompt'. You can check this through tools -> internet options -> select internet zone and click on 'custom level' -> under 'Miscellaneous' select 'prompt' for 'Access data sources across domains'."
2. Next you will need to add my Gadget into you feeds and gadget list:
a. Navigate to http://www.start.com/pdc/
b. On the top left, the "start" logo, expand it and pin it down
c. Now click the "add feeds and gadgets" link
d. In the "Add Content" dialog that pops up, paste in the url to my Gadget: http://www.mscorlib.com/gadgets/google/google.xml
e. Hit Subscribe
f. You can close that dialog now, by the X button on the upper right
g. Under the "My Web" section in the "start" box on the left you should see the Google Icon, and next to it "Search", click that link
h. It should prompt you if you want to install this Gadget. Accept it and make sure you hit the checkbox labeled "Save" as long as I use this Gadget" at the bottom and then hit the "Install Gadget" button.
Here is a screen shot of what I'm talking about.
i. This should show the default search form in the dialog.
j. Click the "Add to my page" link on the top right of that dialog to add that Gadget to your start page, and you can re-arrange it wherever you like.
3. The source can be found here (http://www.mscorlib.com/gadgets/google/). Its just a basic XML doc. and some simple javascript so dont be scared. Just in case you want to install it locally and play around with it. The getting started page on the developer site gives instructions on how to do this. It does require a local web server.
I wonder what MSFT has planned for this stuff. Third party's selling off individual Gadgets/Modules to subscribers? It would be kind of cool to be able to plug-in my own custom Tasks, Notes, Calendar Gadget on my favorite public portal site(s).
How long will it take to see an Outlook Gadget which does all the Ajax stuff for its features then it is just a matter of data synchronization to Exchange Server or something. The whole 'Access data sources across domains' is something that will need to be worked on, but I guess they can just put it onto the end user to make the decision. Authentication, well we would need some level of trust with sites like this.
At last Microsoft has released an early build new AJAX libraries based around version 2 of their .NET Framework.
Skip this next section if you are already familiar with what AJAX is and don't want to read my lame ass description of it.
The most basic intro to AJAX…
Essentially AJAX is Asynchronous JavaScript and XML. At the core of it all what you get is the ability to use JavaScript to talk to the server asynchronously (meaning behind the scene in your pages, without tying up the interface).
A practical example would be if you had two Combo boxes. Country and State. You drop down Country and State automagically populates with the appropriate states for the chosen country, of course this happens without pre-loading JavaScript on the client, nor doing a post back to the server directly.
Typically at the core of any AJAX library we see something along the lines of first creating an instance of the ActiveXObject "Msxml2.XMLHTTP", and then using it to make the calls back to the server, asynchronously. Don't be afraid when you see "MSXML", see this post regarding cross platform support. Once the call has been completely the library usually bubbles the event back up to the method you state.
For more details and a 100x better description see this doc.
So now you know what AJAX is, what do I have to say about it...
I have taken the time to quickly review the QuickStart and the core Atlas Documentation. http://atlas.asp.net/quickstart/ http://atlas.asp.net/docs/default.aspx
I don't want to cover everything that is stated in both those documents you can read them if you like. I intend to just cover the highlights and give my thoughts on what I'm seeing.
OOP:
So the first thing we see is the fact that Microsoft has put allot of thought into the OOP aspect of programming (thank god!). We see that we get some tools for allowing Namespaces, Inheritance and Interfaces. You can literally register namespaces with the Type system on the client setup a class hierarchy and even implement interfaces. The syntax looks a bit strange but I'm sure we can adapt.
ASMX Support:
Next we see that they have enabled the whole ASMX Web Services goop to be easily accessible for us. Simply create your ASMX Web Services as you normally do, and then use <atlas:Script> blocks to include the common JavaScript libraries including the AtlasRuntime.js. I'm sure those includes will be cut down to one prior to RTM. I cant see any reason why we would need to have 3 JavaScript "include" blocks just for Web Services support or for simple AJAX support on the client, let the server determine and control exactly what support JavaScript it needs to pump out.. I immediately notice that their default library script is approx. 137KB, not sure if that is a very reasonable size but time will tell.
What's cool is this next line:
<script language="JavaScript" src="SimpleService.asmx/js">
Notice we simply need to point it to our same old ASMX service with the /js modifier on the URL. Here is the full URL in their help doc for the output of the "SimpleService.aspx/js". Notice it is simply emitting JavaScript out of the service. It would seem logical that the src attribute of the script tag above can be any sort of fully qualified URL, including offsite url's, but I don't see that stated anywhere in the help. Also, it would be nice to see some sort of a wrapper for non .NET services, to automatgically wrap up a simple WSDL with the appropriate JavaScript. Maybe they could add a /out:js parameter to the WSDL.exe command itself? We then could simply include that script as our source instead of the .asmx/js directly. If they don't enhance the wsdl.exe tool directly I would be willing to put money down that someone in the community will have a tool publish in the coming months prior to actual RTM.
Serialization:
As we expected, we can send and receive complex types via this toolkit. I wonder what serializer is used. The SOAP Serializer seems obvious for those calls to an actual Web Service endpoint, but what about non-Web Service endpoints? I hope we can just use typical/raw XML with out the SOAP bloat (envelope, body, etc). For SOAP Envelope's do we also get header support? Oh, I don't see any example of getting nor setting data with a DataSet. I bet you that this will be baked in as well. I personally limit my use of DS's but MSFT has pushed them onto us so much that most people do use them and you can expect support for them.
Caching data received from an ASMX's seems pretty obvious. Do it on the server as we normally have done in the past.
DataSource:
Exposing a DataSource for Atlas to consume is as easy as pie. Take a look at the examples, some really amazing stuff going on there. Setup your service to inherit from "DataServer", implement the required methods; add the atlas:DataSource control to your page, point it to your DataService (asmx); add some control (for example a atlas:ListView control) and point it to your DataSource then wire up the events like click and such. A simple three step process to wire it all up, now that is what I like to see.
ASP.NET Atlas Controls:
This is where things start to go downhill. It would appear that the Atlas team has invested in an extensive library for markup of our client sided forms. The sections of code marked under "<script type="text/xml-atlas">" and "<script type="text/xml-script">". I personally don't like this direction. What are they thinking!? Currently, we have an object model for markup and event handling for controls on the server and now they want to add a completely new model for the client?!
Why could we simply not take advantage of this "runat" attribute on our server sided controls and let the framework put it all together for us? runat="client"
I understand that this stuff is (probably) not going to be included directly in the framework, v2, and will be shipped as a separate install, but come on guys! Another completely separate Object Model? Is that really necessary? How many will actually use this? Is there plans to actually include it in v3 of the framework?
With the coming of XAML we will see yet another object model. That brings up my next point…
My style of Adaptive Rendering…
I have a great idea, which I stated many times already. Let's leverage this whole .NET Framework thing and create rendering engines. That is, this now called "adaptive rendering" we see in v2 for Web and Mobile controls, let's extend that right out. Have a single set of controls which us hard working developers need to learn and Microsoft, you build us rendering engines for each platform: Web, Web+AJAX, Mobile, Windows Forms, etc. If someone hits our URL with a XAML browser (essentially a Windows Forms client) render for that request. If they hit with Netscape 2, render old school Web, etc. I hit with IE7, render for it. Let's avoid tacking yet another object model into the mix.
Server Class Library:
First thing that stands out is the Microsoft.Web.Services.Converters.DataSetConverter. As I suspected it looks like they will be baking in some support for DataSets. Along with that it appears that we will be able to create our own Converters, just based on the Microsoft.Web.Services.JavsScriptConverter. Nice to know.
Here we get to see all of the control classes which are currently exposed to the client. Nice big list, unfortunately its an entire new set of controls we will have to learn. Boo!
Browser Support:
What I would like to see as another final deliverable is a cross browser support matrix. I want to know exactly which feature is and is not supported on each and every (semi)popular browser on the market today, their versions and on alternative OS's. Scroll down on this page to get an idea of what I would expect. I think if MSFT really wants the industry to adapt this technology they will need to prove that it has a wide support base in the industry. Given this matrix it would allow us to really narrow down our browser/OS targets and enable us to make a more educated decision.
This will be my last post, on this blog, regarding my adventures with the Google Desktop and its plugins with .NET. If you care, read the reason here.
If your looking for any plug-in described on this blog for GD, check out the new blog at http://gddotnet.blogspot.com/
Did you know you have more than one Watch window in Visual Studio .NET 2003? A co-worker was grumbling that there was no simple way to just pull up the watch window with a keyboard shortcut -He's a VB guy, not used to having more than one Watch Window. I usually just use the Quick Watch (Ctrl-Shift-Q in my settings) so I dug a bit into the shortcut for Watch windows for him.
Here is the solution…
Go into Tools, Options. Choose Environment/Keyboard. Scroll the list box in the middle of the form on the right, down to "Debug.Watch1". You will see the keyboard shortcut for bringing it up. Notice there is also Watch2, Watch3 and Watch4 as well. Now you can group your watches into separate watch windows for specific areas you are debugging.
By default, mine is Ctrl-Alt-W, 1 (Global).
This means that in order for me to bring up Watch Window #1, I hit "Control-Alt-W" all at the same time, release and then hit the number "1" key. Oh, the "Global" means that this applies to anywhere in VS.NET. The watch window will only appear when it is relevant to do so, like when your actually debugging the application.
Happy Debugging!
I know it's already too late but I want to get my comments in now regarding Microsoft's new OS, "Longhorn" aka "Vista". So here is my wish list, take it as constructive criticism if you like…
1. Fix this whole copy/cut/paste/delete crap. If I choose to copy a folder, and say one file about 3/4 the way through is locked for some reason, it breaks the entire process. Why!!?? Why cant it simply resume/abort/retry copying? Now I have to go find that file and start the entire copy process over again.
1a. The whole "Yes to All" button. Make it work or don't give us the option. It seems that it is scoped at a folder level. That is, if you hit "Yes to all" it will apply that decision to the current folder and its items. It would seem this button should apply to the entire operation.
1b. Threaded?! Take advantage of faster machines with faster drives! Here's an idea. Take the top 3 HTTP/FTP download managers and simulate their behavior. Have it run in "silent"/"end user" mode which emulates the current behavior and then allow us to turn on the full display if we like it. Viewing all the current threads copying/moving each file, be able to pause/resume/delete/overwrite each action, etc.
1c. If I'm deleting a file, which has a lock. Don't you think it would be good to let us know exactly what has it locked? Wouldn't that help us correct the issue much faster? Give us the "Abort, Retry, Skip"/"Cancel, Retry, Continue" set of options or something.
2. The Shell. Oh that nasty little shell. How much I have resisted it over the years with replacements (http://weblogs.asp.net/rchartier/archive/2003/03/26/4298.aspx and http://weblogs.asp.net/rchartier/archive/2004/02/25/79930.aspx). Microsoft please let your shell assimilate me! All I ask for is .NET integration in some form (dogfood!?). Be it plug-ins like the Google Desktop or some other fashion, I don't really care. Just allow me to customize it and get it the point of being productive with it. I know your current shell is really targeted to the casual end user who likes the idea of "Start"ing at the sample place to find things. But what about us power-users (and beyond) that need more control over our environment.
Take a look at my blog these days. The majority of the last posts are all related to improving my desktop experience using a competitor's product! I don't want to have to use the Google desktop its just more crap to maintain. You guys need to work with me here…
Lets hope that fancy SideBar makes it into production!!! http://channel9.msdn.com/ShowPost.aspx?PostID=95433
http://blogs.msdn.com/tims/archive/2004/08/20/217893.aspx
3. Make shell extensions much easier (IFilter?). The whole COM Interop goop is a mess and very difficult to get to a solid working product in .NET
4. Don't worry so much about RSS, its cool and all but let the rest of the world take care of readers. We need more aggregation and features that do not need to put into any sort of OS.
Here is some more ideas from others…
5. Network resources. When navigating to a path, \\shar\folder instead of \\share\folder I want to be able to hit a Stop button. Instead of waiting for the process to simply time out on the bad computer name.
6. Right-Clicking. Sometimes the right-click menu is slow to respond. In some cases when it does appear, it simply hides right away. Now right clicking again causes a big delay. Fix it!
More Posts