All I need is just <script>location.href</script> value in JSTL(or JSP).
Just same as the web browswers display. But it's not that easy.
I'm using Tiles2 and request.getRequestURL() shows tiles base jsp location like /WEB-INF/tiles/base.jsp...
And I found <%=request.getAttribute("javax.servlet.forward.request_uri")%> shows what I want.
https://stackoverflow.com/a/11387378/411615
But still it's not enough. it's not showing protocol and domain.
And I searched again.
http://${pageContext.request.localName}<%=request.getAttribute("javax.servlet.forward.request_uri")%>
It looks dirty and does not contain parameters. I would make it like this...
Map<String, String[]> parameters = request.getParameterMap();
for(String parameter : parameters.keySet()) {
...
}
But it's weird. In javascript it's so simple, but in JSP it's very tough.
Is there any neat way?
My environment isSpring 3.1, Tiles2.
The Request object is all you get on the server side. There's no way to know what was in the original href link because the browser sends the fully assembled URL to the server. Your options are 1) use some javascript trickery on the client side to send the original href as a parameter or header value, or 2) poke around in the Request object to get what you need. 2) is better.
Related
I have a URL that in the browser shows like this https://localhost:3000/location#valueIwant=1234.
I am trying to get access to the valueIwant value but all of the items I try ctx.request.path, ctx.request.href, etc but all seem to not have the values after #. How do I parse this part of the url.
Also this is coming from a redirect.
Everything after the # is not sent to the server. The purpose of the fragment is to create a link to a specific subsection of a page.
If you want to send specific parameters to the server, the right way to do it is to use the query part (everything after ?), not the fragment part. This is by design.
Halo ! I'm trying to implement dropzonejs in a very specific way. Actually I follow the standard implementation described on the official page. Everything works perfectly.
But I'm willing to attach the server's generated URI for each uploaded file directly when uploaded : when uploading it's creating a database entry with some stuff like a page uri with title etc. This mean that the server would return as a response the id of the database saved file in order to attach the href attribute with its value to the the element in front.
This is quite ok to do this when only one file is uploaded, but it becomes trickier when bulk uploading.
So maybe I didn't understand the documentation well (and I'm quite sure I didn't), but is there any way to add custom data-dz-like attributes based on my server's response ? I'd like something like data-dz-url where the url points to a database entity (not the file itself).
Or if not if there is an "easy way" to handle this.
Thanks a lot
Here is the answer :
myDropzone.on('success', (file, response) => {
file.previewElement.href = "/admin/media/"+response.id+"/show/"
})
file is reference to the current uploaded element. It's possible to extend it's html attributes through previewElement. Setting the data-type attribute in the template before, then assigning it the right value works aswell.
Hope this will help some.
On Xamarin iOS. I'm using HttpClient to get a JSON string. The problem is that it ignores updates and gives me the same JSON response if I query the same URL. I want it to not cache anything and always actually query the URL and give me the new response.
This sounds trivial, there must be a simple way for this. I'm using a Forms shared project.
I assume you are setting the cache-control header to no-cache?
client.DefaultRequestHeaders.CacheControl.NoCache = true;
If so but it still doesn't work - maybe the server is caching the response? If it comes down to it, you can usually defeat something like that by adding a cachebuster to the querystring though. Just append a bogus param and pass it a unique value each time. For example, if your URL is http://my.url.com/resource/someid then you can defeat the caching by using http://my.url.com/resource/someid?b=1 and then increment that "b" param with each call.
I am new to Django but i am advanced programmer in other frameworks.
What i intend to do:
Press a form button, triggering Javascript that fires a Ajax request which is processed by a Django View (creates a file) that return plain simple JSON data (the name of the file) - and that is appended as a link to a DOM-Element named 'downloads'.
What i achieved so far instead:
Press the button, triggering js that fires a ajax request which is process by a Django view (creates a file) that return the whole page appended as a duplicate to the DOM-Element named 'downloads' (instead of simple JSON data).
here is the extracted code from the corresponding Django view:
context = {
'filename': filename
}
data['filename'] = render_to_string(current_app+'/json_download_link.html', context)
return HttpResponse(json.dumps(data), content_type="application/json")
I tried several variants (like https://stackoverflow.com/a/2428119/850547), with and without RequestContext object; different rendering strats.. i am out of ideas now..
It seems to me that there is NO possibility to make ajax requests without using a template in the response.. :-/ (but i hope i am wrong)
But even then: Why is Django return the main template (with full DOM) that i have NOT passed to the context...
I just want JSON data - not more!
I hope my problem is understandable... if you need more informations let me know and i will add them.
EDIT:
for the upcoming questions - json_download_link.html looks like this:
Download
But i don't even want to use that!
corresponding jquery:
$.post(url, form_data)
.done(function(result){
$('#downloads').append(' Download CSV')
})
I don't understand your question. Of course you can make an Ajax request without using a template. If you don't want to use a template, don't use a template. If you just want to return JSON, then do that.
Without having any details of what's going wrong, I would imagine that your Ajax request is not hitting the view you think it is, but is going to the original full-page view. Try adding some logging in the view to see what's going on.
There is no need to return the full template. You can return parts of template and render/append them at the frontend.
A template can be as small as you want. For example this is a template:
name.html
<p>My name is {{name}}</p>
You can return only this template with json.dumps() and append it on the front end.
What is your json_download_link.html?
assuming example.csv is string
data ={}
data['filename'] = u'example.csv'
return HttpResponse(simplejson.dumps(data), content_type="application/json")
Is this what you are looking for?
I want to use Wicket to build an application, but I have some designers that would like to write/maintain the javascript, and they basically expect 1 JS-segment per page, and a global JS-file.
I think the most natural way to add javascript in wicket is to add it per component (not per page), which would create problems for those designers (fractioned javascript, and having to write it in java-files). Is there a better way to solve this?
(of course, I expect things to work after a partial refresh.)
And a second (related) thing they'd like (and I'd like actually) is the possibility to request information in JSON-format through a static link , is this possible in Wicket?
I started with JSON by making my wicket pages return the JSON, but quickly realized there are better tools for the job, especially if you will have a full web services layer. If you just need a little JSON here and there, always via a GET, then sure, just make a Wicket page.
I ended up using Jersey with Jackson alongside of Wicket. Jersey simplifies the configuration of URLs that can do different things with different http methods (GET/POST/PUT/DELETE), as well as easily parsing query strings, etc. I'd consider going this route for heavier JSON needs.
You can easily run both Wicket and Jersey in the same web application with a little web.xml configuration.
Wicket's built in AJAX support is always stateful and thus accessed with changing URLs. If your designers aren't planning to use Wicket's JS library, it's pretty straightforward to mount a JSON page:
public class JsonReturningPage extends WebPage {
public JsonReturningPage(PageParameters params) {
String json = "{foo: 4711}";
IRequestTarget t = new StringRequestTarget("application/json", "UTF-8", json);
getRequestCycle().setRequestTarget(t);
}
}
Alternatively, you could also implement your own AbstractRequestTargetUrlCodingStrategy to directly return an IRequestTarget from IRequestTarget decode(RequestParameters params) and mount it in your application.
Regarding JS files, I'd try to educate them to use one file per component. This certainly has the advantage of less copy-paste code and simpler maitenance. Additionally, I'd certainly discourage JS in Java code. It's normally only needed to pass data or config to JS , either as variable definitions or method calls. As this data is typically in Java and JS is written by designers, it's time for designers and programmers to team up.
Quick answer to your second question is yes it is possible. Use bookmarkable links to access a resource that returns JSON data.
You can easily use the following code to dynamically communicate with Wicket:
AbstractDefaultAjaxBehavior callme = new AbstractDefaultAjaxBehavior(){
#Override
protected void respond(AjaxRequestTarget target) {
}
};
page.add(callme);
//From any ajaxrequesttarget you can simply append the following code:
target.appendJavascript("wicketAjaxGet('"+callme.getCallbackUrl()+");");
This way you can have an ajaxlink etc... that will transfer the ajaxrequest to the Wicket side. If you want to pass data (though a static link doesn't sound like that) do the following:
"wicketAjaxGet('"+callme.getCallbackUrl()+"&x='+value_to_pass_back''";
//to Read the value in the respond:
String x = RequestCycle.get().getRequest().getParameter("x");
So the url to the callback is dynamically generated (as the callback url is specific to the session) but it is formed like any other url....
To me this is 10 times simpler than building a JSON system on top of wicket instead of using the one built into it.... I use this all the time and it works great for me at least. If your solution is different/better I would like to know why perhaps.