Due to a security requirement all browsers that will run a web application we need to create must have all client side scripting disabled. So that means no Javascript.
Unfortunately Web Forms make quite some use of Javascript. The login control works without Javascript, but a button does not (it calls the Javascript function __doPostback()).
So to make it work we'd need to program all the forms by hand (the ASP Classic, or PHP method). But I was wondering if there is a framework available for ASP.NET that offers the normal ASP.NET controls (treeview, gridview, etc) with all the functoinality they have, but that doesn't use Javascript and doesn't require the programmer to program massive amounts of logic?
Update:
For clarification, I know ASP.NET MVC is an option that will help a bit, but it won't give me a nice GridView. So I'm wondering if there is a 100% functional, 100% no-javascript replacement for the standard ASP.NET controls.
Thanks.
Update2:
It's been a while and I never found the exact answer I was looking for. Probably because what I want doesn't exist. So I'll go for ASP.NET MVC which is the next best thing.
ASP.Net MVC is probally the closest you'd get. You can use it to build a site without javascript. It is very different from Web forms
Many of the stock controls will be problematic. They just depend too heavily on Javascript. You do have some options, though:
ASP.Net MVC should give you a bit more control over your html
You can build your own replacement WebForms control library that doesn't rely on javascript to provide alternatives for controls that do.
Related
I have experience in javascript, html(Bronze certified), css(Gold certified), sql and xml(Bronze certified), and now have turned my attention towards server side scripting. I have little experience in php but have no Idea what to choose between MVC and ASP.NET Web Pages. I like all the features that ASP.NET Web Pages(Since I already new a little about server side scripting, so getting started was not that difficult and I know a few basic things.) have like, automatic form authentication among others but I seriously doubt that it can never be by-passed. Still, for safety I use my own algorithms against sql-injection and javascript codes. But, now I am confused what to learn, MVC or ASP.NET Web Pages. All the posts I searched on internet where for new programmers. Since I am not new they are no use to me. So what should I learn MVC OR ASP.NET Web Pages and why?
*English is not my native language, there may be some grammatical mistakes.
You are kind of asking what's the better option, apples or bananas. MVC is a pattern and allows you greater control over what HTML is sent to the browser whereas Web Forms has a great number of pre-made controls that do all the hard work rendering out html to the browser (but often less control of how it is rendered out)
It's also down to preferences, I personally prefer MVC as the unit testing and component nature of it give me great flexibility. Alternatively, using WebForms you can create some things quickly using drag and drop controls.
Hope that gives you a bit of useful info. I'd recommend reading up about both, and seeing which fits into your style of programming and go from there, but there's nothing stopping you learning and using both (just don't use them in the same project, lol)
During the last 2 years JQuery has become more and more popular. So do you think, it is now time to prefer JQuery to ASP.NET Ajax in ASP.NET projects with Ajax? Has the ASP.NET Ajax Control Kit a future in the ASP.NET world?
Short answer:
If your page/site isn't currently depending on the UpdatePanel or ACT controls, definitely use jQuery and jQuery UI for any new work. That's even Microsoft's own recommendation now.
Long answer:
It's important to be clear about terminology when dealing with this topic.
ASP.NET AJAX is part client-side, but also part server-side. System.Web.Extensions came from Atlas and was eventually integrated into ASP.NET 3.5. Even if you don't use a ScriptManager or MicrosoftAjax.js, the server-side portions of ASP.NET AJAX are still very useful for creating JSON-based server-side endpoints (and those may be called directly from jQuery, with no ScriptManager).
jQuery and MicrosoftAjax.js are somewhat similar, but both do things that the other doesn't. It's not strictly accurate to say that they compete with each other; they have different goals. If your application has any UpdatePanels, you have no choice but to include MicrosoftAjax.js (which is coming in automatically with the ScriptManager). jQuery and MicrosoftAjax.js do play nice together though, so you can still use jQuery's more powerful selectors, traversals, and animations in conjunction with UpdatePanels if you must.
The AJAX Control Toolkit (ACT) is a different project, entirely separate from ASP.NET AJAX. It most directly compares with jQuery UI, not jQuery core itself. Going forward, I think we'll see most of the client-side-only AJAX Control Toolkit controls refactored as jQuery plugins (that already happened late last year, but they were pulled).
Ultimately, it's best to favor jQuery or jQuery UI over MicrosoftAjax.js or the ACT if an equivalent solution exists in both. However, if you're tied to MicrosoftAjax.js with UpdatePanels or other existing code, don't be afraid to mix jQuery with that and transition to jQuery slowly. They work great together.
jQuery is the more popular, mainly because it is platform independent, but it's a good system in it's own right.
I don't think that there is anything wrong with ASP.NET AJAX for those developing on Microsoft platforms either.
I've used both, but I'm erring towards jQuery now, mainly because of the resources and samples available out there.
Does that mean the MS offering is doomed? Not yet. It will exist for as long as a certain number of people are using it, but I think it will always play second-fiddle to jQuery.
If you are an ASP.NET-only developer, have a peek at both and use whichever suits you best. If you develop on different platforms, then settling on jQuery might be more advisable.
PS. there are other cross-platform AJAX frameworks out there also...
In my opinion, jQuery is leaps and bounds better than the Ajax Control Toolkit. The main reason for me is the great back-up the community has given it. Not only is the jQuery documentation on the web better, but by jQuery not being a .NET-centric framework, the community is bigger, meaning that anyone from a Ruby on Rails developer to a PHP developer can help you with your code just as good as a .NET developer, which would be obviously harder to find.
Other than that, I've had better performance than the Toolkit, and I find it a whole lot easier to write against and customize. And you got to love jQuery UI.
By the way, be aware that by simply enabling the ScriptManager on your ASPX page, your loading a bunch of scripts which add extra load to your page. Something to have in mind before mixing up jQuery and the Toolkit.
I think that ASP.NET Ajax Toolkit is using jQuery under the hood. (this is wrong).
You may use both. I guess it depends on what you prefer, because Ajax Toolkit provides controls that you can use server side, while jQuery will always be client side only.
So you'll probably use both : when a control exist in Ajax Toolkit and you need some server side properties / accessors, etc. use it, if you need some functionnalities that aren't provided by the Toolkit, use pure jQuery.
Microsoft is working with the jQuery community and submits some patches to them. So I guess they'll continue to maintain the Toolkit. Ajax Toolkit being only a layer over pure jQuery functions and providing server-side controls.
Update:
Interesting quotes from this blog:
However, with Visual Studio 2008
Service Pack 1, we also added support
for the ever increasing popular jQuery
library. That is, you can use jQuery
along with ASP.NET and would also get
intellisense for jQuery in Visual
Studio 2008.
And :
For client side programming using
JavaScript for implementing AJAX in
ASP.NET, the recommendation is to use
jQuery which will be shipped along
with Visual Studio and provides
intellisense as well.
For server side programming one you
can use the server controls like
UpdatePanel etc., and also the AJAX
Control Toolkit which has close to 40
controls now.
ASP.NET Ajax and the ASP.NET Ajax toolkit are two separate things. The toolkit is a set of ASP.NET controls (and some other stuff). It's server side code and some javascript.
ASP.NET Ajax is an application framework you can use to create and manage client side controls; it's Javascript. The ASP.NET Ajax toolkit is based on this framework.
jQuery and ASP.NET Ajax have some overlaps in functionality but they are by no means mutually exclusive. jQuery is mostly geared towards updating and manipulating markup. ASP.NET Ajax is geared towards providing an application framework.
Microsoft has recently decided not to compete with jQuery but invest in it because jQuery and ASP.NET Ajax work well together and complement each other. JQuery is actually shipped with Visual Studio.
So, to answer your first question, you should use the JavaScript lib best suited for the job, be that jQuery or ASP.NET Ajax.
Whether you want to use the Toolkit, that depends on how much you like wrestling with ASP.NET controls. If you're into lean-and-mean coding like ASP>NET MVC, I'd drop it like a hot potato. If your in a traditional WebForms project, the toolkit is probably as good as it's going to get.
At the moment I am starting to learn Silverlight. I have expriences in ASP.NET and like the concepts of "Masterpages. Does Silverlight provides a similar concept ? I have read a little bit about the Silverlight Navigation Framework. Is this a good replacement for "Masterpages" ?
Makes it sense to combine ASP.NET and HTML (with Javascript) with Silverlight or is it more recommandable to design and write pure Silverlight applications ? Mybe in the ner future I will start to develop an intranet (business) application which will have many and complex user interaction (it should behave like a windows client applicion). I think Silverlight is the better choice than ASP.NET !? Makes it sense also to start to use/learn the WCF RIA Services immediatly ?
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ? Unfortunately I am missing "Starter kits" on http://www.silverlight.net like the starter kits on www.asp.net !
Thanks in advance for your hints.
Silverlight and ASP.Net are light years apart technology wise, Silverlight is closer to Winforms programming than it is to ASP.net, event though it can be hosted inside an ASP.Net page.
To achieve "masterpage" type functionality, you can have a base control or page that you can inherit everything else from. Or you can have a page which acts as a shell and you can swap views in and out depending on the user's actions.
If you are writing an app from scratch, you can do the whole thing in silverlight. You can navigate from one silverlight control (hosted in an aspx page) to another aspx page (with silverlight controls in it), but there is a performance overhead when transitioning between aspx pages (they are web pages and need to be served). You should look to eliminate separate aspx pages if possible, and create it as one big silverlight application - if your application's functionality is all rolled into one application (not spread amongst aspx pages) then you can make the most of Silverlight's Out Of Browser feature.
However you should only consider silverlight if you are build web apps or interactive/streaming stuff. If your pages are going to be largely static (i.e. presenting product catalogs, or a site where the user just drills through from one page to another) then using silverlight would be overkill, you would be better off sticking with ASP.Net or ASP.Net MVC.
Masterpages does Silverlight provide a similar concept ?
Not directly but it does provide a variety of ways to acheive the goals of Masterpages. The navigation framework is mostly the sort of thing you would need to achieve the typical reason to use Masterpages.
However its also possible to achieve "masterpage" functionality more generally by creating a UserControl that has ContentControl instances at points where in ASP.NET masterpages you would have used a asp:contentplaceholder. These content controls would be bound to custom properties added to the UserControl. This completed UserControl can then be used as the "LayoutRoot" of another UserControl or Page. Note this does not require inheritence from the "master".
Does a combined ASP.NET and Silverlight app make sense?
Well thats a tricky one the answer really is, "It depends". There are way to many factors to give this a true answer. Factors:-
Is this a public app or an internal app?
How important are including rich UI features?
First time Silverlight dev will cost you, is your project able to absorbe that?
What client platforms do you need to support?
How might ASP.NET-MVC + appropriate use of JQuery size up against your requirements?
Probably others I haven't thought of yet
Is Silverlight is the better choice than ASP.NET when there are many and complex user interactions?
The phrase "complex user interactions" could mean a couple of things? Do mean complex to deliver with HTML and Javascript but simple for the user? Or is this a sophisticated app aimed at an expert user?
In either case its likely that Silverlight will start to come into its own here.
Does make it sense also to start to use/learn the WCF RIA Services immediately?
Yet again the answer depends of the type of application you have in mind. If its line of business app where data is searched, edited and reported on then (assuming you have decided to develop in Silverlight at all) definitely you should be looking at WCF RIA Services as well as the parts of PRISM that think are appropriate.
Other types of apps may not benefit from WCF RIA Services.
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ?
There are no start kits at present. However I think you will find what you need amoung the various demos and tutorials on the silverlight learning site.
I've particular found the videos useful. If you decide to go Silverlight its well worth clearing a day or two to got through the relevent ones.
These are a lot of questions at once.
Yes, the Navigation Framework functionality is pretty much equivalent to the Master Pages concept. Even to the point that it is tracked in the URL when users navigate, so they can use the back and forward button of their browsers.
If you want to do a stand-alone Silverlight application or a hybrid pretty much depends on your requirements and on the type of application you want to develop. If it's a Line of Business application, you might be doing fine with Silverlight alone.
For a public, content/text-intensive website probably HTML with some silverlight gadgetry here and there might still be preferable.
I am new to the asp.net world (but not new to .net) and I have been playing around with various things to see how I want to architect a web application I am developing. In my playing around I have decided I did not want to use asp.net's controls, as I have done enough php and ruby on rails to be decently familiar with regular HTML, and a decent amount of javascript.
I see a lot of comparisons between asp.net webforms and asp.net MVC, however when ti comes down to it I am not seeing that much of a difference (and I'll admit that it's probably me missing the differences rather than them not being there). I already have coded my asp.net application using a MVC type of architecture (aspx has the view, aspx.cs has the controller code, and models are separate classes in the app_code directory).
If I do not intend to use asp.net controls and just intend to use pure html and javascript, what are the advantages of using the MVC framework? As of right now, the only one that I am seeing is routing, and I'm sure if I look more I can find easy ways to do custom routing without using the whole MVC framework.
Anyways, if anyone could go into details of asp.net webforms minus the asp controls versus mvc framework, I would be greatly appreciated.
You're going to find a number of differences and reasons to use MVC over WebForms but it's going to depend on whether those differences are important to you or your project. Routing is definitely a big advantage for MVC. Although you can implement custom routing configurations in WebForms it's significantly less intuitive.
Another big advantage is unit testing. Along with an IoC container and a mocking framework, MVC makes unit testing a cinch. It's much easier to isolate actions and behaviors with MVC and test those specifically.
A third advantage is that MVC will help reduce the spaghetti code you're going to write. If you're not planning on using any User Controls then it won't be long before you're missing the HTML helpers in MVC. The Html, Url, ViewModel, TempData, etc make working with raw HTML much easier.
The inherent validation in MVC is also impressive. It's getting better in MVC2 and now with the integration with client side validation libraries it will save you a ton of time and add a lot of functionality.
No more VIEWSTATE.
There are many others but again it depends on whether those features are important to you. Good luck with your decision!
ASP.NET MVC is built on interfaces, which makes it extensible, easy to write unit tests for, and encourages clean, loosely-coupled architecture.
If you're using 'classic' ASP.Net without using any of the server-side controls, there's not much of ASP.Net that you're using -- it's basically classic ASP with .Net instead of VBScript behind it at that point.
Giving up webcontrols is the biggest reason not to use ASP.Net MVC. If you're fine giving that up, I'd just use ASP.Net MVC and be done with it. It's got all the parts you'd need to write yourself anyway, and the parts you don't like, you don't have to use.
In my playing around I have decided I
did not want to use asp.net's
controls, as I have done enough php
and ruby on rails to be decently
familiar with regular HTML
Thats not a good reason to decide against ASP.NET controlls. The importand thing about ASP.NET is Viewstate. It allows you to use event driven programming in Webapplications. This makes a lot of things very easy and productive.
Anyway - as you know ruby on rails I guess you will pick up ASP.NET MVC pretty fast.
First up, if you use ASP.NET MVC you'll be using a supported framework that has books, online resources and hundreds of blog posts surrounding it.
Second, I suspect you need to play with ASP.NET MVC to see it's power. There is way more than WebForms in ASP.NET MVC. For many, the fact that WebForms is optional (you can use different view engines) is a major plus.
For me, the extension points, the cleaner code, and the unit-testability of everything I do are major reasons to never go back to ASP.NET "classic".
My recommendation to you is to get a decent tutorial (look for the Nerd Dinner tutorial), play with ASP.NET MVC, and find out for yourself.
Note: ASP.NET MVC is not for everyone, and if you're heavily into the post-back mechanisms in ASP.NET, or have a heavy investment in server and user controls, then you might not want to take ASP.NET MVC right now. But for your next project you should at least know what your options are.
Looking at some of the changes coming to WebForms in ASP.NET 4.0 I can see many improvements that give developers even more control over the output. Some of these improvement have been a long time coming, and for some time it seemed that it wasn't even possible. It made me wonder if the current model with the single form element that runs on the server is really the only possible way.
Why couldn't the ASPNET WebForm architecture work with multiple forms that all run on the server?
Imagine if you could architect this change. How would it impact the way we write codebehind today? Would it introduce extra complexity? Would it change the way event handlers work, or validation, or ASP.NET Ajax with the ScriptManager and UpdatePanel controls?
I think .NET mvc is MS making the change you speak of.
From a ASP.NET book Im not going to mention because I'm not sure if I'm allowed to, it says that before with ASP you could put 2 forms in the same page so some people in the same webpage could put a form for authentication for registered users and a form for creating an account for new users, something you cant do in ASP.NET because of the limitation of the framework. So you should be able to do that again if they would add that possibility in ASP.NET
You can toggle forms very easily on the page level:
http://www.codersbarn.com/post/2008/03/08/Solution-to-ASPNET-Form-PayPal-Problem.aspx