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.
Related
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
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.
Let's say I'm on a list page and I
page to, say, page 10. Then I select
a record on that page and redirect to detail
page. After that, I click on the edit
to redirect to the edit page.
After I update the record I'm redirected back to
the detail page. I, then, press back
to go back list to continue my browsing from
where I left off. The key here is
where I left off in the list which is
page 10.
What is the best way to handle this?
Initially, I put a hidden field called page number in each of the webforms and pass it along with the querystring back and forth. Seemed like a lot or a bit redundant checking the querystring on each page and passing it.
I was wondering if there are some other ways. for instance, I've been reading about a separation between the UI and the presentation layer is a good idea (for larger scale apps). To me I understand it as all click handler events will yield control over to the presentation layer which is just a plain class?
Is this correct? Also, is the presentation layer suppose to implement something particular? I know this could probably be saved in session but could someone humor me and show me how to use a presentation layer to handle this (I know it would be overkill but is it possible?)
I don't think there is THE best way. Everything depends of what you achieve to do, ie. the requirements of the whole project.
After all, according to the description, I don't even understand why are you having three pages to do a single thing. By the way, ASP.NET data controls handle mostly everything for you, so you don't even have to ask yourself how to do this (except if you have serious reasons to avoid ASP.NET controls).
For example, a simple <asp:ListView /> will let you list items page per page and show details when a single item is selected. Edition of an element is also quite easy.
What you are asking for is well... large and could span multiple blog posts to give a complete understanding of UI Design Patterns.
I have a small example of MVP with Asp.Net here: What is the best way to reuse pages from one website in another?
However, it is not exhaustive. If you really want information on this you should do some looking into a framework such as WebForms MVP, or ASP.Net MVC.
Check out ASP.NET MVC. It is a framework which goes on top of ASP.NET to do the separation between the presentation layer and business layer.
For simplicity, what you are describing is a very good example of the perfect place to use Asp.Net Dynamic Data.
It's incredibly easy and powerful, and easy to modify once you dig into it a bit. I'd start with the videos here: http://www.asp.net/dynamicdata
I've been using this more and more on every project, for at least the simple CRUD portion of it. I really can't express how much I love this tool now that I'm used to it.
We are designing a data capture process with many questions (using ASP.NET), which can repeat (e.g. enter all your vehicles). In rare cases this could be over 100 repeating groups.
Therefore I've stated that rather than having one huge form that we split the application into multiple forms, using logical points for page splits (e.g. personal details) in a wizard style.
However, there is debate within the team as to whether we should be using AJAX/Javascript to have a single form. Suggested approaches to this appear to be:
Load in all the steps in one go, and just use Javascript to toggle.
Load in step 1 and load the other steps using AJAX.
Submit the form using AJAX and load the next step using AJAX.
Option 1 to me defeats the entire point, as you'd end up loading a massive HTML tree - some of the pages can be large. This would be more acceptable if there was a small number of steps with very few questions on each.
Option 2 to me seems overly complex, plus if the user clicks the next button, can you guarantee the next page has loaded? Also, what happens if input from page 1 is required for page 2?
Option 3 seems doable, but I'd have though the response time of doing the AJAX processing would actually be slower than doing a standard form submit, as there would be more processing involved by the client browser. Also this approach is more complex than a standard form submit.
Do you think my approach is correct (standard form posts)? I've read that typically AJAX is used to enhance the functionality of a page, rather than trying to emulate multiple pages.
The Single Page Interface Manifesto talks about how you can build SPI web sites without losing bookmarking, Back/Forward buttons (history navigation) or SEO.
With regards to performance, this is something you can test. But if you go the AJAX route, you should provide an alternative for those users without Javascript. The extra work required may be enough to push the idea off the board.
To my mind, options 2 & 3 lie at ends of a spectrum. You can use AJAX to submit whatever information is required for the next step. Option 2 submits nothing. Submit the entire form, and you have option 3. You'll probably want something in between.
As for performance, there is some processing to be done (collect form data, data transmission, parsing, splicing the result into the document), but the browser will be doing the same tasks with a traditional form; AJAX just makes parts of the process more visible. Since the data is smaller in size (part of a form rather than a full page), performance shouldn't be much worse and may in fact be better. Also, modern javascript engines are very fast.
In any case, listen to MikeB's advice about degrading gracefully when JS isn't supported, unless this is for an internal app where you can depend on browser make & configuration.
I am working on some sort of CRM application which has huge sales data with all the customer leads etc (ASP.NET 2.0/Ajax)
I want to create a dashboard which will have four separate data containers each container will have different sort of data and each container has to update it self after some configured time interval. so I want to update only that part of page not whole page
What should I used in the above scenario asp.net updatePanel or jQuery implementation (which technique and why)
Because performance is also important here.
Both ASP.NET UpdatePanel or jQuery (or a mix of both) would serve you fine on this scenario; if you don't have experience with neither, I would recommend the UpdatePanel way because it is closer to the regular ASP.NET code you're used to.
This article will get you 90% there, all you have to do at the end is to put some simple javascript in place to fire the updates every X seconds; something like window.setTimeout("Button1.click()",5000) if you want to refresh a panel every 5 seconds. If you don't want the button to be available for the users, just make it hidden via CSS.
There are more elegant approaches (using JSON, webservices, client-side templating etc) but that's an easy way to get the job done.
ASP.NET UpdatePanel is easy to set up, but in my experience terrible to debug.
Doing it yourself with jQuery (or some other JS framework) and an .NET AJAX library is more work upfront, but much easier to improve and maintain later.
UpdatePanel's traffic is a lot bigger than the JSON you'd use with your own solution, if that's a concern.
Also you can use dynamic dashboard framework and convert update panels to drag-drop widgets.
It's a browser independent web part framework for Asp.Net.