Login

Tag "methods"

Snippet List

TemplateTag to call a method / function WITH arguments

**Callmethod** - TemplateTag to call a method on an object with arguments from within a template {% callmethod hotel.room_price_for_night night_date="2018-01-02" room_type=room_type_context_var %} ## equals ## >>> hotel.room_price_for_night(night_date="2018-01-02", room_type="standard") #Assuming "standard" is the value of room_type_context_var Django doesn't allow calling a method with arguments in the template to ensure good separation of design and code logic. However, sometimes you will be in situations where it is more maintainable to pass an argument to a method in the template than build an iterable (with the values already resolved) in a view. Furthermore, Django doesn't strictly follow its own ideology: the {% url "url:scheme" arg, kwarg=var %} templatetag readily accepts variables as parameters!! This template tag allows you to call a method on an object, with the specified arguments. Usage: {% callmethod object_var.method_name "arg1_is_a_string" arg2_is_a_var kwarg1="a string" kwarg2=another_contect_variable %} e.g. {% callmethod hotel.room_price_for_night date="2018-01-02" room_type="standard" %} {% callmethod hotel.get_booking_tsandcs "standard" %} NB: If for whatever reason you've ended up with a template context variable with the same name as the method you want to call on your object, you will need to force the template tag to regard that method as a string by putting it in quotes: {# Ensure we call hotel.room_price_for_night() even though there's a template var called {{ room_price_for_night }}! #} {% callmethod hotel."room_price_for_night" date="2018-01-02" room_type="standard" %} * **@author:** Dr Michael J T Brooks * **@version:** 2018-01-05 * **@copyright:** Onley Group 2018 (Onley Technical Consulting Ltd) [http://www.onleygroup.com](http://www.onleygroup.com) * **@license:** MIT (use as you wish, AS IS, no warranty on performance, no liability for losses, please retain the notice) * **@write_code_GET_PAID:** Want to work from home as a Django developer? Earn £30-£50 per hour ($40-$70) depending on experience for helping Onley Group develop its clients' Django-based web apps. E-mail your CV and some sample portfolio code to: [email protected] Copyright 2018 Onley Group Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice, credits, and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

  • template
  • tag
  • templatetag
  • function
  • template-tag
  • args
  • kwargs
  • methods
  • argument
  • template-arguments
Read More

Using class methods as views

This set of handlers allow one to isolate requests based on the method posted. Normally, in a view, we would do checks for request.method value and update the resource accordingly. This makes the view code pretty messy. So one way to avoid these check each time is to have a handler method (resource_handler above), that checks for the method parameter and dispatches to the handler withe the prefix <method>_handler_<suffix>. This also has the advantage of grouping related actions in a particular class. At the same time a new instance of the request handler is not created on each request (as with the google appengine handler?). Yet another advantage is by making the handler methods as class methods, the handler classes can be inherited to add further functionality to a resource "group. The disadvantage however is the inability to restrict access to a handler method to only particular methods. Eg above the "r'obja/(?P<id>[^\/]+)/delete/" would map to the delete_handler_objects if themethod was "delete" and post_handler_objects if the method was "post". However this can be worked with a different suffix passed to the handler_params method. Infact setting the suffix to "objects_delete" would result in a "delete_handler_objects_delete" handler on delete method and a Http404 on all others. Another inconvinience is the inability to detect a view handler by simply inspecting the url patterns. However, this information is carried within the handler_suffix and handler_class parameters which may infact provide greater insight into the semantics around the view handlers. Needless to say, this easily extends rest based accesses. Would greatly appreciate feedback and improvements.

  • django
  • views
  • class
  • methods
Read More

2 snippets posted so far.