e done)
-> should use the language of the request or some other default language
without the need to tell it so
(sites usually only display one translation at a time, of course
there needs so exist some way to get all translations)
Greetings, David Danier
--~--~-~--~~~
akes adding new attributes more easy.
Using the Meta-subclass allows future ModelTranslation's to add/override
fields to/of the original model and keeps this in sync with normal
models (ModelTranslation could be a subclass of models.Model, using its
own metaclass).
Gre
eanField(default=False)
>>> class Meta:
>>> fields = ('foo',)
This way the translation system stays very extendable and may be used
for some version-tracking-scenario while not supporting this itself.
btw.: This is another reason why I want to always use
of sounds nice, but perhaps some sort of django namespace
could be introduced. Meaning $jQD -> dj.$:
var dj = {};
dj.$ = dj.jQuery = jQuery.noConflict(true);
Greetings, David Danier
--
You received this message because you are subscribed to the Google Groups
"Django developers&qu
g this into serve() always means a
request to your local webserver which may lead to a HTTP-redirect (so we
have two requests).
Of course having a template tags means {{ MEDIA_URL }}path/to/file must
be replaced everywhere in your templates. But I think it's worth the
benefit.
Greetings, David
uld create better tools for doing such things inside Django instead
of trying to provide a solution to solve everything.
I hope I haven't missed something essential. Model translations really
touches most of the parts of Django (urls.py, QuerySet, views and of
course models). I intentionally
min) is not as usable as it could be. And even better, it would
simplify managing the auth-system as a whole (only small apps, that
implement, provide or use some API).
Greetings, David Danier
P.S.: Sorry about the missing "In-Reply-To"-Header, I just joined this list.
--~--~-
ormal Django-way
(Admin-subclass...).
But it's nice to see separation the admin from the auth-app is on its
way already.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django deve
easy. But I think allowing the user to explicit use UPDATE or
INSERT would be a nice feature.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to th
ependent of
save() and can be called directly (if you know what you do). Anyhow
there needs to be some logic inside save(), of course.
I'm not familiar with the current implementation of save(), so I don't
know how complex it would be to accomplish this, but it sounds easy
ackends-system obsolete (sorry), but keeps
its flexibility while making things simpler for application-developers.
For the permissions-system I would do similar.
(One configuration-directive, some API thats fixed but allows model- and
row-level-permissions)
If you are interested I could try to contri
follow your coding-style here, but I'm willing to change
that if I get some positive response on this.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&qu
> I found this query that isn't quoted correctly (I trimmed out some
> stuff to make this shorter):
AFAIK the queries are logged without quoting but executed correctly.
(You can see this, if you have a SQL-error and the DB-backends throws an
exception with the real query)
Greet
s there a real advantage over using this?
(except for looking nicer)
8<-
from django.db.models.loading import get_model
[...]
models.ForeignKey(get_model('account', 'User'))
->8
Greetings, David Danier
--
nt. But I haven't seen this so far, nor searched for
it. ;-)
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dj
any interface.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from thi
_ than a binary
representation."
Besides the other methods provide some optimization:
"Protocol version 2 was introduced in Python 2.3. It provides much _more
efficient_ pickling of new-style classes."
Just my 2 cents,
David Danier
--~--~-~--~~~--
nk this should stay default.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsub
st_comment', name="%(load_func)s.post_comment"),
)
-------->8---
Perhaps this case is to specific to be added to a {% url %} refactoring,
but if it can be done on the way it should be considered. Would really
improve what you
well (for initial data). Currently I had to replace LazyDate with
datetime.now(), which is not lazy anymore (datetime.now as used for
models would be lazy). Perhaps this can be changed, too?
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message be
> Just use datetime.now without the function call parentheses.
Know this, doesn't work for newforms (initial value).
I added a ticket (including a patch) to fix this:
http://code.djangoproject.com/ticket/4018
David
--~--~-~--~~~---~--~~
You received this message
rms don't need to do so)?
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscr
the patches:
http://dpaste.com/hold/9043/
svk patch help:
http://dpaste.com/hold/9044/
svk Homepage:
http://svk.bestpractical.com/
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&quo
y default, instead this can go into a different application).
But the code seems mature and working, only some details are missing, if
the current auth-solution should be kept.
(Changing this might be better for post-1.0...but adding this now and
changing it later may be worse than changing it no
(_clean_FIELD/clean__FIELD)?
validate_FIELD sounds right, too.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-devel
replaced by cleaned_data")
clean_data = property(_clean_data_error)
[...]
Classes extending this can override clean_data with some method
validating a data-field, users get some nice message, full_clean()
writes to cleaned_data and this can be removed in the realese after the
next one.
Greetin
Hi,
sorry, if this was said before, I haven't read the latest user discussions.
I'm in favor of enhancing the auth app step by step, as everything else
seems unlikely (haven't happend for a long time, why should it now).
What I dislike about the current auth app in general is that it solves
diffe
Hi list,
as I use "exclude" most of the times (to hide sensible fields from the
user) I don't like the idea of this beeing removed. Perhaps another
solution might be to force developers to either define fields _or_
exclude, so you have to at least think about this..without going through
too much t
I'm with Tom here, this just feels wrong. The whole point of urls.py is
to have a clean mapping of URLs to views.
Of course I understand your problem, so let's look at the details.
> // # front page for country
> // / # list of schools and companies with activities
> in that industry, in that co
> David: The slugs wouldn't be overlapping if they inherited from some
> sort of "Organization" model with unique slug. The user could also add
> validation code to prevent company and schools having same slugs.
If you have a common base model this sounds like some polymorphic model
problem, which
> If we're going to do this, could we also look at deprecating the
> 'templatetag' template tag? There are a couple cases a 'verbatim' tag
> wouldn't cover that 'templatetag' wouldn't, but I'm kinda hard-pressed
> to think of when they'd ever come up in reality.
+1 for this. I for one don't even u
> Other tags which currently use the "as" token are: cycle, regroup and
> url. These all introduce a new variable into the current context,
> which does differ slightly from how {% with %} alters a variable in a
> contained scope. So my secondary (perhaps somewhat feeble) argument is
> that this ac
> On the other hand, having one setting file per site where the only difference
> is the site id seems a bit too much overhead.
Why not use something like this:
from global_settings import *
SITE_ID = 235
#This also allows further changes like:
#INSTALLED_APPS = INSTALLED_APPS + (
# 'fooapp
I currently handle this issue in a much easier way:
I've created an app which allows creating a context for Javascript (this
basically works like the template context processors do, calling defined
functions and combining its results into a dict). The resulting context
will be available in the temp
Hi,
ich recently found myself fighting with FormWizard, again. I think its a
known fact that the integrated wizard lacks features and needs to be
refactored, but this time I struggled using one of the third-party
implementations out in the wild
(http://github.com/stephrdev/django-formwizard). The
Hi Jannis,
>> So, what do you think. Should we try to move forward to a ViewWizard?
> *jumps in time machine*
> Done! See [1] for the work Stephan and me did a few months ago.
This really is nice, I like seeing the old FormWizard becoming more
flexible and reusable. But not what I intended.
The
Hi Jannis,
> I think your intent is the same we had with refactoring the wizard --
> allowing access to the view state inside the wizard steps.
Not only. I also tried to allow steps (=views) to completely move away
from the current form based approach. This means each step can decide
what to to o
Hi Jannis,
>> So, what do you think. Should we try to move forward to a ViewWizard?
> *jumps in time machine*
> Done! See [1] for the work Stephan and me did a few months ago.
This really is nice, I like seeing the old FormWizard becoming more
flexible and reusable. But not what I intended.
The
> Description:
> "The login_required decorator is not checking User.is_active, as
> staff_member_required does. If an authenticated user is deactivated
> (via setting is_active to False), the user is still able to browse
> login_required-protected views."
> For probably most people, the expected an
quote, but this is somewhat different)
Greetings, David Danier
P.S.: I did not open a ticket on this, as I think, this needs discussion
and such minor issues should not flood trac.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
4 for details. The second
ticket contains a XML-validator using lxml.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dj
t posted
some code that works here, but it doesn't fit into django in its current
state.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
ree new lines and should not cause any trouble I think.
Of course docs are missing so far.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to th
to mention. ;-)
This doesn't remove the need to catch the DoesNotExist-exception
everywhere. Additionally it does not work when trying to create reusable
applications that need to have access to some profile.
Greetings, David Danier
--~--~-~--~~~---~--~
the whole field clickable, every other field can be made
clickable by configuration, if someone wants. I don't like the idea of
making the whole row clickable.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed
s, too.
So making the whole field () clickable should really be enough, the
row itself (everything inside ) does not need to be clickable by
default.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
s Meta:
# perhaps useful for urls like /foo
unique_together = ('slug', 'category', 'pub_date__year')
Just some ideas I had when reading the original post, don't know if this
would require lots of work. :)
Greetings, David Danier
--~--~-
Hi Ted,
perhaps take a look at ticket #3011
(http://code.djangoproject.com/ticket/3011).
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
ey, it only took me about 2 hours to write this down, after thinking
about a solution for the last weeks). I would like to get some input on
this topic, about what you think model translations could look like.
Marc, I don't know if you have some proposal of your own. P
rently uses this. Foreign
fields by design always need some JOIN related to them, so this will
depend on conditional joins. If this gets implemented perhaps model
inheritance can be rewritten to use foreign fields, as this looks like a
more generic approach.
Did I miss something?
Greetin
en using pluggable-model-i18n in a
productive environment.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-devel
half-cleaned data out of
cleaned_data will get easier).
And of course clean_FIELD() is not documented so far, which was the
reason for changing its name to do_clean_FIELD() in some commit lately.
So I don't see any reason why not to do this again to get things straight.
Greetings, David Danier
orm(new_data)
But I think copy() already allocates memory, so the performance
difference might be small.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
rue, so the var did not include any special chars'
else:
print 'most likely with foreign languages'
If you change the encoding of the request this might be fine, but the
items in the dict returned by copy() should (/MUST?) look the same as
the items in the original.
Or am I
folder if the file does
not exists any more. Perhaps this can even be done in some
post_delete-signal-handler (iterate over all fields, find image-fields,
delete thumbnail-folders).
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message becaus
he settings-module should do the
rest...
Sorry if this is stupid and I miss some bigger picture here. ;-)
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
T
ngs in my code and works
really smooth after using __unicode__. ;-)
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email t
> Well if I have understood what you say, it is exactly what is
> explained here <http://code.djangoproject.com/wiki/
> UnicodeBranch#PortingApplicationsTheQuickChecklist>..
Right, now I feel dump. ;-)
I even read the docs some time ago....
Greeting
e.djangoproject.com/wiki/UnicodeBranch#PortingApplicationsTheQuickChecklist
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dja
t called by it.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from t
environment without having to fear that
they screw the whole thing up easily. In a professional environment this
might help having a nice way to deprecate things.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed
actical.com/
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group,
So
this definitely needs to be put into your own middleware or view (which
does the redirect).
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
/models/fields/__init__.py?rev=5819#L785).
Why is this done? If I read the code right self.upload_to gets stripped
later in FileField.get_filename() and is added in
File.get_directory_name(), again.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this
ople may guess
valid IDs that they should not use (for example if you use
user_profile.some_relation as the queryset).
Perhaps it could be changed to only allow choices in the queryset, but
an option is added to ModelChoiceField to use the default manager?
Greetings
> Would following that with a syncdb then restore the content types for
> the installed apps? I'll have to test that later.
Even if it did the id's might have changed and any generic relations be
broken.
Greetings, David Danier
--~--~-~--~~~
ailable (which might not be the case when not
using django.contrib.auth or not using an auth-system at all) and that
it has a is_authenticated/message_set attribute (which might be ok, as
this could be called "API" you need to reproduce).
Greetings, David Danier
--~--~-~--~~-
said before: It only fixes one
application out of many.
Instead replacing code like LogEntry.objects.log_action(...) with
request.user.logentry_set.create(...) would help, not only in the admin.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received t
to replace
django.contrib.auth gives some nice advantages, even over the current
backends-system.
For example you do not need to sync your db with LDAP when using LDAP as
the backend. A User-model only containing the DN would be enough here.
Greetings, David Danier
--~--~-~--~~--
to add the admin-app only to have a
nice and clean permission-framework?). It looks to me like the
"unreplaceable django.contrib.auth"-problem will be fixed (or worked
around) only in the admin now, without considering adding this
functionality to the entire django-framework.
Greetings, D
ems with naming the new parameter
and difficulties in creating self-explaining possible values ("not
must_create", rather than "must_not_create").
Just my 2 cents, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subsc
is a very common
> word and there are a number of non-database uses for it.
You don't have to stick to this names. I just used them, as I think they
are pretty self-explainig.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because
72 matches
Mail list logo
