Hi all,
I was quite surprised that I couldn't find a way to override table
names for an application's models on a per-deployment basis (i.e. in
settings.py or some other project/site specific file instead of
modifying the models.py file of the app itself)
Although I admit all of these are rare, I
I am sorry folks, I just found the corresponding issue:
http://code.djangoproject.com/ticket/9245
however, i would still be interested in discussing the reasons behind
this - and why the patch provided in the ticket did't get applied
yet ;)
flo
--~--~-~--~~~---~--~-
choices are defined, if form_class is a subclass of ChoiceField an if
so, leave it alone. Otherwise the default (TypedChoiceField) can be
used as it is the case now. What do you people think?
I could open a ticket if feedback here suggests so. All other
suggenstions regarding my code are welcome!
On Jan 21, 10:11 am, Malcolm Tredinnick
wrote:
> > Coming back from the generalization to my usecase, i cannot see how
>
> > {% with a as b %}
> > {% with x as y %}
> > {% include "foo.html" %}
> > {% endwith %}
> > {% endwith %}
>
> > is syntactically or semantically superior to
>
> > {% includ
On Jan 21, 12:06 am, Malcolm Tredinnick
wrote:
> Huh? You have some change you want to make to the way a template tag
> behaves, but you don't want to write a custom template tag to do that?
> That doesn't sound very logical. If you want template tag behaviour, use
> a template tag.
No, no, th
Hi all,
in my templates I often use combinations of "with...as" and "include"
for modularization of HTML building blocks, like so:
{% with "save" as label %}{% include "components/button.html" %}{%
endwith %}
however, this is a bit cumbersome if used frequently or if multiple
variables must be
On Jan 20, 7:11 pm, "Karen Tracey" wrote:
> From a brief glance at the source, try specifying empty_label='whatever you
> want' as a parameter to the ModelChoiceField. This probably should be
> documented, but I can't find it.
Wow, strange, I could have sworn that I tried that without success
ll '---' for the None choice and not 'Nothing
here' as I would have expected. Any suggestions how I could change
that default value, preferrably even without introducing my own
subclass?
Regards,
Flo Ledermann
--~--~-~--~~~---~--~~
You re
in my settings. Will open a
ticket once I am back from a meeting.
Regards,
Flo
On Jan 11, 2:22 pm, Malcolm Tredinnick
wrote:
> On Sun, 2009-01-11 at 03:41 -0800, Flo Ledermann wrote:
> > Hi all,
>
> > I just bumped into a problem I can't resolve: after adding the {%
Oh, I should probably add that I am using
# coding=utf-8
on some of my source files, because they contain unicode default
values etc.
Flo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To p
aracter u'\u2019' in position 19: ordinal not in range(128)
I haven't used the debug tag before, and googleing the error message
didn't bring up anything useful for me, so I am turning to the group
for help. I paste the stack trace and a subset of my settings below.
Thanks
Malcolm,
thanks for taking the time to clarify the concept for me. I can see
now that Django's approach is valid if one takes a form as a
specification of what "has to be there" (hence the exclude mechanism
in ModelForms) and not, as I did, of what "could be submitted". I
still have a vague feeli
, Malcolm Tredinnick
wrote:
> On Thu, 2009-01-08 at 07:08 -0800, Flo Ledermann wrote:
> No. Don't ask the form class to read your mind. Create a form that knows
> which fields it expects so that errors can be raised correctly and
> validation will occur normally.
I am not asking
Karen,
On Jan 9, 12:40 am, "Karen Tracey" wrote:
> Is there some reason you are not simply using exclude in Meta for the form
> to avoid having these fields present in the form at all:
this would require me to create ModelForm classes for all subsets of
the form I want to use. In my use case I
Hi all,
after some more thinking, the workaround I came up with is now:
if form.is_valid():
for key in form.cleaned_data.keys():
if not key in request.POST: del form.cleaned_data[key]
form.save()
This removes all values that are not found in the original request
from the form da
the default behavior?
I believe the issue is actually not constrained to ModelForms but
probably applies to all forms in general, but it would be especially
handy to use ModelForms in such a sparse way in some scenarios.
Regards,
Flo Ledermann
--~--~-~--~~~---~--~~
Graham,
thanks for answering! it still feels odd comapred to the otherwise
wisely designed parts of django... adding a directory AND its parent
to a source path is something i have never experienced in any
framework, in any language before. But then there is something new to
learn every day ;)
i
refactoring the setup in a way that hints newbies in a more
deployment-friendly way of setting up their projects from the
beginning, instead of causing refactoring troubles later on.
All the best and thanks to creators and contributors for a great
framework!
flo lederma
18 matches
Mail list logo
