I would like to get the original query (in the exact same format as sent) from Django.
Currently, django sends me a query dict object, wherein if I do querydict.urlencode(), I get the query back, but in a different format from what is sent, since dictionary mangles the positions.
For GET, we can use, request.get_full_path().
I have not found a mechanism for POST.
I require it since I am doing a HMAC, and for HMAC, the exact positioning of fields are important.
Regards
K
Sorry, this is solved.
We can use raw_post_data for that. Forgot about that.
Related
I'm using django_haystack with Solr 4.9. I've amended the /select request handler so that all requests use dismax by default.
The problem is that sometimes I would like to query specific fields, but I can't find a way to get the SearchQuerySet api to get it to play nicely with dismax. So basically I want to send the following (or equivalent) request to Solr:q=hello&qf=content_auto
I've tried the following aproaches:
Standard Api
SearchQuerySet().filter(content_auto='hello')
# understandably results in the following being sent to solr:
q=content_auto:hello
AltParser
query = AltParser('dismax', 'hello', qf="content_auto")
sqs = SearchQuerySet().filter(content=query)
# Results in
q=(_query_:"{!dismax+qf%3Dcontent_auto}hello")
Raw
query = Raw('hello&qf=content_auto')
# results in
q=hello%26qf%3Dcontent_auto
The last approach was so close, but since it escaped the = and & it doesn't seem to process the query correctly.
What is the best approach to dealing with this? I have no need for non-dismax querying so it would be preferable to keep the /select request handler the same rather than having to wrap every query in a Raw or AltParser.
In short, the answer is that it can't be done without creating a custom backend and SearchQuerySet. In the end I had to just revert back to a standard configuration and specifying dismax with an AltParser, slightly annoying because it affects your spelling suggestions.
I have what I believe to be common but complicated problem to model. I've got a product configurator that has a series of buttons. Every time the user clicks on a button (corresponding to a change in the product configuration), the url will change, essentially creating a bookmarkable state to that configuration. The big caveat: I do not get to know what configuration options or values are until after app initialization.
I'm modeling this using EmberCLI. After much research, I don't think it's a wise idea to try to fold these directly into the path component, and I'm looking into using the new Ember query string additions. That should work for allowing bookmarkability, but I still have the problem of not knowing what those query parameters are until after initialization.
What I need is a way to allow my Ember app to query the server initially for a list of parameters it should accept. On the link above, the documentation uses the parameter 'filteredArticles' for a computed property. Within the associated function, they've hard-coded the value that the computed property should filter by. Is it a good idea to try to extend this somehow to be generalizable, with arguments? Can I even add query parameters on the fly? I was hoping for an assessment of the validity of this approach before I get stuck down the rabbit hole with it.
I dealt with a similar issue when generating a preview popup of a user's changes. The previewed model had a dynamic set of properties that could not be predetermined. The solution I came up with was to base64 encode a set of data and use that as the query param.
Your url would have something like this ?filter=ICLkvaDlpb0iLAogICJtc2dfa3
The query param is bound to a 2-way computed that takes in a base64 string and outputs a json obj,
JSON.parse(atob(serializedPreview));
as well as doing the reverse: take in a json obj and output a base64 string.
serializedPreview = btoa(JSON.stringify(filterParams));
You'll need some logic to prevent empty json objects from being serialized. In that case, you should just set the query param as null, and remove it from your url.
Using this pattern, you can store just about anything you want in your query params and still have the url as shareable. However, the downside is that your url's query params are obfuscated from your users, but I imagine that most users don't really read/edit query params by hand.
I'm converting my app over to the new version of ember-data (1.13.5).
I'd like to be able to request a set of resources (e.g. this.store.findAll('post')), maintain the background reloading behaviour that comes out of the box, but also request that a set of related resources be included from the server.
i.e. something like:
this.store.findAll('post', { include: ["comments"] }
This can obviously be done with a query, but I'm assuming that kills all of the background reloading stuff?
I think what you are trying to do is sideload your comments together with the post.
I don't know how your server code for that is written, for instance in my case where I use laravel for the serverside,
I would check for the include parameter in the controller code for retrieving the post. If include comments directive has been specified, then I would take advantage of a builtin mechanism that laravel provides where you specify whether you want a model with its related models, i.e return post->with('comments');
And then with the help of a custom json serializer, you can extract the comments and add to the json for the post .
But outside of laravel, an algorithm like this would do in the serverside code for retrieving posts
Retrieve all the posts.
Check for the include parameter. If it's specified, retrieve the comments that belong to each post.
Then write code that creates a json result merging the json result for post with its comments together.
I am looking for a way to serialize a Haystack search query (not the query results) so that I can reconstruct it later. Is there a way to do this without having to intercept the parameters from off of the request object?
For context, I want users to be able to subscribe to the results of a particular search, including any new results that may pop up over time.
Edit:
I settled on storing the search with:
filter = queryset.query.query_filter
and then loading this back in using:
SearchQuerySet().raw_search(filter)
Though I suspect this will tie me to whichever particular search back-end I'm using now. Is this true? Is there a better way?
You should have the query in your request.GET. Then it should be fairly easy to construct a RSS Feed using that query.
I was about ready to start giving a jqgrid in a django app greater functionality (pagination, searching, etc). In order to do this it looks as though jqgrid sends its parameters in the GET to the server. I plan to write an urlpattern to pull out the necessary stuff (page number, records per page, search term, etc) so I can pass it along to my view to return the correct rows to the grid. Has anyone out there already created this urlpattern I am in search of?
Thanks much.
The answer to this was simpler than I realized. As stated in Chapter 7 of the djangobook in the section titled "Query string parameters" one can simply do something as follows, where "someParam" is the parameter in the query string you want to retrieve. However, Django is designed to be clean in that address bar at the top of the page so you should only use this option if you must.
The query string might look something like this.
http://somedomainname.com/?someString=1
The view might look like this.
def someView(request):
if 'someParam' in request.GET and request.GET['someParam']:
someParam = request.GET['someParam']
Hopefully this is of some help to someone else down the road.