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.
Related
I'm creating some default "drag and drop" templates for our developers, and one section is the required tags. Most of the tags reference a variable: nice and easy. But one wants to reference the resource itself and I cannot figure out a way to it. Does anyone have any suggestions?
The tag itself is called "Context" and it's value should be the "type" of the resource it is in, e.g. "Microsoft.Web/serverfarms". This is desired to aid with billing. Obviously I could either create a different template per resource type (not ideal considering the number of different resources) or rely on the devs to update the field manually (not ideal either as relying on them to add the tags manually hasn't worked so far in a lot of cases), but I am trying to automate it.
Extrapolating from the [variables('< variablename >')] function I did try [resources('type')] but Azure complained that "resources is not a valid selection". I thought it might have complained that it couldn't tell which resource to look at, but it didn't get that far. Internet searches have not turned up anything useful so far.
I can't find a way to do this cleanly either (I hope someone corrects me though! This is a topic for us too). The reference and resourceId functions look promising, but both are unavailable inside of the resources block, would require some parsing, and also require the api version, which you probably also need to vary by resource and so you're just back to where you started. ARM won't even let you use a variable for the resource type property(probably a good thing), so that option is out too.
As such, you'll either have to live with your team having to replace that chunk of text manually or pursue some alternative.
The simplest thing that comes to mind would be to write a script in a language that understands JSON. That script reads the template, adds the tag to the resource, then saves the template again.
A similar approach would be to do it after the resources are deployed by writing a script that loops through all resources and making sure they have the tag. You can use automation to schedule this on a regular basis if you're concerned about it being missed. If you're deploying the templates using a script, you could add it in that script too.
There's some things you probably do with nested templates, but you probably wouldn't be making anyone's life easier or making the process more reliable.
This could be achievable potentially through some powershell specifically around Resource and Resource Group. Would need to run a Get-AzResource either at the subscription or potentially just the resource group level. Then pull the ResourceType field from the object return and use a Set-AzResource command passing in the ResourceID from above and the new tag mapped to the returnedResourceType field.
We decided to use POST method and JSON format for all of our internal APIs which makes everything simpler. But then we realized that this is not truly RESTful. More over it seems that GET requests are more lightweight than POSTs under high load.
We have a problem regarding GET methods. We have to bind our criteria object to the HTTP request (query string) which forces us to build Form object for each criteria model. As you know building the Form object will be done manually and there is no automation available like what we have for JSON formatters (Macro Inception).
Another issue is that we have to decide on whether to use route parameters or querystring.
I think it's simpler to use a single HTTP method and make all API calls uniform. Does it make sense?
POST is the method to be used for any operation that isn't standardized by the HTTP protocol, and simple retrieval is standardized in the GET method. So, using POST for simple retrieval isn't RESTful. More than that, it seems like you want to use POST so you can treat querystring parameters in the same way as the POST payload, but REST URIs are atomic identifiers, including the querystring. Your application shouldn't rely on URI semantics, and extracting bits of information that serve any purpose other than identification also doesn't make much sense in REST.
Frankly, from what you describe your API is so far from being considered truly RESTful that this shouldn't be a concern at all. Do whatever is more consistent with your tools and works better for your application. REST isn't for everyone, and worrying about designing an API that's truly RESTful when that isn't a requirement for your application is more likely to lead to bad design choices.
There's absolutely nothing wrong with using POST like you're describing. In fact, GET requests should not alter the state of the server but instead should only be used for retrieval. In other words, if you're sending data to the server to, for instance, create an entity, using GET would be technically incorrect.
There's nothing you're describing that sounds "not RESTful." POST can definitely be part of a RESTful architecture.
That said, the HTTP method you use should correspond to the action it will perform. For example, if you're retrieving an entity by ID, you should use GET whereas if you're updating an entity by ID, you should use POST or PUT. This gives developers using the API a hint as to the side effects and intended usage of the various API methods.
I am aware that I can Google "HTML Form Validation" and would get a billion tutorials. I am well aware that I can use simple JavaScript to validate form input, but I have been told that this is not necessarily an efficient method. I have also heard that it is a best practice to validate both client and server-side code. OK! Well, What exactly does this mean besides writing code on both? Does it mean I do some with JavaScript and other with Servlet's or does it mean that I write identical validation methods on both?
My real question is can anybody give me insight and direction as how to go about validation my HTML forms. I am using JSP's and Servlet's and I have tons of form validation to do.
I have already done minor form validation with regex in Java, but want to figure out if Im heading in the right track before I write any more code.
Only productive answers please, If I wanted negative feedback on how inexperienced I was, I would have gone to Reddit.
Thanks!
Serverside validation is needed because you cannot rely on clientside validation. Users can disable, bypass or change it.
Clientside validation is handy because it already takes some load of the server and it alerts the user on common mistakes before he has to wait for the server to reply.
Serverside without clientside is ok, clientsite without serverside is a no-no.
How you validate on the serverside is really up to you. There are existing libraries out there that help you, but regexes are fine too. Do read up about why you need to validate, so you don't forget to check against possible attacks.
Same thing goes for clientside validation. The JQuery Validate module quite nice, but you can write your own, no problem.
Client-side validation is courteous to and convenient for the end user.
Server-side validation is an absolute necessity.
As you said, there are countless resources on how each one is best accomplished. One simple strategy is to screen for validity at the client-side and correctness at the server--that is, use Javascript to ensure that the inputs are of the correct type and form (e.g. "looks like a date") and server-side logic to additionally guarantee that the valid input makes sense (e.g. "is in a sensible range for this user"). This could save you some AJAX. It depends on the application, the users, and the resources you want to spend on it. If you don't mind the extra Javascript and HTTP requests, you could duplicate all of the server-side checking at the client-side, but then you'd have two separate programs written in different languages to maintain and keep synchronized.
looking for best practices in web development, when you are writing a web application in a traditional non-framework environment (core PHP or Perl / CGI), what is the cleanest way to organize or map calls from the client to server processes?
The answer is rather trivial when working in a single-scope page where, for example, you have a form to complete and a submit button. You could set the action of the form to "save.php" and have a one-to-one relation between the page and the function it is bound to. So save.php could execute the save action and write to the client the form.
Now, the only non out-of-the-box php enhancement i'm using is a template engine (tinybutstrong). Whenever i have a complex page with multiple forms (for example, for sorting a grid, saving something, requesting something else, an ajax component and a search box), what is your way to lay down the various functions (search, sort, insert, retrieve) to a single display page (index)?
Do you use something like index.php?action=search / index.php?action=insert or something like setting each action to a page that acts like a function (search.php, sort.php, insert.php) each delegating the presentational function to a single script (index.php)? What if the "search" function can be used by varius "views"?
I'm using general terms like search or insert as an example, and the referece to PHP is also only for example, as I think my question is rather general on best practices.
Thanks.
By creating something where there's an action which refers you to a view, you're essentially creating a controller for views, and you're two thirds of the way to MVC. (not that there's anything wrong with that, just that's where you're headed)
Q1. what is the cleanest way to organize or map calls from the client to server processes?
A1. Using the filesystem, but structured semantically based on the structure of your data (if possible) doing something like /search/mysearch is your semantically correct option. Requires a little Apache Mojo
Q1. Do you use something like index.php...
A1. Yes, I wouldn't shy away from this approach. It's ideal to use a little Apache rewrite magic to create nice paths, but aside from that, there isn't any other magic way to create an controller.
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.