I have created a form using html. I need to do calculations using the form and the score should be displayed at the bottom in Test4, And if the score should be pass or fail. If there is zero tolerance then it should make the score as 0% and result as fail. manojhnikam#outlook.com
You can't do that. HTML does not have this capability.
A form is designed to send the data entered in it over HTTP to a web server.
Software (which could be written in any programming language you like) then reads the data and generates a suitable HTTP response. You need to pick an HTTP server and a programming language and then learn how to use them together to perform server side programming.
It is also possible to process data in the browser itself using JavaScript. You wouldn't be able to conveniently write to an existing file there though.
Related
We are making integration between three systems (lets call them A, B and C). A and B systems we can control, C we can not.
Logic between three system is this - A communicates with B and B communicates with C.
All use REST webservices. The one we can't control, use content type application/json. B for now use text/html, because there was older integration (with C) that had this used. With A there is no integration done at all.
So I'm wondering if its better to redo B system from scratch and make it use same content type application/json for every system or leave as it is (like there is not much of a difference)?
Also is there any advantages/disadvantages I should be avare of using application/json over html?
Update
Sorry, I forgot to mention, it would be used solely to transfer business data if that is of any use.
TLDR - Use JSON
Realistically when it comes to web services you should be serving out whatever the client asks for (and you support). Clients can specify what type of data they want to receive by using an HTTP Accept header, and it's up to your web service (or the web service framework you're using) to serialize the response accordingly.
When it comes to the difference between serving data using HTML or JSON, they're meant for two different use cases. HTML is sent with "markup" (the M in HTML) that includes instructions for how the data can be viewed, usually by a browser. For another client who isn't a browser and is just looking for the data, parsing this data is an extra unnecessary step that is usually not automatically supported without a 3rd party library or a bunch of manual code.
JSON (and XML and other formats like CSV) is meant to only transmit the data and its possible relations, and the deserialization is usually natively supported by a number of different client programming languages including .NET, JavaScript, and others. Because it's only the data, clients don't have to attempt to extract the data from any additional extraneous markup.
Also, it's a lot easier for a client web application to receive JSON and create HTML on the client side than it is to receive HTML and parse out only the data if needed. Plus you're allowing the client to create HTML that is specific to their application, rather than trying to manipulate HTML that the web service sent them to work with their specific app.
I made an app which provides a schedule for the pupils at my school. It gets its data from the school's online schedule service. Due to the lack for a real API, I reverse-engineerd the website: Now, the app parses it with string operations basically.
And here's the problem: The string searches do not match on certain mobile carriers' networks because they're stripping away the spaces and other foo. Is there an universal way to turn that off?
No, this is up to the carrier and even if there was a way to disable it, it would be non-standard and not worth addressing.
Additionally, you should not use string operations but a real HTML parser, like JSoup is for Java (there is a .NET port too, NSoup). If you look at the examples, it is relatively easy to use and will protect your application from space normalizations and any other change in the markup irrelevant to your application.
For data stored in inline JavaScript, you could first extract the right node from the document and then use a regex to trim the relevant parts. Or you could also use a regex on the HTML document as a whole, but remember that you can't really parse HTML using regexes.
Adopting another strategy, request pages over HTTPs rather than HTTP (if the server supports TLS/SSL) so that they can't be manipulated by the carrier.
I'm thinking about using the jQuery Ajax load method. In some cases, the html I want to load is quite large. I'm wondering if the browser already streamlines the process behind the scenes, or should I minify and/or compress the html before calling .load() from jQuery? If so, which one? or both? Is there a standard way to perform minification and/or compressing in this scenario?
UPDATE
Does this make any sense:
The data I'm going to retrieve from the server is static. Let's say I have data for apples, oranges, kumquats, and papayas, and none of it changes "on the fly" (only when I update the site).
So is it preferable that I get the data as Json via jQuery this way:
$.getJson('kumquats')
(...and then, of course, process the results that come back)... OR ...simply send back the html with no need of massaging, as "kumquats" will always send back the exact same html, "oranges" will always be the same html, etc.
In the latter option, then, I would do something like this (jQuery pseudocode) instead:
$('#MainContent").html($.load("\Content\Kumquat.htm"));
In summation, I can send all the html fully-formed across the wire, and clog up the pipes with some extra bits for a bit, OR I can send a less verbose representation of the datta (json), and then massage it in the .getJson() callback function, transforming it into html. Performance-wise, does it make much difference? BTW, this is not "sensitive" data - it doesn't matter who sees it as it zips by through the ether.
I'm wondering if the browser already streamlines the process behind the scenes
The browser can't control how much data the server sends in its response.
or should I minify and/or compress the html before calling .load() from jQuery?
You call load on the client. The server has to do any minification or compression of the HTML.
Is there a standard way to perform minification and/or compressing in this scenario?
Compression is usually handled by gzip encoding. How you set that up depends on your server and/or the server side programming language that is generating the content.
I'm not aware of any standard way to perform minification. I used HTML Tidy to do that once.
The browser can't minify HTML before downloading it first. The only reason you want to minify is to reduce download time by decreasing the file size of the download, so this is counter intuitive.
Your server needs to minify and/or compress. It probably already is compressing by default (mod_deflate on apache for example). Minification of the HTML can be done in a variety of ways depending upon the server-side technology you are using. There may be a library for it, or you could use a third party CDN to minify and serve the content for you.
As part of a extensive test-case, I'm building an ajax-based CMS-like application which provides CRUD-functionality on various documenttypes, e.g: articles, tags, etc.
on the server and client-side I'm considering to use JSON-schema ( http://json-schema.org/ ) as a way to do user input validation in a DRY way (i.e: 1 validation-schema, to be used both on the server and client-side, no duplicate-code and all that) . This seems great, because:
JSON-schema is both implemented in JS and Java, so one schema could in theory handle client-side and server-side validation
all CUD-operations requests and responses are JSON (through ajax)
However besides the usual validations on user-input I would like to have some additional checks on the server (e.g: like checking if the name of a Tag a user wants to create already exists)
Ideally, I want these type of checks to be included in my general server-side validation code (which as said would be based on JSON-schema). However, I'm not entirely convinced that this is the right approach, because these additional checks are not based on the provided JSON-data alone, but need additional data to validate (e.g: the names of existing tags in the system to check if a tag-name already exists).
So, would it be a good idea (design / architectual wise) to incorporate additional checks like the one described above in the json-schema based validation-framework on the server-side? Would this be an elegant solution? Or would you keep them seperate altogether? If not, why not and what other alternative approached would you suggest to stay DRY concerning client and server-side validation?
What do you think?
Some additional context/ goals of the text-case below for some background info.
Thanks,
Geert-Jan
Some context / goals:
ajax-based CMS using REST approach
CUD-requests are performed through ajax using a rest approach (i.e: mapping on POST, PUT, DELETE respectively). Requests and responses are all done through JSON.
CMS without forms. Instead use in-place editing (e.g using Aloha-editor: http://www.aloha-editor.org/
staying DRY.
templating: done through Mustache templating on client and server-side. Intial rendering and incremental rendering through ajax are done based on 1 and the same template. I wanted to go for something different than Mustache (bc. of it's lack of expressive power), but it works for this prototype at least. (See previous question for alternatives, on which I'm still looking for an answer: Client-side templating language with java compiler as well (DRY templating) )
DRY input-validation: as described above
Validation flow ( in case of failure):
user creates/updates/deletes item.
a validation-failure on the client would instantly give feedback to the user as what to repair. (The Javascript JSON-schema-validator would ideally return JSON which is formatted to the user)
when client-side validation succeeds, the CUD-operation is performed using ajax.
if server-side validation fails, a status-code 400 (Bad request) is returned, with a Json-object containing the validation-failure(s) which is picked up by jquery's error-callback
$.ajax({
....
error: function(xhr, status, error) {
var validationJSON = JSON.parse(xhr.responseText);
//handle server-side validation failure
},
....
});
JSON-object containing server-side validation failures are presented to the user (analogously to client-side)
It is very possible and one of the most gratifying things to have a single definition of validations in one place (per model) on the server that can then generate appropriate JS for client-side and AJAX-based validations.
Yii framework for PHP has a fantastic architecture for accomplishing this in an elegant way that stores all the validation rules together in the model (divvied up into appropriate "scenarios" as needed). From there, it's a matter of flipping a few switches to make a particular form client-side or AJAX-validateable. I believe Yii's interfaces for this were based on Rails.
Anyway I would highly recommend checking out the following key points from Yii's design; even if you don't know PHP, you can use this for inspiration:
CModel::rules() => The DRY source for model validation rules
CActiveForm => Used to generate form elements based on model attributes
See for example CActiveForm::textField()
CValidator => Base class for validators which provisions for the ability to client-validate
I think it's wise to pursue DRY validation rule declaration and in my experience it is not at all unrealistic to achieve that 100% and still have rich forms—and rich validation rules. (And boy will you love life when you don't have to manage all that client-validate JS...)
Hope this helps.
I've got a fairly ajax heavy site and some 3k html formatted pages are inserted into the DOM from ajax requests.
What I have been doing is taking the html responses and just inserting the whole thing using jQuery.
My other option is to output in xml (or possibly json) and then parse the document and insert it into the page.
I've noticed it seems that most larger site do things the json/xml way. Google Mail returns xml rather than formatted html.
Is this due to performance? or is there another reason to use xml/json vs just retrieving html?
From a javascript standpoint, it would seem injecting direct html is simplest. In jQuery I just do this
jQuery.ajax({
type: "POST",
url: "getpage.php",
data: requestData,
success: function(response) {
jQuery('div#putItHear').html(response);
}
with an xml/json response I would have to do
jQuery.ajax({
type: "POST",
url: "getpage.php",
data: requestData,
success: function(xml) {
$("message",xml).each(function(id) {
message = $("message",xml).get(id);
$("#messagewindow").prepend("<b>" + $("author",message).text() +
"</b>: " + $("text",message).text() +
"<br />");
});
}
});
clearly not as efficient from a code standpoint, and I can't expect that it is better browser performance, so why do things the second way?
Returning JSON/XML gives the application more freedom compared to returning HTML, and requires less specific knowledge in different fields (data vs markup).
Since the data is still just data, you leave the choice of how to display it to the client side of things. This allows a lot of the code to be executed on the client side instead of on the server - the server side needs to know only about data structures and nothing about markup. All the programmer needs to know is how to deliver data structures.
The client implementation only needs to know about how to display the data structures returned by the server, and doesn't need to worry about how these structures actually get build. All the programmer needs to know is how to display data structures.
If another client is to be build (that doesn't use HTML as a markup language), all the server components can be reused. The same goes for building another server implementation.
It will normally reduce the amount of data transferred and therefore improve transfer speed. As anything over-the-wire is normally the bottleneck in a process reducing the transfer time will reduce the total time taken to perform the process, improving user experience.
Here are a few pros for sending JSON/XML instead of HTML:
If the data is going to ever be used outside of your application HTML might be harder to parse and fit into other structure
JSON can be directly embedded in script tags which allows cross domain AJAX scenarios
JSON/XML preserves the separation of concerns between the server side scripts and views
Reduces bandwidth
You should check out Pure, a templating tool
to generate HTML from JSON data.
Generally JSON is a more efficient way to retrieve data via ajax as the same data in XML is a lot larger. JSON is also more easily consumed by your client side Javascript. However, if you're retrieving pure HTML content I would likely do as you suggest. Although, If you really needed to, you could embed your HTML content within a JSON string and get the best of both worlds
I'm currently wrestling with this decision too and it didn't quite click until I saw how Darin boiled it down:
"If the data is going to ever be used outside of your application HTML might be harder to parse and fit into other structure"
I think a lot of it is where/how the data is going. If it's a one-off application that doesn't need to share/send data anywhere else, then spitting back pure HTML is fine, even if it does weigh more.
Personally, if there is complex HTML to be wrapped around the data, I just spit back the HTML and drop it in. jQuery is sweet and all, but building HTML with Javascript is often a pain. But it's a balance game.
In some cases, AJAX responses need to return more information than just the HTML to be displayed. For example, let's say you are returning a list of the first twenty items from a search. You may need to return the total number of search results to be displayed somewhere else in the DOM. You could try piggybacking the total count in a hidden div, but that can get messy. With JSON, the total count can simply be a field value a structured JSON response.
To me it boils down to this:
It's for many of us, much less work to use a server side, mature, template engine that we're accustomed to, to generate html and send it down the pipe, than using a bunch of javascript code to generate HTML client side. Yes, there are some templating engines for javascript now which may mitigate it somewhat.
Since I already separate model, logic and views server side, there is no argument in having yet another separation. JSON is a view, HTML is another view.
And lets face it; both HTML/AJAX and JSON/AJAX are many times better than full page over the pipe.
The final thing you perhaps need to think about is; if you're going to be search engine friendly - you might have to generate the HTML server side any way (the old degrade gracefully mantra).
I usually do a combination. If there is client side logic, I use JSON - else I use HTML. Notifications and autocomplete special fields are sent via JSON.