modular settings / site settings
a snippet to split up settings or to reuse and modify settings
- settings
- custom
- modular
a snippet to split up settings or to reuse and modify settings
This widget can be imported in your forms.py file and used like so: formfield = forms.ModelChoiceField(widget=SelectDropdownWidget, queryset=Model.objects.all()) The javascript is provided by [filament group's Scott and his jQueryUI Selectmenu](http://www.filamentgroup.com/lab/jquery_ui_selectmenu_an_aria_accessible_plugin_for_styling_a_html_select/). In addition to the javascript you will need [jQuery (the latest release is fine) and jQuery UI](http://jqueryui.com/). The convenient thing is that this widget will style to match whichever jQuery UI you've 'rolled' or selected, making it highly customizable! Hopefully this helps others who wanted a nice widget with jQuery and were sad to find there were no nice default options, enjoy! :)
This is a XML-RPC server, that uses arguments in URLs and every dispatcher instance is prepared in memory during webserver run. It's good, for example, for securing XML-RPC server with hashed strings and there are a lot of similar use cases. Usage: from xmlrpclib import ServerProxy server = ServerProxy('http://example.com/xmlr-rpc/%s/' % something, allow_none=True) server.do_something(*args)
Check database constraints after dirty import
This is a simple calendar widget in Django 1.2 for Jalali Calendar usages. It actually sends a Gregorian value to server, so if you need further manipulations, you can use [GNU Jalali Calendar](http://home.gna.org/jalali-calendar/). You should also have [JalaliJSCalendar](http://farhadi.ir/works/jalalijscalendar) set up in your project. Also posted on: [Django Jalali Calendar Widget](http://texscribbles.blogspot.com/2010/06/django-jalali-calendar-widget.html)
Makes manage.py testserver accept a `--noinput` argument to delete test database without asking if it already exists; makes it emit `django.core.management.commands.testserver.testserver_setup` signal after fixtures are loaded and before server itself is started to allow custom postprocessing.
My application is made up of two main pieces: 1) an ajax client, and 2) backend services supplying data to the ajax client. Django delivers html files that bootstrap the javascript client, which in turns calls back to Django's restful services. Most of javascript code is in static .js files that being delivered to the browser bypassing Django. When calling back into Django, I started by embedding call endpoints into the javascript code. Soon, I noticed, though, that every time I adjusted an endpoint's url in urls.py, I also had to remember to go back and adjust the javascript. This was suboptimal and violated the DRY principle. I realized that all the information I needed was already in urls.py. All that needed to be done, was to find a way to expose that information to the javascript environment. The code I'm including does exactly that. It consists of two pieces: a view function and a corresponding javascript template. The view function will go through all declared urls looking for those whose name ends with '-svc'. These urls are then converted into javascript constants by the template. The url names are slightly mangled to conform to javascript identifier conventions and if you have any url parameters, they will be encoded into something that javascript can easily replace with real values at run time. For example, `url('^blog/(?P<id>[\d]+/$', 'sample.views.showblog', name='blog-entry')` will become `svc.__BLOG_ENTRY = "/blog/{id}/"` to get the uri from your javascript code, you simply make this call: `svc('BLOG_ENTRY', {id: 12345})` and you'll get back `/blog/12345/` Requirements: the javascript template assumes availability of the Namespace library by Maxime Bouroumeau-Fuseau (http://code.google.com/p/namespacedotjs/)
There are several snippets that provide a basic caching decorator for functions and methods (e.g. #202, #1130, etc.). The `Cacheable` class in this snippet extends them by (*if you don't see an unordered list below, the Markdown on this site is still broken...*): - Specifying how cache keys are determined in one of two general, flexible ways. - Exposing a few extra methods for (re)setting and deleting the cached value transparently. Given these methods, cache key management should follow DRY: keys are specified once (and only once) at instantiation time, without having to be repeated at later interactions with the cache. - Adding a variant for cacheable properties. Unlike some other snippets, the way cache keys are generated must be explicitly specified by the client; there is no automagic key generation for arbitrary `func(*args, **kwds)` calls (but can be added if desired). The reason is that all usual serialization approaches (`func.__name__`/`func.__module__`, `repr`, `pickle`, etc.) are generally fragile, unsafe, inefficient or all of the above. Explicit is better than implicit in this case.
After reading this article: http://blog.roseman.org.uk/2010/06/2/class-based-views-and-thread-safety/ and checking out this snippet: http://djangosnippets.org/snippets/2046/ I realized that I was using a class based view without even thinking about the consequences... so, without having to completely re-factor my existing class based views to make them singletons, I wrote this wrapper that should allow my class based views to work as I intended, and maintain state for a single request only.
A shortcut for generating img-s with predefined classes and attributes that mimics a html tag, while resolving context variables inside {% %} without crutches like tag/stuff/endtag. Used as `{% icon test class="spam" eggs="{{ object.pk }}" %}` yields `<img src="http://host.tld/media/icons/test.png" alt="" class="icon16 spam" eggs="42"/>`. Not customizable here for simplicity.
By using __new__ the result of a class instantiation is not an object but the result of a method call. This way classes can be used for views the same way as functions.
This class adds a cc: argument to EmailMultiAlternatives.
Useful if you can make sure your files will never collide unless they share the same contents. You point to the storage parameter when you declare an ImageField and use the hashed_path class method (seemed to make sense to bundle it with the class) to build a custom upload_to method that has to generate the path based on the file contents. Combining both will allow you to deduplicate files uploaded repeatedly.
*WARNING* This is *extremely* slow. This snippet allows you to easily prevent *most* race conditions (if used properly). Feel free to extend on top of this as you like, I'd appreciate any comments to [email protected]
Small hack to inherit region content from the translated object. code should be placed in models.py, where the Page object is created. use feincms version 1.1.2 and above