Hi, folks, happy new week to everyone.
I have some functionality I would like to implement and have been going over in me head how I will do it.
The plan is to, when enter is pressed on a form search element, it checks the contents of the string and either returns page_a.html if criteria a is met or page_b.html if criteria b is met.
what I’ve been trying to work out the consequences of in my head is where I should put the logic for this?
1- in views.py which would mean sending to a specific view, doing the logic, sending to a different view.
2- in the template that has the search element. Do the logic, and send to a specific url depending on the logic. I’m not sure yet if django template language even allows this logic.
3- do it all in javascript
What would be the industry standard method to do this?
There isn’t one. There’s no “best practice” here either. Take your pick.
For clarity, you wrote:
Are you actually talking about returning one of two static pages, or are you talking about returning the output of one of two views, or are you talking about one view that may render one of two templates for the same data?
I generally wouldn’t recommend #2. As far as I’m concerned, the template is never the right place for any decisional logic.
Beyond that, either 1 or 3 is going to be fine. I’m not sure what you’re thinking of when you say “sending to a different view”, but a view is just a function that accepts a request and returns a response. You can always call a function from a different function.
e.g.
def decision_view(request):
view_selector = request.GET.get('q')
if view_selector == 'option-1':
return view_one(request)
elif view_selector == 'option-2':
return view_two(request)
else:
return default_view(request)
Obviously, the conditionals need to be more intricate if the search element isn’t a simple “a” or “b” type test.
Yea, I was pretty sure that #2 wasn’t the way but put it in there to make clear that I knew it existed as an option. I understand functions can call other functions, it’s Django I have questions about not python lol and pretty much exactly how you’ve shown in your decision_view() is how I see doing it.
How I really should have asked this was I was wondering about urls.py. How I understand django is that we access views through url patterns and I was thinking about the redirects (from the url that points to decision_view() to the url that decision_view() decides to send us to.
Which is why I was considering JS to pull the string, make the decision and choose which view (function) to use to render the appropriate template.
This way would skip the redirect (I feel redirects should be avoided if possible, even though I have no solid reason for feeling that way) unless there’s also a way that I’m overlooking to keep it purely python and not use the redirect.
I should have been clearer in my OP, apologies
What makes you think that the sample I provided creates a redirect?
Django is Python code. There’s nothing magic about it.
I find it hilarious you edited your OP to add this line, you even italicized ‘is’, even though it’s the one thing we can be absolutely sure everyone here knows.
Back to the story:
If I use the following inside views.py
def search(request):
# here is where to start thinking about the conditional on whether to archive or search
search_string = request.GET.get('search-for')
if search_string == "archive":
return archive(request)
# return HttpResponseRedirect(reverse('searchnet:archive', args=(search_string,)))
engine = SearchEngine()
search_results = engine.google(search_string)
template = 'searchnet/results.html'
context = {
"menu": CATEGORIES,
"search_results": search_results[:10],
"side_results": search_string[::-1],
}
return render(request, template, context)
def archive(request):
template = 'searchnet/archive.html'
context = {}
return render(request, template, context)
It works but the url isn’t localhost:8000/archive like I expected it to be. It’s localhost:8000/search/?search-for=archive as it would be if the search was done even though it’s definitely rendering archive.html. I figure this is because archive.html is being loaded only through the function and not urls.py. Which I’m not really content with. I figure the solution is a reverse redirect, which I haven’t managed to get working yet.
What would be your solution?
Actually it’s not. There are many people here starting with Django and no Python experience.
Nor did I edit my original post, I’m not sure what gives you that idea.
To not worry about things that don’t matter.
If you don’t do a redirect, then your URL is as it’s submitted.
So make your choice - you can either do a redirect, which yields a new URL, or return the response from the view, which is the url at which the request was submitted.
Unfortunately, this is something that matters. It makes the impressive someone did a half ass job and was too lazy to do it right.
Anyways, now you’ve got your answer to this question
I never said anything about everyone having python experience, what I said was that everyone here knows that django is python. Which they do, and I stand by. Have a good night