EmailListField for Django
A simple Django form field which validates a list of emails. [See this at my blog](http://sciyoshi.com/blog/2009/aug/08/emaillistfield-django/)
- fields
- forms
- form
- field
- email-list
A simple Django form field which validates a list of emails. [See this at my blog](http://sciyoshi.com/blog/2009/aug/08/emaillistfield-django/)
This view parses complex tag queries. It generates a list of model instances matching an expression of tags. The expression currently supports intersection, union and subtraction. Expressions can also be put in parenthesis and then combined with other expressions. The expression must be passed to this view in the tag_expression argument. In my application this is simply passed from the URL querystring. This snippet uses the django-tagging app. It assumes that tags are composed of alphanumeric characters, underscores, hyphens and spaces, but the django-tagging application allows tags with other characters, so you might either want to restrict users to using tags that only contain the above characters, or you might prefer to improve this snippet. Example: This URL http://example.com/people/?(deceased&parrot)|"Monty Python" will retrieve all people who are either deceased parrots or members of Monty Python. In the tag_expression argument: * ALL is treated as a keyword. If you happen (by some sad chance) to have a tag called ALL and want to use it in the expression, surround it in quotation marks. E.g. "ALL" * Examples: - famous -returns all instances of the model tagged with famous - famous&deceased -returns all instances of the model tagged both famous and deceased. - famous|deceased -returns all instances of the model tagged famous or deceased. - parrot-deceased -returns all alive parrots in the model. - ALL-deceased -returns all instances of the model that are not tagged deceased. - ALL -returns all instances of the model - "ALL" -returns all instances of the model that are tagged ALL - "great author"&deceased -returns all models tagged as great authors and deceased. Arguments: * request -- HTTP Request object * tag_expression -- a set expression of tags, supporting intersection, union, parenthesis and difference * app_name -- App for the model we're working on (defaults to pubman) * model_name -- Model on which to apply the set operations (defaults to Article) * view -- view to redirect to after the model instance list has been constructed * html_template -- HTML template to redirect (defaults to 'pubman/tag.html')
**Warning**: I'm quite sure this is **not** a best practice, but this snippet has proven being very useful to me. Handle with care. I also wonder about the impact on performance, while I didn't notice any slowdown on a very small app of mine. Idea is to expose project settings to template request context through a context processor, and \__doc__ should be self-explanatory. Of course, if you know a better way to achieve the purpose, please tell in the comments.
A common problem (it hit the Django mailinglist a couple of times) is that if you get `models.Topping.objects.all()`, you get a list of toppings, although they stand for other classes such as `SalamiTopping` or `CheeseTopping`. If you need the actual object, just derive `Topping` from `PolymorphicModel`, and say `topping.actual_instance`. This will give you e.g. a `SalamiTopping`. Sometimes you just want to check for the actual class. You can get it by saying `topping.content_type.model_class()`. There is a slight performance impact when creating objects because they have to be saved twice. NEWS: A good alternative to this approach is the [InheritanceManager](https://github.com/carljm/django-model-utils/blob/master/README.rst).
How to use it {% pycall os.path.abspath(".") %} {% pycall os.path.abspath(".") as path %} This is the {{ path }}. Syntax {% pycall module.function(...) [as variable_name] %} If there is no as variable_name, the result will be output directly.
Deploying relocatable Django sites isn't currently as trivial as it should be (see http://code.djangoproject.com/ticket/8906, http://groups.google.com/group/django-developers/tree/browse_frm/thread/fa3661888716f940/). This snippet relocates all url patterns (similarly to http://djangosnippets.org/snippets/2129/) as well as the absolute url settings of `settings.py`. This allows deployment under a different mount point with a single Django setting, without having to repeat the mount point again as a SCRIPT_NAME parameter supplied by the web server.
This snipped provides a subclass of the syndication Feed class that supports HTTP authentication (basic auth). Feeds that should support authentication can inherit from this class instead from the Feed class. It is basically the implementation of [Snippet #243](http://djangosnippets.org/snippets/243/) ported to the new-style syndication framework feeds (for which decorators don't work). Usage: class ArticleFeed(HTTPAuthFeed): def items(self, obj): return Article.objects.all().order_by('-created')[:10] def item_title(self, item): return item.title def item_description(self, item): return item.description
here is some working code from a site that maintains profile information (address, phone number, etc) for users ("Partners"). this snippet handles the submitted form (after validation) and checks to see if any fields have been changed by the partner. if so, it shoots off an email to the admin showing the current profile information with changed fields marked with asterisks.
In one situation I needed to join strings in template, so I wrote this filter. Use it like this: 1) var = 23 {{"I have eat %d apples today."|joinstrings:var}} -> "I have eat 23 apples today." var = '23' {{"I have eat %s apples today."|joinstrings:var}} -> "I have eat 23 apples today." 2) var = [23, 45] #or any iterable object (except string - see pt. 1) {{"I have eat %d apples and %d pears today."|joinstrings:var}} -> "I have eat 23 apples and 45 pears today."
I know in Django 1.2 we may acquire the same result using {% if value in arg %} but I need this filter in Django 1.1.
It is not so portable and easy as I wanted it to be because of how django forms work - they don't play well with recaptcha. To get it to work: * Add two variables to your app settings, **RECAPTCHA_PUBKEY** and **RECAPTCHA_PRIVKEY** * Derive forms you want to have a captcha from the provided `ReCaptchaForm` class (how to get it working with ModelForm? any ideas?) * * If you override the form's clean method make sure you firstly call the `ReCaptchaForm`'s clean method * * In your view, upon receiving the form data initialize the objects like this `form = YouFormClassDerivedFromReCaptchaForm(remoteip=request.META['REMOTE_ADDR'], data=request.POST)` (or request.GET of course) - this is because reCaptcha needs the user's remote ip.
Generate model data with this django management command! Data is generated based off of the model field types. And will also correctly generate foreign key's to other randomly generated records for join tables. And generate images with random colors and random words in the image - for image fields. You can supply quite a few parameters that control how the data is generated. And you can control it per field, per model. Or you can supply your own callable function which you can return your own random data. **SEE THE DOCS / EXAMPLE IN THE CODE SNIPPET FOR AVAILABLE OPTIONS, AND HOW TO CONTROL GENERATED DATA PARAMETERS** You can generate data that looks like real content, without having to write fixtures and such. Just generate it! It can generate data for these types of fields: EmailField SlugField BooleanField DateField DateTimeField TimeField IntegerField DecimalField TextField CharField IPAddressField URLField SmallIntegerField PositiveSmallIntegerField PositiveIntegerField ImageField There are also a few callables included that you can use to generate this kind of data: zip, extended zip, hashkey and uuid It's also worth noting that I keep this project up to date on my own git repository. There are a few fonts you'll need if you want to generate imaages, included in my git repo. http://gitweb.codeendeavor.com/?p=dilla.git;a=summary
This decorator is for views that one wants only users of the site to logout based on few conditions Just add the decorator and it should logout anyuser who doestnot match the condition btw I borrowed the code from django`s source code
Adds a View Link button next to the field that opens the contents of the field in a new window.
http://github.com/coleifer/django-generic-aggregation http://charlesleifer.com/blog/generating-aggregate-data-across-generic-relations/ Generate and calculate aggregations across generic foreign keys. >>> from misc import generic_annotate, generic_aggregate >>> from blog.models import Entry >>> from tagging.models import TaggedItem >>> from django.db.models import Count >>> qs = generic_annotate(Entry.objects.all(), TaggedItem.object, 'id', Count) >>> qs[0].score 5L >>> qs[1].score 4L >>> qs[1].tags u'databases django many-to-many python' >>> generic_aggregate(Entry.objects.all(), TaggedItem.object, 'id', Count) 106L # total number of times entries were tagged