I have seen a few other questions of a similar vein on here, but with no definitive answers.
I am looking for the best way to go about loading asp.net server controls (or user controls) from client script (likely jQuery). I am creating a small dashboard that will feature multiple controls/controls created as the result of client script call's and the controls will need to be able to run server side functions and are not just simple information display controls.
I have done something similar recently with loading details controls which were rendered via an HttpHandler from a jQuery $.get() and the resulting HTML of the control is injected into the DIV area - however these used a custom formless page as a temp placeholder as to not interfere with the current viewstate/rendering cycle on the page so they were only able to use HTML elements such as hyperlinks, etc.
This is different and I am looking for the best way to be able to load up controls which will act as if they were registered into the page at the beginning of the page life cycle because I want the controls to be able to run their own server side methods/events (some filtering, etc).
I have seen some people say you should really use UpdatePanel's for this and do the processing server-side - but I am loathe to do this as one of the requirements is heavily tied to using client script.
I have experimented some with this and feel that ASP .Net stateful behaviour of the server side controls is really restricting when it comes to things like this.
If it is a simple dialog such as a login with username and password I can recommend that you do either a page method or a ashx handler that the javascript can communicate with, and then just build all the markup + server communication with your client side script.
But since you are building a more complex solution I would give you the advice that people already have suggested: Use UpdatePanels.
You can always hook up client scripts that run before the postBack (which shows the server side controls) is triggered, this client script can control if the postBack should fire or not etc. And you can also make the server side of the code invoke client side scripts when it have been rendered.
Things like this make you really appriciate ASP .Net MVC.
Related
I'm an android developer and about two years and recently I've been thinking about building web applications. So I started researching about spring boot and everything is great. Then, I came across this thing called template engines (thymeleaf) which by definition separate your code from presentation.
What is confusing me is how can a backend server have html? should the presentation be handled by html, css and javascript in the front end? I even saw tutorials where they actually type in html code in their controller as return values.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
THank you
the frontend will manipulate this data
What front end? You mean the JavaScript code in the HTML page? Where did that come from? Oh yeah, the server.
It is the server that serves the HTML pages to the client, as well as any .js and .css files.
The server could provide static pages, and anything dynamic is handled by JavaScript. Or, the server could dynamically build the HTML page, using ... you guessed it ... a template engine.
You generally don't want JavaScript to build the page initially, just to use JavaScript for handling any dynamic behavior. Some pages don't even need any dynamic behavior.
Unless of course you're thinking about single-page applications (SPA), where there is only one root HTML page, and everything else is built client-side with JavaScript and AJAX calls, but most web applications are not SPAs.
Thymeleaf replaces JSP by providing HTML pages using a template engine. The controller requests the HTML file and Spring Boot provides that template after building it using the Model provided.
Thymeleaf is great because it allows you to rebuild templates on the fly. Lets say for example you're showing a users points to them on the front end, but maybe the points increase or decrease.
What you can do is build the template in the background using a Model. The Model reference is magically provided to the template provided which parses it.
#RequestMapping(...)
public String request(Model model) {
model.put("points", 5);
return "my-template.html"
}
Then use the Thymeleaf language to provide your object to the HTML file to be processed in the engine during runtime.
<html..>
<head>...</head>
<body>
<h1 th:text="${points}"></h1>
</html>
Spring Boots Template engine will build this in the background and present it to the user, but it will show the actual points to the end user! Hope this helps a tiny bit.
I know this question has been answered pretty effectively so far, but I want to add my two cents in as I work with Thymeleaf often.
The easiest way to think about a template engine is that it allows some dynamic development of html based on information passed to it by the controller method. This allows you to put logic in that normally wouldn't exist, or say display a certain section if a user is perhaps logged into admin.
If web pages were houses, html is the frame, css is the walls, Javascript is the lights and electricity, and a template engine would pretty much just be the architect designing the plans on the fly before the frame was built based on desires of the buyer of the house (user inputs).
OK, newer Apps and websites may just load/boot/open once and then pull or push data via AJAX requests, this is good, it saves traffic and it is fast.
But it has not always been like this and some Frameworks still don't build everything on small requests. Spring in Java or Symfony in PHP are MVC Frameworks and use template engines to build pages. This may sound a little outdated but there is still a lot of websites using this.
And if you build a web app for a customer with slow PCs or other devices and the page contents are performance heavy you might want to do as much work as possible on the server so that the user does not have to wait for long. And also you can cache the rendered pages. There is even server side rendering of react pages to e.g. make the initial page load faster...
With Java and Spring I did just use JSP I don't know thymeleaf. Just use what you like and maybe what is most supported/documented.
And building websites like this does not mean you cannot use AJAX, but if you use templates you need to think about what makes sense.
What is confusing me is how can a backend server have html?
The "back end" must have HTML, because that's what's delivered to, and rendered by, the client.
It may just be that the back end "server" is just a CDN delivering, say, an HTML/JS SPA, but there's still something delivering content to the browser.
That said: server-side rendering is still a thing, and has had a resurgence lately--a React app may have its initial rendering done on the server so again the client gets a page rendered with both HTML and associated data, and then starts acting like a normal SPA.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
Because something needs to run the JS to access those APIs.
Some history:
Browsers used to suck. JS used to be a neat add-on, sites were relatively static, and essentially all rendering was done on the server. The back end would get data from wherever it got data from and generate complete HTML pages, and there was little happening on the client side other than some form fields, maybe some validation, and that was about the extent of it.
What is the best thing to do when a user doesn't have JavaScript enabled? What is the best way to deliver content to that kind of user? What is the best way to keep a site readable by search engines?
I can think of two ways to achieve this, but do not know what is better (or if a 3rd option is better):
Rely on the meta-refresh tag to redirect users to a non-javascript version of site. Wrap the meta-refresh tag in a noscript tag so it will be ignored by those with javascript.
Rely on an iframe tag located within the body tag to deliver a non-javascript version of site. Wrap the iframe tag in a a noscript tag so it will be ignored by those with javascript.
I would also appreciate high-profile examples of the correct or incorrect way to do this.
--------- ADDITION TO QUESTION -----------
Here is an example of what I have done in the past to address this: http://photocontest.highpoint.edu/
I want to make sure there aren't better ways to do this.
You are talking about graceful degradation: Designing and making the site to work with javascript, then making the site still work with javascript turned off. The easiest thing to do is include the html "noscript" tag somewhere near the top of your page that gives a message saying that the site REQUIRES javascript or things won't work right. SO is a perfect example of this. Most of the buttons at the top of the screen run via javascript. Turn it off and you get a nice red banner and the drop down js effects are gone.
I prefer progressive enhancement development. Get the site working in it's entirety without javascript / flash / css3 / whatever, THEN enhance it bit by bit (still include the noscript tag) to improve the user experience. This ensures you have a fully working, readable website regardless if you're a disabled user with a screen reader or search engine, whilst providing a good user experience for users with newer browsers.
Bottom line: for any dynamically generated content (for example page elements generated via AJAX) there has to be a static page alternative where this content must be available via a standard link. If you are using javascript for tabbed content, then show all the content in a way that is consistent with the rest of the webpage.
An example is http://www.bbc.co.uk/news/ Turn off javascript and you have a full page of written content, pictures, links etc. Turn on javascript and you get scrolling news stories, tabbed content, scrolling pictures and so on.
I'm going to be naughty and post links to wikipedia:
Progressive Enhancement
Graceful Degredation
You have another option, just load the same page but make it work for noscript users (progressive enhancement/gracefull degradation).
A simple example:
You want to load content into a div with ajax, make an <a> tag linking to the full page with the new content (noscript behavior) and bind the <a> tag with jQuery to intercept clicks and load with ajax (script behavior).
$('a.ajax').click(function(){
var anchor = $(this);
$('#content').load(anchor.attr('href') + ' #content');
return false;
});
I'm not entirely sure if Progressive Enhancement is considered to be best practice these days but it's the approach I personally favour. In this case you write your server side code so that it functions like a standard web 1.0 web app (no JavaScript) to provide at least enough functionality for the system to work without JavaScript. You then start layering JavaScript functionality on top of this to make the system more user friendly. If done properly you should end up with a web app that at least provides enough functionality to be useful for non-JavaScript users.
A related process is known as Graceful Degradation, which works in a similar way but starts with the assumption that a user has JavaScript enabled and build in workarounds for cases where they don/t. This has a drawback, however, in that if you overlook something you can leave a non-JavaScript user without a fallback.
Progressive Enhancement example for a search page: Build your search page so that it normally just returns a HTML page of search results, but also add a flag that can be set via GET that when set, it returns XML or JSON instead. On the search page, include a script that does an AJAX request to the search page with the flag appended onto the query string and then replaces the main content of the page with the result of the AJAX call. JavaScript users get the benefit of AJAX but those without JavaScript still get a workable search page.
http://en.wikipedia.org/wiki/Progressive_enhancement
If your application must have javascript to function then there's nothing you can do except show them a polite message in a noscript tag.
Otherwise, you should be thinking the other way around.
Build your site without JS
Give awesome user experience and make it full functional
Add JS and make the UX even more functional. Layer the JS on top.
So if the user doesn't have JS, your site will still revert to step two of your site state.
As for crawling. If your site depends on AJAX and a lot of JS to work, you can make gogole aware of it : http://code.google.com/web/ajaxcrawling/docs/getting-started.html
One quick tip that may help you: just install lynx, a command-line web browser, and you'll immediately see how google and other seo see your site (and blind people too). This is very useful. Of course, in a command line windows, there's no graphics and javascript is disabled.
If you're doing "serious" Ajax (e.g. client side-routing) the following technique could be useful:
Use Urls without GET/"?"-parameters (it makes your life easier later on)
Use http://baseurl.com/#!/path/to/resource for client side-routing
Implement rendering of non-script HTML-version of your site (HTML snapshot is what Google calls it) at http://baseurl.com/path/to/resource
Wrap the whole content of your HTML snapshot in noscript-tags and redirect via top.location.href to the full version of the site
Handle http://baseurl.com/?_escaped_fragment=/path/to/resource - it should redirect via 301-response to http://baseurl.com/path/to/resource
Use a-tags only for GET-links, use forms for POST/PUT/DELETE-links - unstyle the hell out of them if necessary
A nice example code for links I found while researching "How to write proper Ajax-code":
Resource
This is of course a pretty complex solution but it should enable both SEO (including non-search engine crawlers) and accessibility. The problem is that you have to be able to render your page server- AND client side.
One solution could be to use a templating framework like mustache where implementations for different platforms exist.
Use something like {{#pagelet}}/path/to/partial{{/pagelet}} for dynamic parts of your page - example: {{#pagelet}}/image/{{image_id}}/preview{{/pagelet}}
In your client-side rendering, pagelet would be implemented to be dynamically replaced with something loaded via Ajax (for example: render )
In your server-side rendering, pagelet would just be rendered directly (in doubt just curl the pagelet and render it right away - or if you can write the code asynchronously do it just as you would do it client side: write some temporary span into a buffer, start fetching all the pagelets, replace the temporary spans as the pagelets arrive and flush the buffer once all pagelets have been rendered.
That's the best general design I found so far. You can deep link into your app, it's search engine friendly and it should force you to build a page that gracefully degrades.
P.S.: One advantage of the techniques described above is that both the Ajax- and the "Web 1.0"-rendering of a page could profit from memcached-caching of whole pagelets.
I would prefer to code the page without javascript and then if javascript is enabled, we redirect users to a similar page with javascript. (same concept as progressive enhancement)
redirecting with javascript
I'm building a survey system where a user can pick various types of questions. Each question should be loaded into the current page.
There are 6 different question types, each with different settings/form fields. You can also add multiples of the same type of question.
So should I have the form templates stored and then load them dynamically (I'm using jQuery)?
And if so, where should they be stored and how should they be called (they'd have erb in them)?
EDIT: For clarification, I know how to do the javascript stuff. I'm curious from the Rails side of things how this works. Would I create a bunch of partials for each question type? And how would I load just the partial content?
I suggest: http://railscasts.com/episodes/197-nested-model-form-part-2
And in the link, comment 57 claims to have it unobstrusive way here: http://github.com/thb/surveysays
But I'd avoid using ajax for such kind of feature: if it can be done client side, do it client side :)
You can make an AJAX request to the server and have jQuery completely replace the content in a certain, say, <div> with new HTML content sent back from the server.
Take a look at the documentation for jQuery.load: http://api.jquery.com/load
From the Rails side, yes, have the forms in partials that are sent back via AJAX, but can also be included in 'normal' HTML requests for folks that do not have JavaScript enabled.
I am in charge of converting an ASP.NET web application into fully AJAX based application. I know Javascript and Jquery very well.
Initially I thought to point every anchor tag's click event to JS function and to call stuff via ajax and to populate the body and so on. I encountered a problem when it came to ASP.NET Form on every page and when there was need to make a post-back. I decided to point every Form tag's onSubmit event to a JS function to post stuff using ajax and to get results and I got to know this is not possible with ASP.NET as every time where is a button click, there will be post back so it's hard to let page know what button was clicked.
I then decided to use ASP.NET built-in AJAX controls to use with Forms which is pretty easy and worked like the way they should.
Now I am stuck with the question of which I should go with?
I like to be JS way because it's more customizable than AJAX.NET. I highly need your suggestions.
I don't see a problem in using ASP.NET Ajax. The scriptmanager and UpdatePanel controls will make you task easy and fast to convert to and ajax enabled website.
I am not sure what kind of customization you are looking for but you can still use js way whereever necessary. One another plus point with ASP.NET Ajax is it is well tested and used by thousands of sites and comes with lots of controls like in ajaxcontrol toolkit.
If you want to convert a web forms application completely to JavaScript coding, this is going to be really hard to do. It would be a lot easier to use the updatepanel control to make it look asynchronous to the user, as this doesn't break the server-side integration. But if you are using JS to post back to the server, then wipe the UI and replace it with the new one every time, that's going to be a lot harder.
Ideally, the best way is to use web services, call the web services through JS code (either JQuery or using the Sys.Net.WebServiceProxy ASP.NET AJAX object) to stream the data and you build the client in JS.
Let me know if you want more info...
HTH.
I want to create a javascript popup box that contains text fields. I want to be able to style this box - using CSS - and I want the textfield entries to be Inserted into a MySQL database. Is this possible?
I would be familiar with doing this through web forms and server side scripting but I need it to be a bit more client side this time to make things seem a bit faster. I am thinking I may need to learn some AJAX but any pointers would be a help.
GF
You don't need to learn that much Javascript, to be completely honest. You could simply create a small HTML form on your page, and display it as a popup. You could either have it send the data to your server-side script via the form's natural submit, or you could pass that information asynchronously.
jQueryUI has an example of something very similar: http://jqueryui.com/demos/dialog/#modal-form
You can't connect to a database with client-side javascript. Ajax will help you make seamless calls back to the server without refreshing pages, but you will need to have a server side component to return something useful back to your javascript.
As far as styling your forms with CSS, that part is doable.
Best way to do this would be to "popup" a new window which points to a file with the AJAX calls, the form, and the styling.