> 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,
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
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
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
> 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
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
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,
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
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
> 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 + (
#
> 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
> 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
ly
touches most of the parts of Django (urls.py, QuerySet, views and of
course models). I intentionally have left out some aspects, because they
are not relevant to most users (for example translated content and full
text search (haystack)).
Thanks for reading this far,
David Danier
--
You rece
utting 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 Danier
-
f 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" g
t;>> 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 a JOIN.
Greetings, David Danier
--~--~-~--~~---
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).
Greetings, David Danier
r 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
--~--~-~--~~~---~--~~
You received this message because you are subscribed
e-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-developers@googlegroups.c
e currently 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
even start implementing this together. I am willing to
spend some time with this topic, because I need some solution flexible
enough (aka "fits my needs") for a client. Additionally I think django
would very much benefit from a official solution on this topic.
Greetings, David Danier
--~
r 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
--~--~-~--~~~---~--~~
You received this message b
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
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 to t
nes 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 this grou
ted
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 to thi
ils. 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 django-de
, 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 the
e 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 you are subscribed to the Google Groups
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
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, David Danier
--~--~-~--~~
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 th
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
--~--~-~--~~~---~--~
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, Dav
/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
finitely 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 group,
al.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, send
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 to the Google Groups
"Dja
et 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 thi
ngoproject.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 djang
> 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
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
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
ely 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 missing something?
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.
ta 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
--~--~-~--~~~---~--~
en 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
an_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-developers
ault, 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 now)
G
ild 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
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 unsubscribe from this g
ed to a {% url %} refactoring,
but if it can be done on the way it should be considered. Would really
improve what you can do with include().
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
is 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 unsubsc
us_ 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
--~--~-~--~~~--
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
ut 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 django-devel
?
(except for looking nicer)
8<-
from django.db.models.loading import get_model
[...]
models.ForeignKey(get_model('account', 'User'))
--------->8
Greetings, David Danier
--~--~-~--~~~---~--~~
You rece
> 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)
Greetings,
ere, 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" group.
To post to this group, s
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 contribute some code, too. ;-)
Greetings, David Danier
--~--~
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.
Greetin
nk 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 this group, se
).
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 developers" group.
To post to this grou
e 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.
--~--~-~--~~--
65 matches
Mail list logo
