Simon,
Ran in the same issue as you.
I filed documentation ticket #6690 to document a clean way to
dynamically create ModelForm instances. The ticket got closed because
the runtime creation of forms "isn't common enough"...
See also the thread "ModelForm: Dynamically change model and fields"
on
On Mon, Apr 7, 2008 at 3:49 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> would be much less daunting to those that haven't read the Friedl book
> than this:
>
> url(r'^(?P[-\w]+)/$', myview),
Note that this example is more complicated than it needs to be. I'd
write it like this:
(r'^([-
On Mon, Apr 7, 2008 at 3:49 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> It was discussed previously that making URL matching easier by not
> having to understand regular expressions would be a nice goal, and
> perhaps a nice 1.0 goal...
Two things:
1. If Django were going to support an altern
Rob Hudson wrote:
> * Defaulting to "[-\w+]" makes sense to me as a default regular
> expression to catch most URL patterns. It can catch strings, slugs,
> and numbers. Things like this would still work: "/{{ year }}/{{ month
> }}/{{ day }}/{{ slug }}/" but may not be as optimized as specificall
If I may point to a new ticket I just created related to sessions and
race conditions
http://code.djangoproject.com/ticket/6984
It fixes a lot of weirdness I was experiencing. It is still not thread
safe though I am not sure that is an issue since in my (limited)
testing there was a one-to-one ma
On Apr 8, 10:46 am, Mike Axiak <[EMAIL PROTECTED]> wrote:
> but if Django were to "support" pre-1900
> dates, then it stands to reason code wouldn't break if written like
> this::
>
> instance.field.strftime("%Y-%m-%d")
Actually, I've backpedalled a bit in my new patch (uploaded just now).
No
On Mar 19, 10:07 pm, Philippe Raoult <[EMAIL PROTECTED]>
wrote:
> Hi everyone,
> [...]
> Anyway, the issue is that we have two different strategies for fixing
> #1443(and two different patches):
> 1. simply replace strtfime calls with custom format prints
> 2. replace datetime by a specific module
On Mon, 2008-04-07 at 03:09 -0700, mrts wrote:
> > Realise that I am in agreement with you that logout (and possibly login,
> > I haven't worked through the implications there) should be changed to
> > clear the session by default. There's no strong reason not to do that,
> > since the session is
It was discussed previously that making URL matching easier by not
having to understand regular expressions would be a nice goal, and
perhaps a nice 1.0 goal...
http://groups.google.com/group/django-developers/browse_thread/thread/b4c237ad76f9eeca/b9b2acc81fe6e5cf
I just stumbled across yet anoth
On Mon, Apr 7, 2008 at 9:09 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> I'm also mostly in agreement here.
As am I. Syntax is tough, of course; here's my two cents::
form = ModelForm(model=Person, exclude=["pay_grade"])
Jacob
--~--~-~--~~~---~--~~
Yo
On Mon, Apr 7, 2008 at 10:16 AM, Brian Rosner <[EMAIL PROTECTED]> wrote:
>
> > I like the syntactic sugar provided by declarative APIs such as
> > ModelForm, but I think it's important to provide a non-declarative
> > alternative for people who need to dynamically construct something at
> > ru
> I like the syntactic sugar provided by declarative APIs such as
> ModelForm, but I think it's important to provide a non-declarative
> alternative for people who need to dynamically construct something at
> runtime rather than baking the details in to their source code.
I agree with you Simon.
On Apr 7, 2:15 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > I'd still like to see form_for_model stay (or be replaced by the above
> > or similar) rather than being deprecated.
>
> Personally I don't see much call for it; dynamically building a
> ModelForm is easy enough, and maintaining t
On Apr 7, 2:15 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > I'd still like to see form_for_model stay (or be replaced by the above
> > or similar) rather than being deprecated.
>
> Personally I don't see much call for it; dynamically building a
> ModelForm is easy enough, and maintaining t
On Mon, Apr 7, 2008 at 7:52 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> To answer my own question, it turns out dynamically constructing a
> class is really easy if you take advantage of closures:
Yup. I've got a generic user-profile-editing app which uses that exact
trick to get a form for
On Apr 7, 1:05 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> I suppose I could dynamically
> construct a ModelForm subclass at runtime (any pointers on how to do
> that, including dynamically creating the inner class called "Meta",
> would be welcome) but for the above the existing form_for_mode
form_for_model is marked as deprecated but ModelForm does not appear
to be a full replacement for it. Given an arbitrary model class (i.e.
one that is defined at runtime, not at "compile" time) there is no
clear way of creating a form from it using the ModelForm mechanism.
Here's what I am doing
> def show_foo(request):
> request.session['foo'] = 'bar'
> request.session.delete(request.session._session_key)
> return HttpResponse(request.session['foo'])
>
> In [1]: from django.contrib.sessions.backends.db import SessionStore
> In [2]: s =
> SessionStore(session_key='61a271f29a67
> Realise that I am in agreement with you that logout (and possibly login,
> I haven't worked through the implications there) should be changed to
> clear the session by default. There's no strong reason not to do that,
> since the session is over when logout is called (I'll raise that
> separatel
19 matches
Mail list logo
