I am building my own GridView in an ASP.NET project
I am drawing out my plans and I was wondering what the best solution is to a simple problem, paging and sorting.
The fast and easy way is using submit buttons (or similar) and POSTING the form back. That's also how the ASP.NET gridview works.
pro:
less overhead
con:
backbuttons
The second method is using links and the URL with GET requests.
pro:
backbuttons work just fine
direct link to certain position
con:
less reusable because of the dependence on url
The third method is AJAX
pro:
little overhead
con:
harder to implement
What design/solution would you pick and why?
Am i overlooking some pros and cons?
I add some extra comments to think about.
-The second method is using links and the URL with GET requests.
This is the one that you need to use, if your need web spiders (google) knows all the pages of your site, and be SEO friendly. This method have the problem that you can not have viewstate and each time you must render the page that you see on the url parameters with out knowing anything else.
With this case you probably have more problems if you wish to make edit on one line
-The fast and easy way is using submit buttons (or similar) and POSTING the form back
This is the method if you won to have many functionality on code behind because with the post back you have all the previous action that you have done, and the viewstate is working and can be used for that. Is not SEO friendly and if you like to make it you need extra code to write on the url just the page that you are now and need to land.
-The third method is AJAX
This is the method that must co-exist with the previous and not alone for the case that the browser fails to run javascript for any reason. If you do not care about that, the rest is that this method is also not SEO friendly and you need to make it, is cool, modern, and is a must for modern site, but if you going to make difficult things then you may end up with many issues that must be solved.
To summarize:
More than show data ? Post Request : Get Request ; // ToDo: make it ajax
Related
At the moment we have a solution which is Web forms ASP.Net 4.0. We do a number of things such as using web methods and services either calling them using the standard web forms way or sometimes to reduce the footprint directly calling them with jQuery ajax posts and gets.
We are looking to improve the way we work but we have heavy constricts regarding how the solution is at the moment and not being able to completely rewrite it.
Updating the page using Ajaxs for data, forms and for example pulling "the next 20" items and displaying them on the page it what I would like to heavily stream line.
Using template's due as PURE and jQuery Templates is fantastic way to produce fast calls back and forth between the servers but results in having two copies of the html. (the template for the jQuery and the code in the actual first render of the page)
We have thought about possible producing a empty template and then always populating it via json data we post down to the server but I feel this isn't how things should be done...
can anyone reckoned the best way we can do this without having two copies of our 'template' (e.g. a row of a table)
You mean you have a template in asp and the same template in javascript, but you'd rather just have 1 or the other?
I think that is really subjective. It is always different based on use case. That being said I'd do it by modifying my views and templates. My views (non-js) would simply have containers for that dynamic content. In other words I'd never load the dynamic portions of content into the views initially. Rather, on page load I would simply load up the template and the json that fills it in.
If you think about it that's 2 more requests, but it makes your life easier. The user also is able to see something on the page sooner.
This is one of those questions that really depends on what you are doing. There are trade-offs to be analyzed with every solution.
I realized that many of my past projects have suffered from "too much ajax". I write pretty much all intranet "business" type apps so accessibility to older browser/disabled javascript/etc has never really been much of an issue for me. But things like unable to bookmark/go back/random errors/timeouts that the user doesn't see (I know there are ways around this but just as an example)...and most of all the development time is a lot longer (big issue for me I'm the sole dev) for what seems to be not a whole lot.
From people's experience - when is it appropriate to use ajax in business app/mainly CRUD type sites?
Take this as an example: I have a grid displaying all the registered users. One of the buttons takes you to an edit/details view where you can edit all the info and view further info not displayed on the grid. You can click "save" an ajax request is made and return either a success message or a modelstate with errors converted to JSON and that is displayed in a message above the "save" button (with a bunch of jquery that parses the result) all nice without a page refresh. I have many many screens similar to this. Would it make more sense just to redirect back to the grid displaying all the users once "save" is clicked and successful (with some sort of "flash message" on top stating save was successful) skipping all the ajax/json/etc? As the dev. I have a hard time imaging what would make most sense to the end users, but just doing a redirect would be much simpler and makes sense to me. What are people's experiences in these sort of scenarios?
In that scenario I would avoid AJAX all together unless you have a specific reason for it. Partial page updates, keeping a user's place on the page, or other reason.
MVC handles the scenario you describe very well, including the success/failure messages. In this "edit" failure case you'll detect the failure server side and return the same edit view back to the user with model state information. All of their fields will remain populated and you'll easily be able to display validation messages. On the success side you will return your list or index view and possibly use TempData to display a message to the user indicating their successful edit. A little javascript to spice that up and remove the message after 10 seconds or so and the user experience is very good.
This gets even better when you add client side validation, which is much easier in MVC3.
I think you can create a very intuitive experience for the user in this case and avoid ajax/json all together. I do both but I make sure I have a legitimate reason before I start writing client side ajax code.
Take a look at the Steve Sanderson MVC books. He walks through this scenario exactly as you described with good detail. His MVC3 book isn't out yet, and I haven't read the MVC2 book but the original MVC book has it.
http://www.amazon.com/ASP-NET-Framework-Experts-Voice-NET/dp/1430228865/ref=sr_1_4?ie=UTF8&qid=1308745293&sr=8-4
I also like PluralSight online training when I'm looking for fundamental framework guidance like this. http://www.pluralsight-training.net/microsoft/
Of course there are plenty of free blogs and what not that cover MVC too. Have fun.
In my application where I have to take a lot of data from the user that happens mostly form main business entities (Employeee, Distributor, etc.) I usually take the route of normal form post rather than ajaxifying the form. Mostly, I use ajax when data to be posted is small and I have to display data on same page after saving.
For instance, on Employees view page you can have a little form to add experiences for the employee and you can save it through ajax and append the entered data back to the same page.
Take the example of Stack Overflow for instance. They use normal form post for saving answers and questions but when it comes to comments where amount of data is small and comments have to be appended on the same page then it makes sense to use ajax in such scenarios.
Using ASP.NET MVC: I am caught in the middle between rendering my views on the server vs in the client (say jquery templates). I do not like the idea of mixing the two as I hear some people say. For example, some have said they will render the initial page (say a list of a bunch of comments) server side, and then when a new comment is added they use client side templating. The requirement to have the same rendering logic in two different areas of your code makes me wonder how people convince themselves it is worth it.
What are the reasons you use to decide which to use where?
How does your argument change when using ASP.NET Web Forms?
One reason that people do that is because they want their sites to get indexed by search engines but also want to have the best user experience, so are writing client code for that. You have to decide what makes sense given the constraints and goals you have. Unfortunately, what makes the most business sense won't always seem to make the most sense from a technical perspective.
One advantage to server-side rendering is that your clients don't have to use javascript in order for your pages to be functional. If you're relying on JQuery templates, you pretty much have to assume that your page won't have any content when rendered without javascript. For some people this is important.
As you say, I would prefer not to use the same rendering logic twice, since you run the risk of letting it get out of sync.
I generally prefer to just leverage partial views to generate most content server-side. Pages with straight HTML tend to render a bit faster than pages that have to be "built" after they've loaded, making the initial load a little speedier.
We've developed an event-based AJAX architecture for our application which allows us to generate a piece of content in response to the result of an action, and essentially send back any number of commands to the client-side code to say "Use the results of this rendered partial view to replace the element with ID 'X'", or "Open a new modal popup dialog with this as the content." This is beneficial because the server-side code can have a lot more control over the results of an AJAX request, without having to write client-side code to handle every contingency for every action.
On the other hand, putting the server in control like this means that the request has to return before the client-side knows what to do. If your view rendering was largely client-based, you could make something "happen" in the UI (like inserting the new comment where it goes) immediately, thereby improving the "perceived speed" of your site. Also, the internet connection is generally the real speed bottleneck of most websites, so just having less data (JSON) to send over the wire can often make things more speedy. So for elements that I want to respond very smoothly to user interaction, I often use client-side rendering.
In the past, search-engine optimization was a big issue here as well, as Jarrett Widman says. But my understanding is that most modern search engines are smart enough to evaluate the initial javascript for pages they visit, and figure out what the page would actually look like after it loads. Google even recommends the use of the "shebang" in your URLs to help them know how to index pages that are dynamically loaded by AJAX.
Got a question: how far can we go without a form being implemented around the master page in a .net project?
I hate that form tag it stops us from having multiple smaller forms and thus we cannot use an "edit-in-place" feature properly, where i dont want to send all fields, just a few of them, and an ajax solutions is all good until we hit the wall of uploading a file, DAMN uploads, DAMN .net, DAMN HTML, does anyone know a way out of this ditch?
Question on the side, how on God's earth is posting a file thru the iframe regarded MORE SECURE than sending the file in an HTTPXML object? aren't they both an HTTP request?
thank you for bearing with my temper today
There's so many places to start it's hard to pick a point.
First off, although the single form issue is enforced by regular .net web forms there are other options such as MVC. This would give you more control to emit multiple forms on the page. Just don't nest them as a number of browsers can't deal with nested forms very well.
As far as ajax, you don't have to make an ajax call back to the web form that served the page. It is pretty common to instead make several generic handlers (.ashx files) which your ajax controls post to. As an example, you might have one .ashx handler which deals simply with file uploads.
Besides separating out the functionality, generic handlers don't have to go through the entire page lifecycle to handle what amounts to a single action.
Regarding an iframe upload versus a regular upload, I've never seen anyone claim one is more secure than another. It's not. Further, some browsers (safari, I'm looking at you) have interesting issues regarding iframes so I tend to stay away from them anyway.
I got over this problem finally, i first used nested forms which is pretty ugle, it worked fine tho until i tried it on IE9 the look was broken (the behavior tho wasnt), one little small tweak and i was over it, i inserted the form tags on runtime, and IE9 didnt complain ;)
I've built a full ajax site using jQuery and asp.net. All database data are loaded dynamically via client-side ajax calls. There are no html forms or postbacks, just ajax calls to a web service returning (xml) data.
Now, I need to make the site SEO friendly with emphasis to google. What is the least time expensive way to do it? Is there a way jQuery or asp.net can help me with out-of-the-box solutions/components etc? On the other hand, there is the google specification but is it standard or easy to implement in my case?
Any help or ideas much appreciated.
your question is kinda unspecific.
jquery is javascript - based on how it's implemented can be very bad for SEO
asp.net is server side - can be anything, what counts is the HTML you have on page.
for a start i would recommend googling your site, then click on the "cached" link below it, then "text only version" ... this is what google sees. if you can makes sense of it, then google can make sense of it. if there is nothing there (possible for a very very ajaxy site) then well you are in trouble. then go to your competitiors site and do the same. if he is doing a better job look at his HTML sourcecode and think about ways you can get in this direction.
you would maybe also like to take a look at http://code.google.com/web/ajaxcrawling/docs/getting-started.html