, value, attrs, choices)
I think it would be also useful for CheckboxSelectMultiple widget and
multiwidgets. What do you think?
Regards,
Max
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develop
A small correction.
>
> {{ form.choice.1 }}
> [some markup with fields]
> {{ form.choice.2 }}
> etc...
{{ form.choice.0 }}
{{ form.choice.1 }}
of course, 0-based indexes.
Regards,
Max
--~--~-~--~~~---~--~~
You received this message
at up with new versions each
quarter, if not each month...
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
emaining instance
of maxlength rather than max_length... It's still convenient to rope
together all warnings rather than have them printing at odd times during
debugging.
It would be nice to easily validate non-installed models, but I don't
think that's a compelling use case in eith
On Jan 21, 4:25 pm, "Matthew Flanagan" <[EMAIL PROTECTED]> wrote:
> ADMIN_FIND_ADMIN_CLASSES = True
> ADMIN_MODELS = (
> 'myproj.myapp.admin.PollAdmin',
> 'someotherproj.someapp.admin.FooAdmin',
> )
My 2 (belated) cents on the issue: the settings.py idea is the best
I've seen in the threa
I was thinking that another option would be to decouple the
INSTALLED_APPS setting from the data store to allow for future changes
(such as a better place to store app-specific settings than the global
namespace as CAPS_NAMES in the settings file), similar to the
patterns() and include() functions
> There are some things that we do though, that I don't see in Django. The
> biggest is our logging system, which I really like. In Django I've
> just seen logging in the admin page with the 'History'. Our setup is that
> we have a class LogEntry (actually action_log but i would change it now)
101 - 107 of 107 matches
Mail list logo
