Hours of Operation Middleware
Middleware for implementing "hours of operation" for a website. In use (as configured here) on http://ianab.com/.
- middleware
- hours
- closed
Middleware for implementing "hours of operation" for a website. In use (as configured here) on http://ianab.com/.
** DEPRECATED**, use [django-reversetag @ github](http://github.com/ulope/django-reversetag/tree/master) instead. If you want to be able to use context variables as argument for the "url" template tag this is for you. Just put this code somwhere where it will be run early (like your app's _ _init_ _.py) and of you go. Usage: {% url name_of_view_or_variable arg1 arg2 %} **NOTE:** This may possibly break your site! Every view name that is passed to url will be tried to be resolved as a context variable first! So if there is a variable coincidentally named like one of your views THEN IT WILL BREAK. So far it works great for me, but keep an eye out for name clashes.
A simple template tag that generates a random UUID and stores it in a name context variable.
This snippet is working code, however it is not intended for proper use, rather to garner comment on an alternative style of view - using a class for views, rather than a function. While working with views, I've often felt that the traditional django code layout splits concerns in an unnatural fashion. The parameters for a view must be maintained in both the urls file as well as the view for example, and there is no neat way of grouping multiple accessor for a REST resource. This 'shim' code aims to propose an alternative architecture, that is interchangeable with the existing system. Rather than include a tuple of urls, instead a list of classes is provided. Each class models a resource, or page. Page objects have a url property and name property, so it is therefor trivial to reconstruct the url tuple from the class, but allow more simplicity and structure in relating the methods of the resource. You may notice that this structure closely follows the architecture of the web.py framework - this syntax did indeed play a part in the concept for such a structure. While this paradigm may not be suitable in all situations, I believe it promotes a simpler, more encapsulated views architecture. Any comments and feedback are welcomed. Example usage (untested, sorry): class Homepage(Page): def get(request): return HttpResponse("Hello World") urlpatterns = patterns('', Homepage, url('^existing$', existing.view.function, name = "foo"), )
Use this in your form if you want to accept input in microseconds. In a ModelForm you can override the field like this: def __init__(self, *arg, **kwargs): super(MyForm, self).__init__(*arg, **kwargs) self.fields['date'] = DateTimeWithUsecsField() *Update* May 26 2009 - Updated to address a couple issues with this approach. See http://code.djangoproject.com/ticket/9459
I wanted a global way to filter profanity w/out having to modify every model, view, or form. While middleware takes overhead, this technique is intended mainly for sites w/few postbacks. Hopefully this snippet will lead to more/better techniques in the comments below. Usage (settings.py): MIDDLEWARE_CLASSES = ( 'PROJECT_NAME.FILE_NAME.ProfanityFilterMiddleware', )
This is a basic stub for a model that you can use to easily add customizable JSON serialization to your models. Make your model inherit from JsonableModel, and then define the models/yourmodel.json template with whatever information from the model that you want to make available.
Given a string, it first lowercases it, then uppercases the first letter of each sentence. Helpful when dealing with awfully formatted entirely UPPERCASE XML product data feeds.
returns a list of (argname, value) tuples (NB: keeps ordering and is easily turned into a dict). Params: * tagname : the name of calling tag (for error messages) * bits : sequence of tokens to parse as kw args * args_spec : (optional) dict of argname=>validator for kwargs, cf below * restrict : if True, only argnames in args_specs will be accepted If restrict=False and args_spec is None (default), this will just try to parse a sequence of key=val strings. About args_spec validators : * A validator can be either a callable, a regular expression or None. * If it's a callable, the callable must take the value as argument and return a (possibly different) value, which will become the final value for the argument. Any exception raised by the validator will be considered a rejection. * If it's a regexp, the value will be matched against it. A failure will be considered as a rejection. * Using None as validator only makes sense with the restrict flag set to True. This is useful when the only validation is on the argument name being expected.
Very simple proof-of-concept that uses the django.forms library (newforms) for validation, and formalchemy for saving the model instance using sqlalchemy. it can be used like this (pseudo-code): if form.is_valid(): form.save(session=Session, app_label='Contact') Feel free to improve the concept. Ideally, either use formalchemy or django.forms but not both like this example. ;-)
This is the code for a template tag. Put this code in your template to render your messages: {% for message in messages %} {% render_user_message message %} {% endfor %} When you're adding a message to the user's message set, follow these rules: If you want a message to appear as an error, append "0001" to the end of it. To appear as a notice, append "0002" to it. To appear as a happy message, appear "0000" to it. If no code is present, it will default to displaying as an error. This makes use of the classes "error", "notice", and "success", so you need to define these in your CSS. For help with custom template tags, see [the Django docs](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/)
There are several nice ModelAdmin subclasses that provide useful functionality (such as django-batchadmin, django-reversion, and others), but unfortunately a ModelAdmin can really only subclass one at a time, making them mutually exclusive. This snippet aims to make mixing these classes in as easy as possible -- you can inherit your model admin from it, add a tuple of mixins, and it will dynamically change the inheritance tree to match. This isn't guaranteed to work with all ModelAdmins, but so long as the mixins play nice with django modeladmin they *should* work.
Add's updated and created fields to a model if mixed in. Example that uses the name as the representation: class Company(models.Model, UnicodeReprMixIn): """ A representation of a comic book company. """ name = models.CharField(max_length=255) slug = models.SlugField() logo = models.ImageField(upload_to=os.path.join('upload', 'company_logos')) url = models.URLField(verify_exists=True) _unicode = "name"
This code assumes your XFN field is called 'rel' in models. See the last call (addLoadEvent down the bottom) for the two lines requiring modification; otherwise, aside from the Django-styling involved, it can be used anywhere. The accompanying model.py and admin.py information can be found here: [http://www.djangosnippets.org/snippets/1265/](http://www.djangosnippets.org/snippets/1265/). I'm no master programmer, so feedback/comments/criticism is more than welcome. EDIT: Fixed my esoteric dev. comments and removed references to spawning more overlords.
Slightly different validation to that of jpwatts; developed with knowledge of that snippet but written up from scratch for use as a fallback for when the Javascript Assist is off. I'm no master programmer, so feedback/comments/criticism is more than welcome. The accompanying Javascript (xfn-admin.js) can be found here: [http://www.djangosnippets.org/snippets/1266/](http://www.djangosnippets.org/snippets/1266/).
3110 snippets posted so far.