Hi,
I've spotted what I think is a bug. See ticket #7651.
Basically, there is a duplicate entry in the file list (i.e.
request.FILES.getlist(file_input_name)), when using the jQuery
MultiFile plugin. It used to work just fine before #2070 was merged.
Cheers,
Julien
[1] http://www.fyneworks.com
On Jul 6, 2008, at 4:36 PM, Yuri Baburov wrote:
> At least they have or might have in common:
> * editable fields
> * readonly fields
> * fields display order
> * associated model
> * inline subforms
> * dynamic choices
> * widgets
> * widget resources: css/js files
> * validators and validation
On Sun, 2008-07-06 at 18:59 -0700, Graham Dumpleton wrote:
[...]
> If using mod_python 3.3, then from memory, in simple case one can
> access:
>
> req.hlist.location
>
> and it should give you the Location directive mount point, which
> should logically be the same as SCRIPT_NAME.
>
> This m
On Jul 6, 10:21 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Malcolm Tredinnick wrote:
> >
> > PythonHandler django.core.handlers.modpython
> > SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> > ...
> >
>
> >
> > PythonHandl
On Sun, 2008-07-06 at 10:39 -0500, Joseph Kocherhans wrote:
> Dynamic choices become an argument to the form constructor. The
> argument is a dictionary of fieldname, choices pairs where choices is
> either the choices structure we currently use, or a queryset.
This doesn't feel a lot less compl
Hi Joseph,
At least they have or might have in common:
* editable fields
* readonly fields
* fields display order
* associated model
* inline subforms
* dynamic choices
* widgets
* widget resources: css/js files
* validators and validation
The idea is that they have lots of similar func
Michael Elsdörfer wrote:
> Why stop at widgets?
Basically, because I was struggling with widgets many times but didn't
have any practical needs for changing a label, for example. I don't say
it's useless or something but I just can't defend it from my experience.
> By the way, IIRC the followi
Dynamic choices become an argument to the form constructor. The
argument is a dictionary of fieldname, choices pairs where choices is
either the choices structure we currently use, or a queryset.
Define your model and form just like you normally would.
class Task(Model):
owner = mode
On Sun, Jul 6, 2008 at 9:01 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I'd like to propose the same declarative syntax for ModelAdmin as Ivan
> suggested for ModelForms below.
>
> ModelAdmin and ModelForms both are quite similar already in NFA, and I
> think it would be The Right
On Sun, Jul 6, 2008 at 6:27 AM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
>
> ## Proposal
>
> To fix this I was thinking along the lines of:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
Hi all,
I'd like to propose the same declarative syntax for ModelAdmin as Ivan
suggested for ModelForms below.
ModelAdmin and ModelForms both are quite similar already in NFA, and I
think it would be The Right Thing if 90% of their features to be the
same and they will have only one implementati
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
> 'text': Textarea(...),
> }
Why stop at widgets? Let's say I want to change just the label of a
field, or
On Sun, Jul 6, 2008 at 8:44 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> As for dynamic choices, I think that still belongs to the init method,
> not the Meta class.
No, I mean kinda dynamic_FIELD_choices methods, as it was suggested
for ModelAdmin.
> On Jul 6, 11:20 pm, Ivan Sagalaev <[EMAIL
Hi Malcolm,
Solution #4:
make this choice an optional second argument of include(), but not patterns().
patterns are overloaded, and this approach combines advantages of
solution #1 and solution #2.
Solution #5
add map: root path -> urlconf
On Sun, Jul 6, 2008 at 8:51 AM, Malcolm Tredinnick
<[E
To add to the case, redefining fields in ModelForm can introduce
serious problems and do more than just compromise DRY.
E.g. if you have a model field that's optional (blank=True), you need
not to forget to add 'required=False' to your form field re-
declaration...
As for dynamic choices, I think
Hi Ivan,
1) You missed making a subclass as third option in your initial post
(and preferred one), that's why i suggested it.
2) "Sure everyone can subclass anything or patch Django installation"
is not much realistic statement: for some things, it's much easier
than for other ;)
3) Why I think y
Malcolm Tredinnick wrote:
> No, SCRIPT_NAME would be more or less /site_prefix/ in the first case
> and /admin/ in the second case.
Ok, got your point. I now understand why you wanted SITE_PREFIX as a
parameter for patterns().
> But we do have to be consistent. PATH_INFO does not include any
>
Yuri Baburov wrote:
> And before it's landed into the trunk (i hope it will ;) ) you can
> make your own subclass of ModelForm which does exactly what you
> proposed, and then subclass it everywhere ;)
Yuri, it's a bit redundant note :-). Sure everyone can subclass anything
or patch Django insta
Hi Ivan,
Yes, together with dynamic choices will perform great (on init,
developers might assign some options to widgets...).
And before it's landed into the trunk (i hope it will ;) ) you can
make your own subclass of ModelForm which does exactly what you
proposed, and then subclass it everywher
> ## Proposal
>
> To fix this I was thinking along the lines of:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
> 'text': Textarea(...),
> }
>
> Sound s
Hi Alex,
Check out this: http://www.djangosnippets.org/snippets/414/
and this: http://www.djangosnippets.org/snippets/323/
On Sun, Jul 6, 2008 at 12:47 PM, Alex Rades <[EMAIL PROTECTED]> wrote:
> You mean this?
>
> http://code.djangoproject.com/wiki/NewformsHOWTO#Q:HowdoIchangetheattributesforaw
Steve Holden wrote:
> What's CSS for?
For styling. Choosing widgets has nothing to do with styling. My cols
and rows for textarea is just an example that, incidently, can be
emulated with CSS. But often you want to use a different widget
altogether, say, a set of radio buttons instead of defau
On Sun, 2008-07-06 at 16:21 +0400, Ivan Sagalaev wrote:
> Malcolm Tredinnick wrote:
> >
> >PythonHandler django.core.handlers.modpython
> >SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> >...
> >
> >
> >
> >Python
Malcolm Tredinnick wrote:
>
>PythonHandler django.core.handlers.modpython
>SetEnv DJANGO_SETTINGS_MODULE mysite.settings
>...
>
>
>
>PythonHandler django.core.handlers.modpython
>SetEnv DJANGO_SETTINGS_
On Thu, 2008-07-03 at 15:38 +0200, Christian Tanzer wrote:
>
> Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2008-07-03 at 14:56 +0200, Christian Tanzer wrote:
> > [...]
> > > I'd propose to write that check as
> > >
> > > parents = [b for b in bases if isinstance(b, Model
Ivan Sagalaev wrote:
> Hi, everyone!
>
> I was recently refactoring some old code to use a ModelForm and was
> stuck at an issue that we don't have a simple way to say "this form has
> these fields from a model but with other widgets".
>
> For example I have an Article model that I want to edi
Hello all,
Midterm evaluation is soon approaching and here is my last update
before it.
Here is what I have been able to accomplish so far:
* Threaded-comment support without too much of modification to Jacob's
initial code
* Transition to newforms-admin
* Demos and ability to have custom commen
Hi, everyone!
I was recently refactoring some old code to use a ModelForm and was
stuck at an issue that we don't have a simple way to say "this form has
these fields from a model but with other widgets".
For example I have an Article model that I want to edit in a form:
class ArticleFor
MONTHLY EARNING $1000 TO$1
SIMPLE ONLINE SURVEY
CREATE YOUR MEMBERSHIP
OTHER DETAIL VISIT
**
HTTP:/.AWSURVEYS.COM/HOMEMAIN.CFM?
REF ID= SIVA ICICI
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
29 matches
Mail list logo
