The grails manual shows the following example:
<g:set var="now" value="${new Date()}" scope="request" />
and also indicates by default variables defined by the set are page scope (out of the page, request, flash, session, and application choices). I'm wondering what the difference between page and request scope is, and what an example use of the difference might be.
Also, with the flash scope, the manual indicates: "Grails supports the concept of flash scope as a temporary store for attributes which need to be available for this request and the next request only. Afterwards the attributes are cleared. This is useful for setting a message directly before redirection."
It isn't immediately apparent to me how redirection relates to "this request and the next request", since the example of redirection they give is redirecting from one controller action to another, which doesn't respond in two pages/http responses being sent to the client?
Hopefully those two questions make sense -- i.e. high level difference between page and request scope, and how redirecting between actions is useful for flash scope?
A redirect(controller: "foo", action:"bar") equals a new request (in the context of a servlet at least). Which is why you need flash to be a sort of 'two requests scope', the action you get sent to treats your redirection as a new request. You can explicitly avoid this by using chain().
As for the difference between the page and request scope, my understanding is that the page scope is more or less the model a given view / render process operates on whereas the request is for the entire request cycle. Meaning that whatever you pass off to the view in an action return (or the stuff you put in model: [] of a render()) is the 'page scope'.
As for the manual example I have no clue why they would show any scoping at all in a view g:set operation, setting variables in the view should generally be avoided anyways (separation of concerns and all that jazz).
Related
I have a website built from Ember.js. A user can access a page through URL http://..../view?showTitle=true. However I don't want to explicitly expose the parameter showTitle=true to the user (meaning user will only see http://..../view). This URL is automatically generated and serves as a redirect destination URL. So, I have to remove it manually somewhere before the page load. But I still need this value of this query parameter to query data. Is there a way to achieve that (A example would be great)? What about do it without refreshing the router?
Actually, an example of your scenario would be greater :)
There are some other ways to store data while transitioning to a route. Such as: storing the params in transition object or storing the value in a service. Create a redirection route, use beforeModel hook to grab the value from query params then do a redirection to the real route.
A working example is: ember-twiddle-1
By the way, even if you don't describe your queryParamsin your routes, you can access them via transition.queryParams. This seems a bit hacky. But it works: ember-twiddle-2 (Note: It doesn't work in the same route.)
Updated:
At the setupController hook you can override the controller parameters. So you can remove the parameters from the url. ember-twiddle-3
Suppose I have URL as
http://someurl.com/Search?q=a&page=8
(Above mentioned URL is getting called throug AJAX, in MVC4.paging)
What I want is to show only upto http://someurl.com/Search?q=a
I want to hide my second parameter which is page=8
Is this possible?
EDIT: More confusion to add.
<a data-ajax="true" data-ajax-loading="#divLoading" data-ajax-method="POST" data-ajax-mode="replace" data-ajax-success="successPaging" data-ajax-update="#searchresults" href="/Search?q=a&page=1" title="Go to first page"><<</a>
Is button of Next in my Paging, it is making an AJAX request, So I don't know how to change GET to POST for this.
The URL isn't there just for looks; it's telling the server what resource is being requested, and in the case of a query string, that's information the server needs to return a response. http://someurl.com/Search?q=a is a completely different resource than http://someurl.com/Search?q=a&page=8. With a GET request, all you have is the URL, so all the information the server needs must be in the URL. What others in the comments are telling you to do is use a POST request, which among other things includes a post body. In other words, you can pass information to the server both in the URL and in the post body. That allows you to remove the page parameter from the URL and include it in the post body instead. That's the only way you can achieve what you want.
That said, strictly speaking, a POST is inappropriate for fetching a resource like this. POST should be used to update or modify a resource or to call some atomic method in an API scenario. It can also be used for the creation of resources, although PUT is more appropriate there. GET is supposed to be used to return a resource which is not variable. For example, any request to http://someurl.com/Search?q=a&page=8 should always return the same response no matter what client requests it. And, it's even less important what URL is actually being used because the user does not see it at all, since you're requesting it via AJAX (it won't show in the navigation bar). Just keep it as a GET request and leave the parameters as they are.
Shouldn't PUT be used to Create and POST used to Update since PUT is idempotent.
That way multiple PUTs for the same Order will place only one Order?
The difference is that a PUT is for a known resource, and therefor used for updating, as stated here in rfc2616.
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations. In
contrast, the URI in a PUT request identifies the entity enclosed with
the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
I do see where you are coming from based on the names themselves however.
I usually look at POST as it should be the URI that will handle the content of my request (in most cases the params as form values) and thus creating a new resource, and PUT as the URI which is the subject of my request (/users/1234), a resource which already exists.
I believe the nomenclature goes back a long ways, consider the early web. One might want to POST their message to a message board, and then PUT additional content into their message at a later date.
There's no strict correspondence between HTTP methods and CRUD. This is a convention adopted by some frameworks, but it has nothing to do with REST constraints.
A PUT request asks the server to replace whatever is at the given URI with the enclosed representation, completely ignoring the current contents. A good analogy is the mv command in a shell. It creates the new file at the destination if it doesn't exist, or replaces whatever exists. In either case, it completely ignores whatever is in there. You can use this to create, but also to update something, as long as you're sending a complete representation.
POST asks the target resource to process the payload according to predefined rules, so it's the method to use for any operation that isn't already standardized by the HTTP protocol. This means a POST can do anything you want, as long as you're not duplicating functionality from other method -- for instance, using POST for retrieval when you should be using GET -- and you document it properly.
So, you can use both for create and update, depending on the exact circumstances, but with PUT you must have consistent semantics for everything in your API and you can't make partial updates, and with POST you can do anything you want, as long as you document how exactly it works.
PUT should be used for creates if and only if possible URI of the new resource is known for a client. New URI maybe advertised by the service in resource representation. For example service may provide with some kind of submit form and specify action URI on it which can be a pre populated URI of the new resource. In this case yes, if initial PUT request successfully creates resource following PUT request will only replace it.
It's ok to use POST for updates, it was never said that POST is for "create" operations only.
You are trying to correlate CRUD to HTTP, and that doesn't work. The philosophy of HTTP is different, and does not natively correspond to CRUD. The confusion arises because of REST; which does correspond to CRUD. REST uses HTTP, but with additional constraints upon what is allowed. I've prepared this Q & A to explain the HTTP approach to things:
What's being requested?
A POST requests an action upon a collection.
A PUT requests the placement of a resource into a collection.
What kind of object is named in the URI?
The URI of a POST identifies a collection.
The URI of a PUT identifies a resource (within a collection).
How is the object specified in the URI, for POST and PUT respectively?
/collectionId
/collectionId/resourceId
How much freedom does the HTTP protocol grant the collection?
With a POST, the collection is in control.
With a PUT, the requestor is in control (unless request fails).
What guarantees does the HTTP protocol make?
With a POST, the HTTP protocol does not define what is supposed to happen with the collection; the rfc states that the server should "process ... the request according to the [collection's] own specific semantics." (FYI: The rfc uses the confusing phrase "target resource" to mean "collection".) It is up to the server to decide upon a contract that defines what a POST will do.
With a PUT, the HTTP protocol requires that a response of "success" must guarantee that the collection now contains a resource with the ID and content specified by the request.
Can the operation result in the creation of a new resource within the collection?
Yes, or no, depending upon the contract. If the contract is a REST protocol, then insertion is required. When a POST creates a new resource, the response will be 201.
Yes, but that means the requestor is specifying the new ID. This is fine for bulletin boards, but problematic with databases. (Hence, for database applications, PUT will generally not insert, but only update.) When a PUT creates a new resource, the response will be 201.
Is the operation idempotent?
A POST is generally not idempotent. (The server can offer any contract it wishes, but idempotency is generally not part of that contract).
A PUT is required to be idempotent. (The state of the identified resource is idempotent. Side effects outside of that resource are allowed.)
Here is the rfc:
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.3
It depends..
you can create/update sites/records with both.
When the client is specifying the URI then PUT is the way to go.
e.g. Any Code Editor like Dreamweaver, PUT is the right protocol to use.
have also a look at this thread: put vs post in rest
I completely understand the differences between the two in terms of form handling, user discretion and privacy of data, but in what situation would anyone rather use GET over POST when sending form results?
Thanks
W3C HTML 4.01 Recommendation on the appropriate usage of GET and POST:
The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.
If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the "post" method should be used.
Note: The "get" method restricts form data set values to ASCII characters. Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire [ISO10646] character set.
GET places parameters in the URL itself, allowing everyone to see. While POST would be ideal for logins and security-sensitive data, GET is ideal when you want a dynamic page to be bookmarked.
Take a forum for example. The thread which shows all posts within it is loaded dynamically. There doesn't exist a page for every thread available, meaning parameters must be provided which indicate which thread to load. These parameters are passed using GET so that you can bookmark the page and that exact URL with the parameters provided will be used again to load the page.
For instance, to make form data visible in logs.
If i need that user can save a bookmark of next step/page (for whatever reason) i would use GET other than that probably POST.
Both are unsafe and you must escape both.
I have a pretty simple ASP.NET MVC page and am using TinyMCE to allow users to enter comments. However, when I pass the data to a controller I receive the following error message:
A potentially dangerous Request.Form
value was detected from the client
The consensus is that ValidateInput("false") should be set on the Action method but somehow that does not sit well with me. I have tried to intercept this by ordering my action methods and sanitizing the data through my ActionExecitomgContext ActionParameters however this error keeps occurring time and again. Does anyone know of a way to allow this content through (or properly intercept it) without disabling ValidateInput
Do you have specifics on why it doesn't sit well? ValidateInput("false") on the one action that accepts HTML is the proper way to go. The input validation is an old ASP.NET feature that is on by default for security in depth, but is like a sledge hammer. It doesn't understand the nuances of allowed HTML.
For that one action method, you could write your own ValidateSafeHtmlAttribute action filter and put that on the method instead. Maybe that one internally encapsulates a ValidateInput set to false and then does its own validation specific to your scenario. That'd be my recommendation.