Does JSON, JQuery & ASP.NET 2.0 webforms go together or is it only preferred in MVC with ASP.NET 3.5 & 4.0?
While using JSON, would gridviews and repeaters controls be of any use (binding with JSON data) or do I format the results in custom tables myself ?
Would my business object classes still be of any use while using JSON ?
What is the ideal combination for JSON with ASP.NET (JQuery+ASP.NET AJAX+ JSON) ?
5.Can anyone post me a link/code snippet of simple CRUD application with JSON and ASP.NET webforms ?
Thank you.
I would really recommned you to move on to MVC, since it is far more better than ASP.NET Webforms. but still here are my answers to your questions.
yes, they can easily be used together, and they will make user experience more richer than simeple ASP.Net.
You can use JTemplates, Mustache script and other scripts for binding with JSON data. and you would never require GridView or Repeater control for this.
yes, they would be useful to some extent. but most probably your business logic will be exposed on client side, when working with jquery, json and ajax.
your data will be in JSON format, and ASP.NET will be used as backend layer. AJAX will be used to call ASP.NEt pages/handlers to fetch data from database asynchronously. adn you can use jquery for manipulating data on clientside and then display on the UI.
Sorry, I could not find any such link over google. let me search more, I might find one to share with you.
a reminder:
Even the framework makes them look working in same scope, ASP .NET & javascript(jQuery, JSON) lives in thier own scopes. ASP .NET(back end) generate nothing more than html, css, javascript to browers(front end). Then, browers interpret the html, javascript, css. They don't really work together. Also, JSON is nothing fancy than a notation as its name(JavaScript Object Notation)
e.g.
code:
$("#<%= Textbox1.ClientID %>").val("mywork");
what really happens in html
$("#Textbox1").val("mywork");
I've used JSON & JQuery in an ASP.NET website quite successfully. (non-MVC)
You can bind JSON to ASP.NET elements, but I'm not sure it is worth the effort
Do you mean .NET objects? Check out System.Web.Script.Serialization.JavaScriptSerializer
You should take care not to employ too much interaction if you help it. Use JQuery for client side interaction only.
Related
I have Coldfusion web application that has a CF query from a database table. This data is displayed in an HTML table with a checkbox beside each data item and an associated picture. There is Jquery functionality on the page so that the items can be re-arranged in the table based on the users preference. After the user finishes with their re-arrangement, it is re-displayed without the checkboxes for sending as an email. Note I did not write this application myself but inherited it...
I need to transfer this functionality to a asp.net C# web application but i am at a crossroads on how to proceed. I've looked at telerik controls and others but none appear to fit the functionality i need. Any solid suggestions?
I'd suggest to handle rendering of the table yourself. If you're using asp.net webforms, this can be done with a custom server control. If you're using asp.net mvc (which I suggest as MVC matches the coldfusion development model a bit closer than webforms), then it's much simpler and you can just do so in the view.
Once you are rendering the grid yourself, then it's simple to apply the jquery functionality on the client-side.
Without more info about what you can or can't do, it's a bit difficult to offer any more guidance. But you did only ask for suggestions :-)
Asp.net doesn't mean you need to use a library control built for .net. jQuery is powerful enough today, and it's not tied to any back end technology.
So, that being said, I would still go with jQuery and back it up with RESTful request using webservices with WebForms or controllers with MVC.
Have a look at this: JQuery Drag and Drop features with ASP.NET
I'm dipping my toes into web development. Based on various bits of advice, I'm going to start by getting a handle on html, css and javascript.
I'm interested in Ajax, I've had a look at the client side code and that looks straight forward enough, I'm slightly confused about what I do on the server side.
I'm using IIS and ASP.NET. I've had a google but I can't find anything that is either simple or current. There's a lot of talk about the Ajax toolkit, which I believe are controls which use Ajax (and may be retired??) Everything else seems to be based on old versions which I don't trust.
So, in really simple terms, what do I have to do in IIS to respond to an AJAX call?
Quick aside, I believe we can use JSON for object serialisation?? I assume I don't need to in the interests of getting a simple sample running?
So I have an Ajax call which will have one parameter, and I want to return "something" based on the parameter. What is the simplest code to achieve that with IIS and ASP.NET?
Thanks
An AJAX call is basically just a regular call to your website. The only difference is how the browser handles it - AJAX calls are done in the background with Javascript (the J in AJAX) and then does something with the data. You could take the URL that you're doing an AJAX call with and put it in your address bar and it'll return the exact same data. So, basically, what you do on the server side is exactly what you would do as if it were a form being submitted, for example.
As far as object serialization, yes, JSON can do that.
First of all, doing ajax has nothing to do with IIS; it has to do with ASP.NET.
There are essentially 2 ways to do AJAX in .net
1) Heavy use of the framework. You can put your asp controls (such as literals, gridviews, listbox...) in a control called an updatepanel. For this to work, you need to add a script manager to the aspx page. Then, when the user raises an event (for example, paging and sorting of a table), the request is handled by the framework and only the part of the page that's in the updatepanel is refreshed. The other way to raise events is by using the __doPostback function that comes with the asp.net framework. The downside of this method is that a lot of data needs to go back and forth between the user and the server so it can be slow. The upside is that you don't have to worry about generating the HTML since the asp controls handle it for you.
2) Heavy use of Json. With this method, you can use jQuery to call a page method or a web service. You send a json object to the server and you get a json object back. With jQuery, this is really easy. The downside of this method is that you're getting just the json data back: no formatted HTML. So, if you're looking to have a table updated, this method would be tedious because you'd have to recreate the entire HTML. However, the upside of the method is that it's very fast because only the raw data is transmitted. If you implement a web service, you don't even need to create an entire page.
What do you need to get from the server?
If you want to return "something" from the server that's "simple" (just data), I'd recommend a web service with jquery to trigger the call. If the return data is "complex" (html code for controls) then I'd recommend using MS ajax with the update panel.
Don't use the AJAX Control Toolkit, ASP.NET AJAX library, updatepanels or the scriptmanager control. Microsoft have pretty much ditched the lot in favour of jQuery and its Plugins (sensibly).
Here are just some of the ways you can use AJAX with jQuery in ASP.NET: Many ways to communicate with your database using jQuery AJAX and ASP.NET
I was wondering, whats the best way to handle common HTML controls in ASP.NET? I mean, ASP.NET server controls generate too much crap inside the code so I rather use common controls.
But how about databind and how to manage those common objects correctly (such as combobox, textbox and so on)?
Don't forget that you can always set runat="server" on any control - that includes standard html form controls such as <input> and <select>, and also other elements like <div>. Anything, really.
This means that you can regain control of the html output in your WebForms pages quite effortlessly - as long as you don't need viewstate or any other more advanced databinding/state managing that ASP.NET normally handles for you.
That said, learning to use the ASP.NET MVC Framework is not a bad idea, since it helps you regain control of much more than just the html output. Generally, creating a page in ASP.NET MVC takes a little more work, since there are no drag-n-drop controls like gridview, textbox or even repeater. Instead, you use html helper methods and regular foreach loops, which means you have to type a lot more code. However, the MVC framework is designed so that you won't have to repeat much code anyway.
If you're concerned about the html markup generated by the WebForms ASP.NET engine, i suggest you take a look at ASP.NET MVC. It's purpose is specifically to give you the control you need over the generated html.
If you don't want to start learning ASP.NET MVC, ASP.NET 4.0 WebForms gives you more flexibility in the generated HTML (such as enabling the ViewState for a specific control only, setting the html id's etc.).
As for the databinding, again if you study MVC in depth and start thinking in terms of action -> result you can gain a lot more control and flexibility.
Later edit: I forgot to mention Razor, the new ViewEngine under development at microsoft. It's currently in beta and only inside WebMatrix, a very stripped down 'getting-started type' development platform for ASP.NET. MVC combined with the very clean code you can write using Razor will be in my opinion an important trend-setter in the web development world.
There's a reason ASP.Net controls generate all that "crap". It's so you can databind and manage those objects correctly. Using standard html controls is useful when you don't need direct databinding or if you have no need to manipulate the control through server-side code.
The best way to handle common HTML controls in ASP.Net is not to handle them directly. By using them to handle data and functionality, you're basically neutering .Net. You might as well go back to classic ASP.
I have a relatively simple page that will do most of its operations on the client side using Javascript or JQuery. However, initially I do need to retrieve some data from the DB server based on QueryString parameters.
I plan on passing this data in the form of a JSON string to the script by an old-fashioned ASP manner ( var severData = <%=MyPublicData %>) block where MyPublicData is defined in CodeBehind as:
Public string MyPublicData;
The question is, which event in the ASP.NET page lifecycle is the best for this? Page_Init ? Page_Load? Also, is it worth the effort to do this in ASP.NET MVC. I did look at this possiblity but it seemed a little too much for a simple page like this where I do more 90% of the work on the client. Any thoughts on this?
Page_Load is more appropriate, but either will work.
It's very difficult to say if MVC is more appropriate for you application than webforms without knowing more about the application. However, if you don't want to abstract away the traditional web model then I'd go with MVC.
This kind of simple property or field assignment can go anywhere in the lifecycle. For lack of any other reason, you might as well stick it in Page_Load, since that method is usually waiting for you in the code-behind anyway.
well, on the contrary, if it uses mostly javascript with jQuery, I would recommend you to use MVC. you will not have any problem with the ids for instance.
There are workaround to use jQuery with webforms, but it is never perfectly clean regarding selecting the DOM.
MVC : a single action method where you will retrieve your data (preferably from a small repository) and 1 view where you display your data with total control over your html elements.
and jQuery will just fit perfectly for your clientside work.
You can get either to work; you can write public variables/fields to the client in ASP.NET web forms, although MVC has an edge due to the way it renders the UI.
So for MyPublicData, you could assign it a value at any part of the lifecycle; you can assign it in code-behind to a label or something like that, or if it's JS markup you can write it out using Page.ClientScript.RegisterStartupScript or RegisterClientScriptBlock... so you have multiple options.
In MVC, you would assign the value in the controller and render it in the UI, or with JQuery you can do controller requests real easy with $.ajax.
In traditional ASP.NET Web Form applications, UserControls are a great way to encapsulate functionality so that it can be reused. However, UserControls don't fit well into the MVC model. They often make heavy use of ViewState and they blur the seperation of concerns that MVC promotes.
My question is, how do you best bundle a piece of functionality so it can be shared across MVC applications?
As an example, consider a from/to date-selector UserControl that:
allows a user to select two dates, either using a javascript overlay or by typing in day, month and year into seperate fields
can be configured to default to either today and tomorrow's dates or to dates of the developer's choosing
validates the dates that comes back from the user to ensure the from date is before the to date
exposes From and To properties that can be accessed by code-behind
How would I best build something like this in .NET MVC so that I can easily reuse it?
Note that to fully emulate User Control's functionality the MVC component would have to manage the submitted form data and validation - not just the presentation.
In general I would agree that user controls are nice in terms of encapsulating UI stuff, but I don't think too much has really changed in MVC. If I remember right re-using user controls across classic Asp.net projects was a pain and was never really the best way to truly create reusable components. Most UI toolkits that you bought for classic ASP.net didn't give you user controls, they gave you essentially server controls and javascript controls.
In your example, I would probably create or find a jquery (or ur framework of choice) plugin that did what you wanted on the client side. You could also build a C# wrapper around it similar to what Telerik did with some of the jquery UI controls. I do think that the word code-behind and even viewstate will disappear from your vocabulary the more you get into MVC.
If you look at what open source projects are out there for MVC you will get your answer in terms of what you should be doing.
The MVC Contrib app adds a lot of features by creating extension methods and helpers. Their grid control is a typical way to create a reusable component that you could use across projects
Telerik, created some extensions that wrap jquery controls and do asset management.
Finally I think if you look to the future, MVC has areas, which if I interpret it right will give you the ability to break your project apart into multiple smaller projects.
Besides what is already suggested, ASP.NET MVC v2 will have generic templated input controls, see here. You can read how other people do similar techniques, for example, here:
We have
exactly 1 method call for generating a
form element, “Html.InputFor”. As
part of that “InputFor”, it examines
an input specification, that collects
the PropertyInfo, any attributes, the
type, any modifiers called, and
selects an appropriate InputBuilder.
Call InputFor(p => p.Id) and Id is a
GUID? That creates a hidden input
element. Call InputFor(p =>
p.Customer.Address) and Address is a
complex type? That looks for a
partial with the same name of the type
Having considered the helpful answers from others, I will have a go at answering my own question.
It seems to me that the key difficulty with emulating UserControls in MVC is that they crosscut the concerns that MVC aims to seperate. The from/to date selector UserControl in my example incorporates elements of Model, View, Control and interation. UserControls' ability to bundle all this together is exactly the reason that they don't fit well into MVC.
That means that to create a psuedo-UserControl in MVC requires four seperate pieces:
A Model class - in this case an Interval class or similar
A PartialView that knows how to render the Model to HTML
A jQuery script to layer interactivity on top of the PartialView's HTML
A ModelBinder that can deserialise postdata into an instance of the Model class.
The ModelBinder is important because it deals with data coming back from the user. Without it, every Controller that wanted to display a to/from date selector in any of its Views would have to know how to assemble the six postdata fields - and how to cope if they were invalid or some were missing.
Two ways that I can think of. A partial view though this doesn't really transfer well from app to app because you are moving around ascx files. Not a big pain but not my flavour.
I prefer to use WebControls. They are super easy in mvc and all you need to do is reference the library in the project and possibly in your config file and there you go.
I think some of the answers have missed out on the postback functionality of controls. One way you could handle that is to pass any generic information via ViewData when rendering your partial view. That could then post back to its own control, which in turn could redirect to the UrlReferrer.
Its a little messy and use of UrlReferrer poses a security risk. But it is one way around the problem
You can create a jQuery plugin.
As user-controls provided in ASP.NET Webforms, MVC provide a lot of ways to make the controls and code that can be reused in other app.
Using Partials If your partial code have some C# logic and render the html using Razor/aspx code then it's bst to maintain them in razor file.
Write JavaScript Functionality as plugin If you maintain your code and write it as better as it can be used in other app then it would be a huge advantage for you. Next time when you work on other app just open this solution copy it and modify it. Write JavaScript code that can be used as plugin maybe take some more brainstorming.
Write Code As a Separate C# library If some code is too common for every app you make.for example you write a member authentication system or some global function (C#) that are used in every app you made then maintain them in a separate solution so it can be used in other app you made whenever you trying to make a new app in future.