if you were using
> appsettings)
> and (c) is provided by appsettings out of the box.
> So it looks like the thing that needs work/thought/design decisions would be
> (a). Could you give an example use case of that sort of "project
> installation setting"?
>
> Jared
>
Sorry Carl, I agree with pretty much everything you said. I was
talking a bit too abstract and I had misunderstood.
I will concentrate on a few use cases:
with a app level settings.py file i didnt really refer to automatic
import, as that can easily be done now.
I had more like a admin.register in
> I've never understood the desire for more magical behavior here. My
> apps have a settings.py that imports django.conf.settings and provides
> any necessary defaults for unset settings; the rest of my app imports
> from there. Works great, easy to look and see what settings my app
> consumes and
have been hitting my head trying to come up
with a better way of managing configs. I've worked with quite a lot of
other systems,
and one thing i like about django is how "simple" it "still" is. this
simplicity is a strength,
and having a registry makes things.. complicated.
some wild ideas I hav
On 21 Jan., 17:45, Andy McKay wrote:
> On 2010-01-21, at 9:15 AM, chris.moff...@gmail.com wrote:
>
> > I agree that managing settings gets to be a bit difficult in many
> > environments - even non Fortune 1000 environments.
Its also an issue for us that write and use portable apps. Luckily a
w
using mysql.
model: only the times are relevant.
class Time(models.Model):
start = models.DateTimeField("zeitbeginn")
end= models.DateTimeField("zeitende",
blank=True,null=True)
user = models.ForeignKey(User)
project= models.ForeignKey(Project,verbose_name=
yes, lets close this thread: and use this one:
http://groups-beta.google.com/group/django-users/browse_thread/thread/6a96426735ffd7f1
On Jan 23, 1:55 pm, nesh <[EMAIL PROTECTED]> wrote:
> * [EMAIL PROTECTED] wrote, On 23.01.2007 13:04:
>
> >> p.s. Let's go to django-i18n, *the* place for I18N dis
thx for the links :)
> > passI'm -1 on this, translation must be done *without* any
> > changes to the model.
the problem with translations is the many different use "cases". and in
many cases, avoiding a change to the model is not posible. for example,
when u have a site with severa
s.pyhttp://dpaste.com/hold/4899/
>
> change_list.htmlhttp://dpaste.com/hold/4900/
>
> the change_list may look a bit weird (due to the whole js-code and
> the additional styles).
>
> patrick
>
> Am 22.01.2007 um 20:28 schrieb stuff4ash:
>
>
>
> > looks very nice, would also need
looks very nice, would also need something like that in a project i am
working on.
stadtkinowien? :) servus! :D
On Dec 19 2006, 5:09 pm, "va:patrick.kranzlmueller"
<[EMAIL PROTECTED]> wrote:
> we´ve integrated the capability of moving items in the admin change-
> list acc. to a field called "p
after searching and reading all the posts related to internalization
and multilanguange, my first question is if there is any active
development to integrate or make easy translations in the django core,
and if not, if there are any people who would be interested in a joint
effort.
in my experien
11 matches
Mail list logo
