Rants Tagged with “AJAX”
1 (Total Pages: 1/Total Results: 5)
In case you didn't catch it, I participated in a webcast called geekSpeak. This webcast was hosted by Glen Gordon and Chad Brooks. The topic today was "Silverlight and Line of Business Applications". While geekSpeak's usually focus on hands-on examples of creating code, we took a different tact today and discussed the larger topic of where Silverlight fits in the development ecosystem (at least Microsoft's ecosystem).
For my money, the real benefit in Silverlight is for applications that cross the firewall. This means Line of Business applicaitons are really for B2B and B2C solutions. Unfortunately, what I hear from the community is that people see Silverlight as a solution for porting their desktop and traditional 3-tier applications to the web. Is this a good idea? I don't think so. The problem is that desktop development usually involves business objects that tend to have a direct connection to the database. Moving these sorts of applicaitons to the web means that you need to create an extra layer of communications and serialization. There is a cost both in development and performance for these extra layers.
It comes down to a key question...why are you moving to a web model for your application? If you want to expand the reach of your application to more users and clients (outside your organization), Silverlight is still a great story. Unfortunately many organizations see web applications as a deployment solution. No install, no framework, etc. While clearly this isn't true for Silverlight per se, its also a bad reason to go to a web application. Technlogies like Click-Once and XBAP are a great solution for a better deployment story than traditional desktop applications.
Since I brought up XBAP, let's plug it a bit. I notice that even amongst WPF guys, XBAP is a lost story. If you're not familiar with it, essentially its an in-the-browser WPF applicaitons that is deployed via manifest files (e.g. like ClickOnce). This means you can have the richness of UI, the better data binding story and interactivity that WPF/XAML affords you without having to deal with the limitations of Silverlight. I suggest that many organizations that want to use Silverlight for internal applications (inside the firewall) should be doing XBAP instead.
So what about ASP.NET/AJAX? The big story here is that HTML-based interfaces still have the longest reach of all the Internet enabled applications. HTML just works on many more platforms and browsers than Silverlight or Flash. Before you commit to moving away from HTML-based UI's, spend some time with your server logs. Understand who is really using your existing application before you leave anyone in the dust. A better strategy is often to include fall-back functionality. For example, in my Silverlight Tour website (http://www.silverlight-tour.com), I decided that developers may have Silverlight installed so I wanted to give them a better experience by showing an interactive map of tour stops. But their bosses and accounting departments were unlikely to have it installed. In that case I made a design decision to never prompt to install Silverlight, but instead if it wasn't installed to show a simple table of the classes instead of the Silverlight app. This is a great solution to moving forward without leaving old users in the dust.
Why is Silverlight not a good solution inside the firewall? The two issues are infrastructure and security. In order to build solid line-of-business solutions with Silverlight, you need to have a way to communicate data with the server. Building this infrastructure can be labor intensive, but more importantly adds complexity. More moving parts == more than can go wrong. Security is the second issue. Silverlight (for good reason) is pretty locked down. This means you will need to often learn to work in tighter confines (limited access to storage, no access to file system, registry, ports). If your application is meant to work in trusted scenarios (e.g. Integrated Windows Authentication), the limitations of the high-security environment will be a real limiter.
So what does this all mean? I still think Silverlight is still the solution when you need to *extend* the HTML model in the browser. Line of Business applications across the firewall still need to be web driven in my opinion, but enhancing that story with Silverlight for soutions like data visualization, user interactivity or media is a great solution. While I think that creating whole-browser solutions make sense for some applications, it doesn't for many many more. My fear is that we will move from monolithic desktop apps to monolithic Silverlight apps. The web is still a disconnected model and deciding on building a single huge Silverlight app (instead of page-based functionality) just doesn't make much sense. If you are planning on building one of these monstrocities, please also read my recent blog about linkability in Silverlight:
http://wildermuth.com/2008/06/25/Doesn_t_Anyone_Bookmark_Anymore.aspx
Its been a crazy weekend. I've moved into my new servers at MaximumASP and I could not be happier. On the new server, I have full control over the box so I can make it work the way it should have. In the old system, I was doing all sort of re-routing tricks to host 8 sites under a single web site. It was a nightmare that made it difficult to use new technology (e.g. if the root site was using AJAX 1.0, I couldn't have one of the sub sites use 3.5). All that is over and hopefully you will see some new stuff on this site soon! .
Here comes the favor...there is likely some parts of the site that do not work as they did on the other server because I missed a file or two in the transfer...if you see anything that should work that doesn't, please email me at shawn@wildermuth.com.
One thing I noticed was that when using the VS 2008 Publish function, some files were inexplicably not transferred. It may have been the "Content" type or the Silverlight links in some of the project...I don't know. But I've attempted to find all the holes that the "Publish"'s missed but I could have skipped something.
Lastly, this new server has come at the kindness of Maximum ASP. They have graciously offered to give me a machine at a discount for my community sites including this one, GeekDinners.com, SilverlightData.com and SilverlightGuy.com (not all of these are active yet).
Last note: GeekDinners.com is almost fully functional. Look for an announcement this week when you can register your own GeekDinners and schedule event nights!
As some of you know I am writing an appendix about WPF/E for the new revision of Chris Sells/Ian Griffith's Windows Presentation Foundation Book. While editing the appendix, Ian Griffiths noted that using agHost.js file seemed like a good temporary solution, but that there needed to be an ASP.NET control that was smarter. This has been on my mind for the last few weeks so I finally spent a sleepless night writing a first version. This first version took some ideas and code from Mike Harsh's version found here.
For those of you who know how WPF/E SDK works, it uses a script called aghost.js file to emit the right tags (object tags for IE, and embed tags for firefox). I also had some other things I wanted from an ASP.NET Server Control. Here are the features I added:
- The right tags are emitted from data on the server. In other words if the Request is from an IE Browser, I only emit object tags. If it is FireFox, I emit embed. Same for Macintosh browsers.
- I wanted to be able to work with XAML files during development, but to reduce round-trips to the server, I wanted to be able to have the control embed the XAML in the page for me automatically.
- All the properties of the agHost JScript class to be exposed at the design-time.
- A full design-time experience allows resizing of the control, though actually showing the XAML in the designer is not supported.
- Design-time SmartTag is supported to help users pick crucial properties of the WPF/E host.
- To avoid a FireFox bug when using embedded XAML, I am testing the page for the XHTML DOCTYPE to alert the developer of the FireFox bug and how to fix it.
To use the control, you need to download the zip file and compile the project. I have not signed the control for simplicity. You can either add it to your toolbox manually, or simply add it to your project and add the control tags manually. You can see the tester website that is included in the zip file for an example of using the tag.
This is a 0.01 Release (very Alpha)! I spent the last six hours coding it so the XML comments are very rough and the tester only tests some obvious situations and I have not tested it under Mac's FireFox or Safari browsers (anyone who can, please let me know). I expect as the release of WPF/E comes closer, I will either continue polishing this or a Microsoft ASP.NET control will take over its features. Either way, it should make developing WPF/E easier. Please let me know what you think and what you like and don't like!
If you have bugs, please e-mail me at shawn@wildermuth.com and please include what version of Visual Studio you're using (only 2005 is supported right now, but if you have the Service Pack installed for VS and what add-ons like the VS Add-ons for WPF, WCF, etc.). Also what operating system your developing on, and what operating system your are deploying on.
UPDATE: I've found a couple of bugs, most glaring is that the "Click to Activate" bug on IE. It seems that if you construct the object tag, it has to be in script external to the page to avoid that problem. I still am not happy with the solution, but i'll let you know what I come up with.
Dan Wahlin has posted the code (though not a live example) of using Amazon, WPF/E and ASP.NET AJAX to do an Album Lookup Example. He has the code, a video of it working and a talk about how he created it up on his blog. Check it out.
I am delving into WCF and AJAX (not at the same time) lately so I wanted to see if they were compatible. According to this whitepaper on ASP.NET (follow the link and scroll down to "Support for WCF Web Services"), the RTM of AJAX does not support WCF. It seems they removed it so they could make it work better in a later release. The promise is that by the Orcas release of VS, they will be compatible.
This further cements my opinion that releasing .NET 3.0 without FULL tool and compatibility is nonsense. Without a good across the platform support (e.g. WCF and ASP.NET stack working well together), a workable WPF editor (Cider is horribly broken currently...change the default editor for XAML to XML, you'll be happier), and projects that actually compile out of the box (WPF projects don't compile currently without some hand-editing of the XAML). Microsoft has always been about tools more than technology, that's why I've been with them so long. If we need to cruft together a bunch of installs to make stuff work, I'd be doing that in Java and Linux.
It looks like most .NET 3.0 development should wait until late 2007 when Orcas ships...but that's just my opinion...
