Does anyone know if this script will continue to have a future or is it DOA and being replaced by another component? I use its functionality a lot and would like to know if there is a better alternative or what the future holds for it...
To clarify, I'm talking about the async loader features in start.js.
None of the ASP.NET Ajax Library (not to be confused with ASP.NET AJAX) was officially released and development on it ceased before it was complete. You shouldn't use it. I've wrote an article on the subject.
The same team at Microsoft has produced a new script loader, DeferJS, which is the next logical evolution of Sys.require. You can find the latest version of it here: https://github.com/BorisMoore/JsDefer
There's not going to be any further development on sys.require, but the existing scripts and services will not disappear. Microsoft has taken considerable measures to maintain backwards compatibility with its older technologies, so there's no reason to think that what you have working now will suddenly stop working at some point in the near future.
Microsoft seems to be going in the direction of integrating with the open source jQuery library. Here's a blog post about it: http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx. jQuery is very powerful and flexible, and has both built in support as well as a plethora of plugins for AJAX.
There's also RequireJS (http://requirejs.org/), which is quite mature, and somewhat easier to use. It's not from Mircosoft, but it may be worth a look.
May be you can try this
it is an extensible resource loader, and it does dependencies tracking.
Related
DukeScript looks like a life saver for we Java guys! I am considering it for a serious project. Was curious to know whether it's production ready and well documented. Also, liked to know what would be the best way to support routing in a web application.
I asked this question at the official google forum, but didn't get a reply. So, thought to re-ask here.
Here's a blog post with a little example. It shows a simple integration of location hash based routing with knockout templates. The full example code is available on github.
You might also use one of the javascript libraries like sammy or pagerjs, which would require integration with these frameworks, but I wanted to keep it simple.
Microsoft recently announced their Facebook SDK.
http://msdn.microsoft.com/en-us/windows/ee388574.aspx
Has anyone tried using it with ASP.NET or ASP.NET MVC ?
Would like your opinion. Any gotchas that developers need to be aware of ?
Michael
This is version 3.0 of the SDK. I've been using an earlier version and am in the process of upgrading to this new version.
Your question is very vague. What kind of gotchas are you expecting? There are so many pieces of the Facebook API that it's hard to speak to what your experience will be. What's stopping you from giving it a try yourself? You'd probably learn more from a few hours of building your own app with the SDK than anything anyone would be able to tell you here. If you get stuck or something doesn't work, then post your code and/or specific question and we'll do what we can to help you.
I am working on an ASP.NET MVC app using this library.
I have not used a whole lot of the functionality of the library since there are only two MVC specific class. An Controller Extension for getting a facebook api object, and an Action decorator attribute.
I have run into quite a bit of trouble with the methods in the Facebook.Rest.Data namespace.
Namely getting and setting Cookies.
Not sure what the deal is with this but it has been frustrating. And if it was not required by the client I would probably try and find a different library.
I'm planning a ASP.NET project for which I'm going to use AJAX. I'm researching all the available technologies for doing so in the .NET world.
I need a solution that is well documented and stable.
The current solutions I've found are:
1. ASP.NET AJAX UpdatePanel
2. ASP.NET AJAX with Web Services + JQuery
3. JQuery + Http Handlers
In the second and third solutions the backend would only send JSON or XML messages to the client.
In my experience the best way to go is JQuery with WCF with JSON webservices.
The reason is:
ASP.NET ajax is gives you alot for free in terms of coding but is bloated from the start and needs to be stipted and slimed. On the other hand you have JQuery that you needs more development but is light weight. JQuery has a great plugin library as well.
XML is to slow, JSON is fast.
Thats how I would do it today.
All will work but I've had most performance and stability with using JQuery and a script service.
An update panel will work but as its designed to work in the general case it can be a little bloated if you aren't careful. One reason being is that it posts the viewstate back with each update.
I recommend you check out the site: encosia.com as it has a number of posts on how to use script services and page methods. Then you can make a more informed decision. I would say that I've not used page methods and probably won't but that's entirely for personal reasons.
One other thing to consider will be any mvc you may end up doing. The general consensus is that it's a whole lot easier with JQuery. Added to that Microsoft have officially adopted it and also provide intellisense in VS2008.
All compelling reasons to include at least some of it in your project. In mine I only use the built in ScriptManager when I absolutely have to.
HTH!
S
We are developing a CMS in ASP.NET. We love the idea of add-ons (like in Wordpress, where any developer can add a menu button or a widget) and would like to enable developers to do the same with our system.
However I think that the fact that C# is a compiled language is an obstacle in the way of add-ons.
Am I right? Or is there a way to create add-ons for a ASP.NET application?
The fact that C# is a compiled language isn't a problem at all. In fact the .NET framework should make it relatively easy to load other code (just as Java does, for the same reason). Look into the Managed Extensibility Framework, which is all about loading Add-Ons in managed code.
It's not an obstacle at all. MEF has already been mentioned, you could also use:
System.Addin
Mono.Addins
I'm not sure for ASP.NET specifically, but in the only compiled programming language I know (Objective-C/Cocoa), there's the concept of Bundles that can be loaded dynamically. I'm not sure how that works on the backend, but I'd guess that there is some similar system for C#/ASP.NET.
I don't know how it's done in Wordpress, but there should be many ways. You can allow developers to upload their assemblies with compiled code or you can allow them to upload code in C# or IronPython or anything that supported and compile it dynamically. Maybe you can use WebParts for your task.
Microsoft has created the Managed Extensibility Framework (MEF), specifically for this problem: providing .NET plugins for .NET applications. It is the framework that (future versions of) Visual Studio use for writing managed plugins.
However, please consider using a dynamic scripting language for this! Problems like this are exactly what they are specifically designed for. If you host the Dynamic Language Runtime in your application, it not only means that your users can extend the application in a scripting language, but even in any dynamic language (scripting or otherwise) for which a DLR implementation exists: Ruby, Python, Smalltalk, Scheme, JavaScript, PHP, you name it. Biggest disadvantage: the DLR hasn't been released yet.
In C#, you can create any assemblies, link them as DLL files and then do whatever you want.
The usual case would be to define some kind of Plugin Interface which must be implemented by all the plugins.
Then you can load all plugins from the filesystem (by iterating over the plugin DLLs), find the class inside which implements the interface, instantiate it and work with it.
If you want to provide plugins with unloadability and security, you could create an application domain and load the plugins to that, increasing complexity, but also increasing stability (a bad plugin won't crash your app).
Please ask more specifically if you want a specific answer :-)
It's not too difficult to put hooks in place. You have to define in advance where the add-on features will appear. For example: when drawing a menu you can use reflection to search other dlls (with specific names and locations) for a "BuildMenu" function. You'll be defining the API for this function signature. It may have to return a list of items to be added to the base menu items collection.
I am recently in charge of an older app written in C# using asp.net 1.1.
Are there any resources to guide me in converting the application to a newer version of of the .NET Framework.
My main pause is that there are ton's of customized DataGrids in the app as it is written now and since so much of the code needs to be rewritten to use GridViews ...
is it worth trying to convert the grids in the application to use Silverlight in the attempt to move this code into the future.
I had a similar experience, and the only thing that we had to replace was a third-party control that we were using in the 1.1 app, and the vendor had gone out of business an never released a version that worked with .NET 2.0. We ended up replacing it fairly easily with an AJAX Control Toolkit control.
Other than that, the compiler does a pretty good job of telling you what to do with respect to deprecated method calls.
I'd suggest making a copy of the code and upgrading the site in Visual Studio and see what happens. Just open the solution in Visual Studio 2005 or 2008, the IDE will walk you through the upgrade automatically. Get it to compile, then if you have any documented tests you should run through them. If not, you'll want to plan testing to make sure all your functionality still works like it did before the upgrade.
Migrating to Silverlight sounds like fun, but if you can get it upgraded and working, I'd probably push that off until a later release -- my experience tells me that you might get into trouble if you bite off too much at once if there is no show-stopping technical reason.
This MSDN document may be useful to you as you upgrade your application, it contains lists of breaking changes between 1.1 and 2.0, and work arounds for resolving them:
Breaking Changes in .NET Framework 2.0
I would suggest that as part of the upgrade you opt to move to a Web Application Project rather than a Web Site Project, as the former is conceptually similar to the VS2003 web project model.
Here's a nice short post summarising the differences:
http://maordavid.blogspot.com/2007/06/aspnet-20-web-site-vs-web-application.html
As others have said, don't worry too much about the DataGrids, the upgraded site should be backwards-compatible in this respect.
Regarding DataGrids - I don't think you have too much to worry about, DataGrids still work in current versions. It's just that going forward, you should use GridViews.
I am sure there are other things you may want to check into though, deeper framework issues. But I don't know enough about those things to speak to that particular point.