decorators and generic views

I think with the move to class-based Generic Views it is necessary to update this documentation: Limiting access to generic views To limit access to a *generic view*, write a thin wrapper around the view, and point your URLconf to your

Configuring common site URL paths for use in templates

I have a bunch of regular site paths that I'd like to be able to refer to both in my Python code and in my templates, e.g. settings.py: site_root = "/portal" contact_url = site_root + "/contact" sitemap_url = site_root + "/sitemap" login_url = site_root + "/account/login" logout_url = site_root

Re: FormPreview with file upload problems

This problem is more subtle than I had originally appreciated. Textual data is just re-submitted via an embedded hidden form, and the security hash is used to ensure that it hasn't been modified. File data is harder to cope with. There are a few options: 1. The originally uploaded file is

FormPreview with file upload problems

I've followed the instructions here: http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-preview/ to setup a form preview system. The problem is that my form includes a mandatory file upload. I modified the form template to include: however I still have problems processing the

upload_to chicken and egg problem

I would like to do the following: class WSMRTask(GridTask): tasktype= "wsmr" mtz_fp = FileField("MTZ file", upload_to=WSMRTask.path_gen) class GridTask(Model): tasktype= "unspec" def path_gen(instance, filename): return "%s/%s" % (WSMR_RELPATH,

FormPreview and ModelForms

I'm using FormPreview with a ModelForm. My done() method gets the request and the cleaned_data once form.is_valid() evaluates to True. I'm wondering if I need to do anything special to use the cleaned_data or handle the form-uploaded files. My current class definition is: class

Re: Including apps for inherited models in INSTALLED_APPS

I'm (reasonably) happy to include base models in INSTALLED_APPS, but this argument: On 2/8/11 4:32 AM, Tom Evans wrote: > Explicit is better than implicit. If you want models from app 'base' > installed on your system, you add the 'base' app to INSTALLED_APPS. > Otherwise, its a series of $MAGIC

Re: read-only Form.as_* views

On 2/7/11 5:29 PM, Ian Stokes-Rees wrote: > This sounds good. Form Preview could be useful, but right now I just > want to be able to use Generic Views (DetailView.as_view()) to render > the default context object using "as_table()", but I'm failing to do that. > > {{ o

Re: read-only Form.as_* views

This sounds good. Form Preview could be useful, but right now I just want to be able to use Generic Views (DetailView.as_view()) to render the default context object using "as_table()", but I'm failing to do that. {{ object.as_table }} returns nothing, whereas, {{ object.name }} etc. works

Re: Including apps for inherited models in INSTALLED_APPS

On 2/7/11 3:50 PM, Shawn Milochik wrote: > Because when the model isn't abstract, the fields > in the base model aren't created for the subclass -- the subclass has > a foreign key to an instance of the base model. > That last bit should explain why you need to have the base app in > installed

read-only Form.as_* views

fields displayed just as table entries or textareas which can't be edited. In other words, no or tags. TIA. Ian Stokes-Rees -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegr

Re: Including apps for inherited models in INSTALLED_APPS

On 2/7/11 3:38 PM, Shawn Milochik wrote: > Is your base model abstract? If it is not, then the ORM will want to > create it in the database. No, it isn't abstract. It has a particular content model and methods associated with it. When you say the ORM will "want" to create it in the DB, do you

Including apps for inherited models in INSTALLED_APPS

django.db.models.Model and consequently create the necessary tables for MyBaseModel. Or have I just misunderstood why it was necessary for me to include "base" in order to get the tables created properly by "manage.py syncdb"? TIA, Ian Stokes-Rees -- You received this mess