Re: About multilingual models
Hi Marc, hi list, First to get my email into context, I wrote a similar email some time ago, which does list some more options on how to do model translations and offers some kind of hybrid data model as a solution: http://groups.google.com/group/django-developers/browse_thread/thread/ca5987ea80120c63/cfffc43b9ec29738?#cfffc43b9ec29738 > Basically, I arrived to the conclusion that there are two different > approaches, both valid, and everyone more suitable depending on the > website. Let me name these methods "model based" and "gettext like". I like to dismiss the gettext-like approach, as it causes to much trouble. Starting with not being usable inside QuerySet's it may not give django users what they need and want when talking about model translations. A big problem I currently see is that changes to the original text may result in a lost translation as long as you only save the msgid<->msgstr-relation inside the database (as the msgid "changes"). So you would need to include hints like the model, it's pk and fieldname (as you suggest, too), but this makes the approach kind of hacky. What I think makes using a gettext like approach impossible is the need to translate fields you use to _find_ a row in the database. A slug might be needed to be translated for example. So you should be able to query by a slug, depending on your current language setting. A gettext like approach will probably definitely fail here. > model based method > - > > This method is specially interesting in websites where all translations > are provided at the same time. [...] > In this case the admin should allow filling all translations at the same > time, and if a field is required, it should be required for all languages. I don't think this is what makes a model based approach interesting. It's the "searchability". How you present your underlying data structure (database or gettext) to the user/admin should not be coupled to the data structure. You could make translations optional in both cases, with the limitation to force the user/admin to create at least one translation when using a model based approach (even this might not be needed for data-driven models). > In this case I would specify this syntax to let Django know that we want > this field translated: > class MyModel(models.Model): > my_i18n_field = models.CharField(max_length=32, translate=True) > Main advantage of this method is that we have the translate property > together with the field definition. This makes easy to know if a field > will be translated or not after coding the models. I still don't like putting the info about the translated fields inside the model. Why not use the registry based approach you used for your gettext like idea? As you can create dynamic models in django and by this can create the additional table. django-pluggable-model-i18n uses this, it seems to work. > From the database point of view I would create an extra table for every > model, with next structure: > * id > * main_table_id > * language_code > * field1 > * field2 > * ... > So, to get data would be necessary to join both tables filtering by > current language code. That would make easy to filter, sort or search by > any of the translated fields. Whats the big problem here, from a usability perspective, is the way you need to search the translated fields. Thinking about where the field is saved (model or translation), needing to join by yourself and still don't be able to fetch the translation itself with the model doesn't seem to be a real solution. Example: Book.objects.get(translation__language='en', translation__field='...') -> just fetches the book, without the translation (fetching the book will cause an additional query, for every book) -> needing to decide where your field lives may cause errors (and will make adding translated field more complex) -> you will always need to specify the language, this may cause errors, too Thats why I suggested a more easy usage in my original email: Book.objects.get(field='...') -> should know that "field" is translated and use the translation table -> should join the translation and select the translated fields (see original email about how this join needs to be 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 --~--~-~--~~~---~--~~ 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 email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: I need a pony: Model translations (aka "my proposal")
Hi Veena,
first sorry for my late answer, I missed your email somehow.
The SomeObjTranslation-model is what should be dynamically created by
some registry. This registry is a little more difficult than your
suggestion, but should keep things simple enough:
-
class SomeObjTranslation(translation.ModelTranslation):
class Meta:
fields = ('some_field',)
translation.register(SomeObj, SomeObjTranslation)
-
Putting this into it's own class makes 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).
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 email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: I need a pony: Model translations (aka "my proposal")
st translation as "is_base=True".
Anyway I'm not sure if this deserves to much attention. When writing my
proposal the idea was to implement translation.ModelTranslation (see
idea.txt) as a derivate of models.Model (This is one of the reason I
used a Meta subclass). When doing so the translation could itself add
fields that are not included in the original model (or perhaps even
overwrite some attributes in the original model?):
>>> class SomeObj(models.Model):
>>> foo = models.CharField(...)
>>> bar = models.CharField(...)
>>>
>>> class SomeObjTranslation(translation.ModelTranslation):
>>> is_base = models.BooleanField(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 a JOIN.
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 email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: admin javacripts
>
>
> var $jQD = jQuery.noConflict();
>
>
> And somebody else includes this:
>
>
>
> Then Django's version of jQuery would be available to all widgets as
> $jQD and the other jQuery version would still be available as $ or
> jQuery.
This kind 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" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Pass Thru Image Proxy Patch Interest?
> Yes, I was thinking the other day that it would be a cool solution for
> serve() to be able to use storage backends
Wouldn't it be better to have some {% serve path/to/file %} template
tags, that does all the work of checking where the file exists and
returning the right URL? Putting 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
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Model translation
your model it will rewrite
calls to filter/order_by() to use the right field:
filter(name='...') -> filter(name_xx='...')
filter(name__contains='...') -> filter(name_xx__contains='...')
order_by('name') -> order_by('name_xx')
...models.Q-filters do not work of course
These apps are as simple as I could implement them, but they both helped
me a lot more than any other full blown solution. This is why I think we
should 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 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 received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Creating an independent auth/permission-framework, separate the models (Was: Adding support for replacing the auth User model to fit custom needs)
I'll pick this topic up for some changes I think Django needs. Please read the summary between the "="-line, if you don't have the time to read the whole mail. Perhaps it will get you interested in reading the rest. ;-) As far as I can see there are different approaches to improve this (which have been posted in this discussion already): * http://code.djangoproject.com/ticket/3011 Split auth-Module into two parts: Authentication and User-Model -> AUTH_USER_MODULE defines which User-Model to use * Auth-Backends, in the current SVN -> The User-Model still is in your Database I think the best way in solving this is to combine this two: * The User-Model gets its own application, including: - models.py - backends.py - special views or perhaps all of them (didn't read the whole code, includes forms.py) - create_superuser.py * The auth-Module morphs into a authentication-framework, that can use the User-Model, but is not bound to it (other model can be used by changing AUTHENTICATION_BACKENDS), includes: - __init__.py - middleware.py The only difference I see, is that you need to include some "django.contrib.user"-application, if this two parts are separated in a clean way. Big advantage would be, that the admin stays usable if you change the User-Model, as it only needs to use the authorization-framework. Additionally I would merge this idea with the django-branches that try to improve permission-tests (generic-auth, per-object-permissions). More precisely it would make sense to create some permission-framework es well. I think the Ideas behind the generic-auth-branch (http://code.djangoproject.com/wiki/GenericAuthorization) are pretty nice, I like to have one function I pass an object, an user and some permission and get an result. Some additional thoughts: * To recreate the current behavior you could use the Model itself passed as the object (Article(=class) instead of article(=instance)) * I dislike the idea to be forced to register some permission-test. As the Article says it should be put into the Meta/Admin- or perhaps Permission-subclass of a Model, which would be fine or even a MUST HAVE. If some permission-framework is created I would prefer to separate the Permission-Model from the auth-Application (or User-Model/user-application). It would be nice to create two default-systems for permissions as separate applications: * Model-Permissions like used now * Row-Level-Permissions like proposed The permission-framework should be able to use this two systems concurrently. Each model (or application (as a default)) should be able to choose which permission-system to use (or even use more than one). Perhaps separation the permission-framework from the auth-framework would be even nicer (you can use the auth-system, but use your own permissions-system). Also I don't like putting some permission-system into the models(.py). This should only be used to define your models and not for some kind of permission-checks = To summarize: I think the User/Group/Permission-Model should be separated from the auth-framework. You should be able to choose other models using the backends-config or similar. Also there should be created some generic permission-framework, close to generic-auth. This framework should not rely on any model. Two default-implementations should be created (model and row-level). = I think splitting the auth-application into multiple parts and creating some basic frameworks that can be used to do such tasks is really important. Without this the auth-framework will get bigger (just imagine the generic-auth-merge), but instead of getting more flexible it will only solve more specific problems. And if the admin (or any other application that needs authentication) should be usable, even if someone is not able to use the provided authentication-system and implements his own, there needs to be some basic framework without any drawbacks (auth-backends are there, but they pull the whole User/Group/Permission-Models with it). I would like to contribute creating this, if someone is interested. Perhaps the best place to start (or even work if Joseph Kocherhans likes my plans?) is the generic-auth-branch. I believe such a system should be ready with Django 1.0. Otherwise the whole auth-System (and with it the admin) 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop
Re: Creating an independent auth/permission-framework, separate the models (Was: Adding support for replacing the auth User model to fit custom needs)
> I'm much more of the opinion nowadays that Django doesn't necessarily > need an overreaching and generic authentication/authorization > framework. Yes and no. On the one hand it is not needed, besides for the admin (which gets separated somehow, as you said later in your email). On the other hand it would be nice to have such a system for better modularity. I'm thinking of different applications needing some authentication-system. This can be easily done using the current auth-framework if it fits. But as this is not always the case you will end up in having different systems in every application (in the worst case, think of third-party-applications). So you can combine different applications in Django, but may have problems when it comes to user authorization. If instead every application uses some generic calls to get the user-data, manage the session (here this is done already) and handle permissions this gets simple. The application does not need to know which model is behind the user, it can count on get_absolute_url() and __str__() to use it most of the time. This is already done with the AUTHENTICATION_BACKENDS, but has the drawback of forcing the user to include the Django-User-models. So I would at least separate these two (auth-api and user-model). As an enhancement it would be nice to get the generic-auth-branch into the trunk (slightly changed perhaps). So not only authorization can be done on an abstract way, but permission-checks, too. I think Django would benefit from this in the long term (third-party applications get more usable). As the modules are not that big, fairly simple and should be easy to separate (this is somehow already done in the auth-app, while keeping it together in one app) I don't see any reason to not do this. (Besides backwards-compability, but http://www.djangoproject.com/documentation/api_stability/ states, that the auth-framework will be changed anyway) > The newforms-admin branch [1] is moving towards getting rid > of the admin system's dependency on django.contrib.auth for > authorization, and I'm hoping we can eventually get there for > authentication as well. I haven't thought much about exactly *how* to > do so yet. A generic API for authorization would be simple and easy to implement. The users can be changed in the admin using the normal 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 developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model.add() ?
> I should be able to do it with just one > hit at the database. Second (and subsequent) hit(s) should occur only > in the case of an insert exception (AssertionFailed). But the way > Django doesn't differentiate b/w INSERTs and UPDATEs, I have to > manually check for collisions and hit the database TWO TIMES for every > new entry (that's silly). I see his point here. The code would use less Queries if written this way: --- if not this.id: while True: try: this.id = uuid_stuff() # throws exception if id exists, as this field is unique return this._insert() except: pass else: return this._update() --- Perhaps save() could be change to actually do this: (As I started writing my own DB-abstraction-layer once, I know this can become very handy) --- def save(self): # simplified if self.id: self._update() else: self._insert() --- > I wanted to use UUID as primary key in my models. Since Model doesn't > have any add() method, I have to do it like this: I would recommend using a different field for the uuid: --- class MyModel(models.Model): uuid = models.CharField(maxlength=X, unique=True) def save(self): if not this.uuid: while True: try: this.uuid = uuid_stuff() return super(MyModel, self).save() except: pass else: return super(MyModel, self).save() --- > Adding a new entry > and updating an existing one are _different_ operations and the should > not be *automagically* fused together. Even underlying SQL is > separate! Here you are wrong. It really should be fused, as this makes things really 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 this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model.add() ?
> If you abandon the record check when pk_set, then you lose the ability > to manually specify an ID for use in insert. Thats why the comment above says "simplified", perhaps it was oversimplified...: --- def save(self): # not so simplified, but still very simple if pk_set: if record_exists(): self._update() else: self._insert() else: self._insert() --- The goal is to have UPDATE- and INSERT-Methods that are independent 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. 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Creating an independent auth/permission-framework, separate the models (Was: Adding support for replacing the auth User model to fit custom needs)
auth.get_authentication_model().objects.login(request, u) ->8-- Multiple backends (foo/user/models.py): --8<- class UserManager(models.Manager): pass # like above class User(models.Model): objects = UserManager() user_id = models.IntergerField(...) user_backend = models.XxxField(...) def _get_backend(): return load_backend(self.user_backend) def _get_user(): return self._get_backend.get(pk=self.user_id) user = property(_get_user) ->8-- As you see, this makes the backends-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 contribute some code, 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Reworking the authentication and user-system (Was: Creating an independent auth/permission-framework, separate the models)
Sorry, I didn't change the subject on the last email, should have been
this one then. If you don't know what I am talking about, please read
the last email.
(http://groups.google.com/group/django-developers/msg/50f9393fa15251b3?hl=en)
I have starting rewriting the auth-system now (""), code can be viewed
at https://svn.webmasterpro.de/django-auth-rewrite/. This branch moves
django.contrib.auth to django.contrib.oldauth and creates
django.contrib.auth which includes oldauth. django.contrib.newauth is
added with my code, but not used by default so far.
I tried to use the old function-names where possible, as you can see in
https://svn.webmasterpro.de/django-auth-rewrite/django/contrib/newauth/__init__.py.
I added some new functions:
* get_user_model: retrieve the model for foreign keys
* foo_redirect: redirect to the login-page (no configuration needed
this way)
* get_anonymous_user: get the anonymous user, which can be saved into
the database this way (so anonymous comments can include a user_id and
permissions can be set for guests)
* is_authenticated: test if a user is authenticated
* has_model_permission: test if a user may access a model (like done in
the old system)
* has_object_permission: test if a user may access an onject (like done
in generic-auth)
Most of the functions are only wrappers for functions used in some
auth-system later. The modules which are used can be set using
settings.AUTHENTICATION_MODULE and settings.AUTHORIZATION_MODULE (which
is not in the default-config as no implementation exists in this branch).
has_xxx_permissions can do anything they want. No database access is
required, but Django may ship some row-level-permission-system to set
using AUTHORIZATION_MODULE.
context_processors are included, but don't do much right now
(https://svn.webmasterpro.de/django-auth-rewrite/django/contrib/newauth/context_processors.py).
The middleware is a copy of the old middleware so far, but changes the
import-statement
(https://svn.webmasterpro.de/django-auth-rewrite/django/contrib/newauth/middleware.py).
I included some decorators here, that can be used, see __doc__-strings
for details
(https://svn.webmasterpro.de/django-auth-rewrite/django/contrib/newauth/decorators.py).
The models-file only loads the user-model into the local var "User" to
get imports fixed
(https://svn.webmasterpro.de/django-auth-rewrite/django/contrib/newauth/models.py).
Currently there exists no implementation of a user-system or
authorization-checks, besided in my project (I implemented this for a
CMS I'm writing). So the code in newauth is not able to do something
fancy, but should clarify what I ment in the last email. The models from
oldauth should be easy to convert (but I would skip the backends and put
this into a different application), but I don't have enough time today.
Of course the admin is not working, too.
Hope to whet your appetite and get some comments this time.
I know I don't 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" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Possible bug: How does Django decide when to quote SQL arguments?
> 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, 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket 3688 -- Improve support for mutually-referential models
> This patch allows dotted notation ('app_name.model_name')... the same as
> used by Django's "get_model". So, for example:
> models.ForeignKey('accounts.User')
I don't see the real advantage over:
8<-
from foo.accounts.models import User
[...]
models.ForeignKey(User)
->8
Am I right, that this helps when you don't know (or don't want to) where
the application is stored or the application might be exchangeable?
Example:
Application1: foo.accounts
Application1: bar.accounts
Both have a similar API, you may decide which one to use.
-> You want to use "accounts.User" without knowing which application
(under foo or bar) is used in INSTALLED_APPS?
I like this idea, but is 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
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: newsessions
SmileyChris wrote: > Anton Khalikov opened a new ticket pointing out a hole in the current > session framework which can cause session id collisions. Could be easily fixed with providing Model._update() and Model._insert() as proposed here: http://groups.google.com/group/django-developers/browse_thread/thread/6ddfb7da8319c6df/c2d3671b6a6fec5f abstract example code: http://groups.google.com/group/django-developers/browse_thread/thread/6ddfb7da8319c6df/c2d3671b6a6fec5f#msg_56de2a0ef2b884cc (First code block, additional to having less queries this would prevent race conditions) SessionManager could then calculate a session and try to save an object with this session-key (allowing only INSERT, not UPDATE). If the key exists the DB-backend will raise an Exception as the key is unique (primary_key). If it is free, the INSERT will ensure that no other session may use the key. If I get this right the newsession-patch is trying to do so, but will fail, beuase s.save() (django/contrib/newsessions/models.py, line 29) will overwrite (SQL UPDATE) existing sessions instead of failing creating it. One tiny advantage remains: There is less code (=time) between calculation the session key and saving it, so less chances to get a race condition. But I don't see a real fix there. Simon G. wrote: > One thing that I would like to suggest is that we do link the SID to a > user-agent [...] I heard about some proxies or anonymizer services that actually do change the user agent. 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 django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
> Because doing so would introduce some backward incompatibilities. Thats not true, if you provide a save()-method that calls either update() or insert(). save() should not be removed, it makes many things very easy. So only additional flexibility is added without removing or changing 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Support for a binary storage field?
I think a BinaryField could even help getting less data saved into the database, as some binary data fits well into the database, but must be saved as ASCII now (converted or by using a different format). For example the full-history-branch uses pickle (cPickle) to serialize the data of an object. pickle known multiple methods to store the data. By default is creates a ASCII-dump, but you can change this behavior. >From the docs (http://docs.python.org/lib/node316.html): "By default, the pickle data format uses a printable ASCII representation. This is slightly _more voluminous_ 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 --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms: colon after label
Perhaps the user-mailinglist is a better place for this, but anyway...
> I don't think the library should add text like that, what do you
> think?
I really think it should. The methods defined in the form are some
default, that can be used if appropriate. If not newforms is usable in
any way you want. You can use all the flexibility Python and newforms
provides here:
I use this (colon-free) code for form-display:
(put into a separate file that is included in the templates)
---8<
{% for field in form %}
{{ field.label|escape }} {{ field }}
{% if field.errors %}{{ field.errors|join:",
"|escape }}{% endif %}
{% endfor %}
>8---
( includes field to get it working in the IE, for
linebreaks, that even work in text-browsers and because normal lines
cannot be styled using CSS)
You could even write your own Form-class (extending newforms.Form), that
outputs other things (e.g. by just adding an as_my_style()-method and
using this as default). If you really want to change many thing you can
create your own forms-module (importing newforms.* and overwriting
things you need to change). I use this way to have an drop-in
replacement for the forms without forking the main-code. I changed the
date-fields to accept german notation for example. The big advantage
here is that forms.DateField can be used, so nothing needs to be changed
(except for the input-statement).
Perhaps the colon can be moved into the display-methods (as_p, as_ul,
...) or an parameter/attribute could be added to the form, but as most
people use forms with colons and newforms provides anything you need to
display something different I think 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: {% url %} for generic views (proposal)
> I've done some thinking on this, too, and I think the cleanest way to
> solve it would be to introduce optional names for URL patterns.
Sounds really nice. And it doesn't even enforce to break the {% url %} tag:
{% url some.view ... %} -> view lookup
{% url "some name" ... %} -> name lookup
But my current problem with reverse URLs is not generic views. I'm using
include() to put comments and full-history under the url of the object
(/article/foo/ -> /article/foo/comments/ or /article/foo/history/). As
these views are used for multiple objects (articles, news, ...) the
reverse lookup is not possible. Could be solved easily by having the
parameters used for the include() available when resolving the url (I
pass an argument that tells the views how to load the object). Even
nicer would be to be able to put this argument into the name.
Example:
article-patterns:
---8<
urlpatterns = patterns('foo.article.views',
(r'^$', 'index'),
# [...]
(r'^(?P[a-z0-9-]+)/comments/', include('foo.comment.urls'),
{'load_func': 'foo.article.views.get_article'}),
)
# load_func is passed the args/kwargs got from the resolver (slug here)
>8---
comment-patterns:
---8<
urlpatterns = patterns('foo.comment.views',
(r'^$', 'view_comments'),
(r'^post$', 'post_comment'),
)
>8---
Now, something like this would be nice (a additional parameter should
look cleaner, but this shows what I mean I think):
---8<
urlpatterns = patterns('foo.comment.views',
url(r'^$', 'view_comments', name="%(load_func)s.view_comments"),
url(r'^post$', 'post_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 can do with include().
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
LazyDate removal (changeset 4985)
LadyDate was removed in changeset 4985 (http://code.djangoproject.com/changeset/4985). This is great, as the funciotnality here is not really needed and the new handling using a callable object is much simpler. What I'm missing now is the possibility to use callbacks in (new)forms as 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 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: LazyDate removal (changeset 4985)
> 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 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #3297 (reopened) - FileField / ImageField - newforms
> Anyone know the status on ticket #3297? It says "Ready for checkin", > but hasn't been touched in the last three weeks. Perhaps the status should be "Design decision needed" instead, as there are two different implementations in the ticket. (At least I think that's what keeps the patch from being applied) So the question is: Two input-field for file uploads, one field only to do validation (which clashes with normal web-security-rules) OR One input field, but self-written forms need to set required to False themself (automatic generated model-forms 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Maintaining a patched Django (was re: Templates: short comments {##} eats text)
> What tools do you use to manage your patched version? I use svk for getting my patches updated and regenerated if changes happened to the trunk and some lame gentoo-ebuild to install django including my patches. I pasted my ebuild here: http://dpaste.com/hold/9042/ Some script to rebuild 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 "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Merge some branches in before 1.0?
> There are a number which look so close (Oracle, FullHistory, > GenericAuth), [...] I started to read the code of FullHistory and GenericAuth, because I needed this for my own project some time ago. So I try to comment on these two. Perhaps I can help finishing both, as I implemented this functionality myself after reading the code and concluding that both are not ready. FullHistory: Has some nice ideas, but seems very unfinished (there is even debug-output inside the code...print-statements). Additionally I think it has some real issues, that need to be addressed before merging. In detail: * Signal-handlers use pre-events, but save()/delete() might raise an exception * Creating new revisions (model: ChangeLog) using signals misses the option to add an comment (text describing the changes) to the history (model-attribute for this exists) * I had some problems with unicode-strings in my own code, this will happen in this branch again, because I used mainly the same code (unicode + pickle + db: newforms provides unicode-string -> pickle puts this into some normal string as utf-8 -> INSERT fails) * user-Field is unused so far, as the signal does not provide this information (and should not do this)...and saving the IP might be useful, too * Some way to specify options for dumping might be useful (like for the admin)...not all models need to create a history * No views so far (and using the current approach - see urls.py - this will have the same problems with reverse urls I sent to this list some time ago, see http://groups.google.com/group/django-developers/msg/51ef359db17f5e40) * Code is far from being complete For the comment/user-problem some generic function to create a revision can be provided that is called from the (generic-)views. Perhaps forms can add a comments-field if a history is wanted (I extended the newforms to be complete modular, so a simple forms.HistoryField() does this job for me). GenericAuth: I'm not sure if extending the current auth-system is the right way (as stated many times before). Some of the reasons may be in this list again. * Model-backends-approach has the drawback, that every backend must return a standard-django user-model. So data needs to be duplicated and may drift apart. Every backend must mimic the ModelBackend (even with the return value-type)...otherwise many things start to fail (example: models.ForeignKey(User)) * The current system uses some "foo.bar"-string for permissions. This can be avoided using the model-class directly. * No decorators for object-permissions (tricky, but possible...did it using two decorators: fetch_object() and had_object_permission()) * uses oldforms I think the auth-system should be refactored as it is done with the admin (newforms-admin) currently. The GeneriyAuth-branch does a great job here, but tries to keep as much from the old system as possible. I think this should be changed (for example no permission-table should be added by 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 now) 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Changeset [5231] -- do_clean_*() is awkward naming
> What about clean_data -> cleaned_data and maintain clean_*() I would go for this. cleaned_data sounds a lot more more adequate anyway. > The biggest down side is that clean_data is already documented... but > it's an easy find-replace As newforms is not fully documented so far and some parts are missing in 0.96 (see bug 3297 for example) some people (including me) used the source as documentation. So both changes may break things. However clean_data is the official name for it in 0.96 (including the docs). > To me, cleanfield_* and do_clean_* seem overly wordy and, as Malcolm > pointed out, the "clean" metaphor is a good one. Adding something to "clean" (prefix or suffix) just seems wrong (and produces more chars). Perhaps some synonym (http://thesaurus.reference.com/browse/clean) might help? tidy, clear? Or just add an underscore (_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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Changeset [5231] -- do_clean_*() is awkward naming
> For me, an AttributeError from clean_data is a much more friendly
> change than silently ignoring code like:
True, and the AttributeError can even be user-friendly:
class BaseForm(StrAndUnicode):
[...]
_clean_data_error(self):
raise AttributeError("clean_data has been 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.
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: auth.User refactor: reboot
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 differnt things. You either have to take it all or do everything yourself. So perhaps a first step towards a new and shiny auth implementation might be to split things up? What do you think? Currently auth consists of multiple things: * authentication * authorization / permissions * Users * Groups In any case, the current auth system isn't all bad. I like many things and it works well for most cases. The email-login issue may be solves with randomly generated usernames and a authentication backend that matches by email-field instead. This all isn't perfect, but small steps may be enough to get to a nearly perfect solution here. David -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ModelForms and the Rails input handling vulnerability
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 trouble. Minimal form containing all fields would be: class SomeModelForm(forms.ModelForm): class Meta: exclude = [] Everything else would lead to develpers using thinks like mentioned before ([f.name for f in MyModel._meta.fields if f.name not in ...]). I really think this only makes things more ugly. David -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: URL dispatcher fallthrough?
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 country
> /// # list of industries company has activities in, in
> that country
This breaks if an industry with the same pk/slug as a company exists
(/de/foo/ as industry and /de/foo/ as company). You would never be able
to call the company again, as the industry just overlaps. This schema
just is badly designed and not able to handle this case in a sane way.
This is true for router-views, throwing UrlNotMatched or any other way.
You basicaly loose the clean mapping of your URLs. It could even happen,
that you overlap a valid company url by adding a new industry to your
database, moving that URL to a completely new content.
(Sidenote: I think this is a problem even the Django admin has. Just add
an Model with an CharField as primary key and insert "add" into this
field. You will neven be able too edit this in the admin, as the
add_view will be called instead.)
You could of course make sure the URLs never overlap by making the slug
unique. One easy way would be to add a prefix, but then again you could
implement this in your urls.py without any hassle
("//industry-/").
Another solution might be to add a router-view, which is based on
aliases. So you could have a central db-table which stores alias to view
releations (meaning: /de/foo/ -> (industry_view, slug=foo), /de/foo-2/
-> (company_view, slug=foo), stored inside the database). This way you
could avoid overlaying and even create fallback-names for duplicate
slugs. But you need a central storage to accomplish that. (Drupal works
this way.)
Anyway, I don't think throwing UrlNotMatched is the right solution here.
David
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: URL dispatcher fallthrough?
> 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 does not need to be solved in the URLs (and probably should not). There are existing third party solutions, which may help you get the right model back, when fetching one "Organization". An user validation is only useful if you put the logic into an unrelated app, as my proposed alias app. Otherwise you will need to mix your models, at least when doing validation. This may not follow the loose coupling philosophy (https://docs.djangoproject.com/en/dev/misc/design-philosophies/) of Django. If you have this app the name resolution can be done without doing fallbacks anywhere in your code. Anyways, about your proposal: This is somethign that does not need to be inside Django core. So why not just start an thirt party app implementing the proposal? David -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Feature proposal: escape hatch for colliding template syntax in django templates
> 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 use {% templatetag %}, as {{ "{{" }}
is so much easier.
Besides adding some non-rendering-tag I would love to see a
rendering-tag to allow two way rendering for caching/performance
reasons, example:
Usage:
{% render %}{% cache ... %}
this will be cached content: FOOBAR {{ some_var }}
this will not be cached content: {% verbatim %}{{ user }}{% verbatim
%}
{% endcache %}{% endrender %}
I could even provide some code for a {% render %}-tag, as I use
something like this in production.
David
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #7817: Extending "with" and "include" tags.
> 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 actually helps to keep the "as" token's behaviour more
> consistent. :)
Don't forget {% blocktrans %}. Using the foo=bar-syntax here may be
slightly more difficult due to counted arguments.
{% blocktrans count foo as var1 and bar as var2 %}
Could become:
{% blocktrans count var1=foo var2=bar %}
David
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: One Django instance, hundreds of websites
> 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'm using something similar here, but the number of sites I need to run with the same codebase is rather limited (unter 10). Anyways it works well. In addition every site has its own python module here, so changing the settings is just a small step...its even possible to have different urlconfs or templates or ... David -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django urls in JavaScript
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 templates as a normal variable (a context
processor puts it there). Inside my base template I define something
like: "var config = {% json js_context %};". This could be moved into
its own template tags, but I kind of like it this way.
This will store my own, extendable configuration into an project
specific variable (javascript object), which I can easily access
(config.foo.bar). It can be used to store URLs, but may also contain
generic things like MEDIA_URL.
So far it only solves one problem, getting variables into JS in an sane,
structured way...it doesn't solve handling URLs which accept parameters.
URL that don't need parameters are easy to, resolve() does all the work.
Parameters get tricky, but I have come up with an easy and efficient
solution, although it does look kind of strange. I use resolve() to get
a valid URL, but put some placeholder into it, which means:
resolve('my_named_view', kwargs={'slug': '__slug__'})
On the JS-side creating the final url just needs a simple string
replacement. Of course the URL needs to be valid, which means it may not
fit all situations (numeric ids: '(?P[0-9]+|__pk__)'?). Anyways this
works fine for me, while still being extenable enough. In addition it
solves the more generic problem of putting variables into JS, which is
kind of nice I think.
The resulting JS could be cached using normal template caching tags, or
may be moved into its own HTTP request if wanted. The idea of using some
kind of context processors for JS-context is what this email is
about. ;-)
David
--
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 email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
[RFC] Moving from FormWizard to ViewWizard
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 limits a wizard for forms inevitable implies did catch me this time, which means I needed to do more than just iterate over forms (I'll write some more details at the end of this mail). So this got me thinking. We now have shiny new View-classes, some of them to handle forms, but many to do other things. Why not use this to create a new wizard, which just iterates over views (or View-classes) to provide similar functionality like the current FormWizard does. There needs to be - of course - some Mixin to add methods to store/load the saved data into/of some storage, but this would be a thin layer extending the current views. Of course a ViewWizard would outplay the FormWizard, because a FormWizard would just be a ViewWizard containing only Form-Views. So creating a ViewWizard instead of restructuring a new FormWizard would mean creating a nice upgrade path, too (deprecate FormWizard, no need for maintaining backwards compatibility here). I currently have a working prototype, borrowing many things from django-formwizard (method names, storage implementation, ...) and it seems to work fine. This still misses most of the work (docs, test, etc). So, what do you think. Should we try to move forward to a ViewWizard? Greetings, David For the curious, about the shortcomings I ran into: I tried to build a registration process including payment based on the FormWizard. This all worked fine until we needed to add more payment options. Many payment providers (Paypal, Google Checkout, Amazon Whatever) need you to switch to their site for issuing the payment. As a Formizard handles the view-part for you there is no (sane) way to redirect your users to their sites and handle the success-response. A ViewWizard could just send an standard HttpResponseRedirect and do anything else a normal view could do. It'm sure there are many other use cases. -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [RFC] Moving from FormWizard to ViewWizard
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 new WizardView still handles a list of forms to be rendered. What I proposed is completely moving away from the FormWizard...meaning instead of passing a list of forms a ViewWizard should get a list of views. Each view could then a) save/restore its state using some storage api and b) tell the wizard about its state (step is complete) to allow moving to the next step. In code this could look like: class Step1View(FormView): form_class = ... class Step2View(TemplateView): template_name = ... class DoneView(WizardDoneView): # done() method could be moved to an own step, giving it # much more power. This is how my current prototype works. ... wizard_view = ViewWizard.as_view( view_list = ( 'step1': Step1View, 'step2': Step2View, 'done': DoneView, ), ) Using this approach the FormWizard is just a ViewWizard containing of only FormView's. Besides that you could even use a ViewWizard as a step inside a ViewWizard (recursion), but thats probably scary to handle ;-) Anyways the views itself (=steps) would have much more control about what happens and how the data is processes. The Step2View above could - for example - point to the next step if some link gets clicked. Correct me if I'm wrong about the new WizardView. David -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [RFC] Moving from FormWizard to ViewWizard
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 on a view-like-level (render a form, issue an redirect, or just display a simple template). I don't see this is possible with WizardView, as the wizard sure can decide this, but never the step (=form)? The use-case I have in mind is a registration wizard where you probably need to switch to foreign sites (for example paypal payment) and later need to continue the wizard where you left. I decided to implement this using an HttpResponseRedirect inside the payment-step-view. After getting back into the wizard GET-params will tell what happened (if payment succeeded). So there is no form involved here. Besides this having class based views as steps inside the wizard also may create more reusable code. Most of the time registrations-forms will be used again to handle account-changes (e.g. update payment data). Having a class based view here in the first place makes this an no-brainer (you probably need to switch the template). At the same time creating a view-based wizard is not that complicated compared to the form-wizard, there could even be a form-wizard-class which just initializes the view-wizard-class the right way. > That's already possible with the new API since *it is now a view*. So > I don't see a good reason to add another level of abstraction to the wizard > system further moving away from the main use case -- providing the ability > to implement multi-step view rendering. To pick up my example above: I could issue the HttpResponseRedirect inside render_next_step() of WizardView. But if the user comes back this will always be a GET-request, so I have to overwrite get() as the default implementation resets the storage. In addition I need to provide some (useless) form for the payment step, which I will need to fill with dummy data to get it validating. This means fiddling a lot inside the WizardView internals. In addition I want to provide another use case, still regarding handling payment: In our first version we had multiple steps for handling payment. The first one was just used to allow the user to choose the payment method using a simple form. The following steps where forms for each method (credit card, etc), filtered using conditions to just show the right one (so the user always saw two steps). This all worked fine until we decided to merge the whole payment process into one step. Now the step needs to consist of multiple forms, which was very easy to implement using a view where the developer can decide how to handle the request. Actually this step is based on a simple TemplateView, just implementing get()/post(), providing multiple forms to the template. Another thing that got much easier was the ProfileView (step where the user enters his/her personal data). This step initially consisted of four forms, one of these where selected using conditions (if "user is logged in" and "payment is needed"). After having a FormView I could more these four steps to just one view (based on FormView) implementing get_form_class(). I didn't even need to implement the four forms this way, as I could just change form.base_field to remove unneeded fields. There might be other valid use cases. > What is there more to know about how the data is processed in the new > WizardView than the data already provided due its nature as a class-based > view? Having each step implemented as a class-based view itself provides much more data to the step itself (request, args, kwargs, etc -> params you usually don't have inside forms). In addition the view itself handles how the request gets processed (-> dispatch()) so the step itself gets much more power over the whole process. I have put up my (hacky) proof of concept on dpaste: http://dpaste.org/SWhn/ This currenly uses the formwizard storage backend, so this is definately a dependency. In addition it is heavily based on formwizard, so it currenly is not implemented as a View like WizardView. Anyway, I just thought this to be a good and slightly more generic approach, made possible thanks to the new class based views we got in 1.3. If this of to far away from the default use case for django core I will try to move this into a third party app. Currently I think I can reuse much of the code you and Stephan wrote to implement WizardView (for example the storage system), which is nice. David -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [RFC] Moving from FormWizard to ViewWizard
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 new WizardView still handles a list of forms to be rendered. What I proposed is completely moving away from the FormWizard...meaning instead of passing a list of forms a ViewWizard should get a list of views. Each view could then a) save/restore its state using some storage api and b) tell the wizard about its state (step is complete) to allow moving to the next step. In code this could look like: class Step1View(FormView): form_class = ... class Step2View(TemplateView): template_name = ... class DoneView(WizardDoneView): # done() method could be moved to an own step, giving it # much more power. This is how my current prototype works. ... wizard_view = ViewWizard.as_view( view_list = ( 'step1': Step1View, 'step2': Step2View, 'done': DoneView, ), ) Using this approach the FormWizard is just a ViewWizard containing of only FormView's. Besides that you could even use a ViewWizard as a step inside a ViewWizard (recursion), but thats probably scary to handle ;-) Anyways the views itself (=steps) would have much more control about what happens and how the data is processes. The Step2View above could - for example - point to the next step if some link gets clicked. Correct me if I'm wrong about the new WizardView. David -- 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 email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ticket 13125 is waiting for a design decision for 18 months
> 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 and (most likely) wanted
> behavior would be not to let inactive users have access to
> login_required files.
I actually had my problems with this some time ago, too. Meaning I
wanted to disable users via setting is_active=False. Back then I just
though this was stupid.
But a while later I discovered a not so uncommon usecase for the
login_required behavior which may be the reason this still is in design
decision state:
Many websites force their users to activate using email verification.
Many of those also login their users after registration (as an
is_active=False-user). This way the user gets logged in successfuly but
may never login again before going through email verification.
I myself have code which relies on this behavior. So I think just
changing it may break some websites. Anyway I still think this is not
what people expect, so either this needs to be documented ("WARNING:
...") or changed in a backwards compatible way (e.g. add a parameter to
login_required).
David
--
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 email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Unify wraps() and update_wrapper() imports?
Just a short question about coding style and possible shortcuts for django-users. I know this is a very minor issue, but I'm just curious... Currently there are some - I count eight - places where wraps() get imported, they all look something like: --8< try: from functools import wraps except ImportError: from django.utils.functional import wraps # Python 2.3, 2.4 fallback. >8-- After needing to use wraps() myself I wondered why we could not just use "from django.utils.functional import wraps" everywhere inside django. functional.py could do the error-catching and import from functool if possible. --8<--[ functional.py ]- try: from functools import wraps, update_wrapper except ImportError: # Python 2.3, 2.4 fallbacks: def wraps(...): ... def update_wrapper(...): ... >8-- I know, this is a question about coding-style, but I think needing only to import from django (meaning only needing one line instead of four) cleans up your files a little. Additionally importing from django by mistake would not cause to have two different versions of wraps()/update_wrapper() around (as functools might get updated some day). So are there any reasons to keep the current imports as they are? If nobody has strong feelings against this I could provide a simple patch. Perhaps the question can be extended to other imports as well... Btw.: There are already places where normal python modules are wrapped by django. So this would not break current coding-styles I think. (Example: django.utils.http.urlquote, 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 Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: XMLField in nfa
> I'm trying to understand what's wrong with the XMLField in nfa. > The validation in validators.py/RelaxNGCompact is never called, It looks > like unused dead code. This means the validation on XMLFields is > currently not working at all. > Is there anyone with a better understanding of the situation? AFAIK XmlField is currently not supported in nfa. Even more the current solution for XML-validation will be replaced, so that django does not depend on jing any more, see http://code.djangoproject.com/ticket/5620 and http://code.djangoproject.com/ticket/3094 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 django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: XMLField in nfa
> Shouldn't this be marked as somewhat blocking for 1.0-alpha? Personally I would remove XmlField from the standard-models and create something like django.contrib.xml, which includes some common code for xml-handling (forms, models, dom/etree/..., xslt with callbacks, etc). But thats nothing I decide. > Is there > any good reason why the code you wrote has not been accepted? #3094 is accepted, but there has not been any (visible) progress for some time. So there will be a better solution, just be patient. About my code: This is far from being ready for checkin. I just 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 to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Some ideas about AUTH_PROFILE_MODULE (tickets: #7584, #7592 and #7400)
This basically started as a ticket suggesting adding some way to create a default profile for users which don't have one, moving the need to catch DoesNotExist-exceptions out of the applications using get_profile(). -> http://code.djangoproject.com/ticket/7584 julien did suggest some alternatives, which all bring some drawbacks with them and finally closed the ticket, as #7592 got closed, too. After some discussion he suggested bringing the topic up here. My current idea is to add the possibility to provide a get_for_user()-method in the profile manager, this would fix #7584, #7592 and even #7400...and would possible add room for more ideas, hence make the whole get_profile()-stuff more flexible. Patch: http://code.djangoproject.com/attachment/ticket/7584/django-profile-manager.patch So, about the alternatives: 1. Use signals (#7584, comment:1) Might work, but does not support on demand creation of profiles for legacy-users. There may be more use-cases where post_save is not enough. Still need to catch the exception, as you can't guarantee the existence of a profile. 2. Importing AUTH_PROFILE_MODULE yourself (#7592) Not really possible, think about templates for example. Even if only needed in views this duplicates code. 3. Own profile-module with appropriate manager (#7584, comment:3) Like importing AUTH_PROFILE_MODULE yourself, but with cleaner code. Still no easy support in templates. Does not work if application needs to be reusable (on some other website with different profiles). 4. Overwrite get() on profile-manager (#7584, comment:4) Possible, but seems rather hackish. Additionally nothing someone new to django might do or want to do. So is there any reason not to support creating profiles on demand? The patch is only three 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 this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Some ideas about AUTH_PROFILE_MODULE (tickets: #7584, #7592 and #7400)
> May be better way to use ``OneToOneField`` with proper > ``related_name`` like "profile" for example. Than profile can be > accessed very simple ``user.pofile``. and its creation machinery leave > to profile app author? Right, I knew there was a fifth alternative I forgot 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 --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Make clickable area of object links larger
> Each row in a change list represents one object, usability suffers by > making only one potentially tiny (an integer primary key) field > clickable. What about supporting custom urls for some fields in the future? (e.g. linking to an foreign object for model.ForeignKey) I would make 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 the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Make clickable area of object links larger
> There is already a way to control which fields are links to the change > page: http://www.djangoproject.com/documentation/model-api/#list-display-links I know, thats what I meant. To make the whole row clickable you have to put all fields which are in list_display into list_display_links, 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 Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unique_for_ fields
> Short version: model-aware validation is being worked on. We didn't get
> it finished for 1.0, but it's still ongoing work.
Wouldn't it be nice to replace these three parameters by something like:
class SomeModel(models.Model):
[...]
class Meta:
unique_together = ('title', 'pub_date__year')
Meaning we could use the same syntax as we do for filter()/explude().
This could allow new use-cases like some combination of fields should be
unique for some given date. Example:
class SomeCategorizedModel(models.Model):
[...]
class 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
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Customizable User model as GSoC project
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 this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
I need a pony: Model translations (aka "my proposal")
f course save all translations, too.
Now you might notice, that this sounds familiar. Yes, model inheritance
works similar. We have fields, that transparently are rewritten to the
right table on queries, save() UPDATEs many tables and attributes just
live in one object (obj.parent_field, instead of
obj.parent.parent_field). If you look at this right, you will see, that
the proposed translations are something like models using "reverse
inheritance", meaning behavior is like with inheritance, but the
semantics are reverse. The biggest difference is the changed JOIN, but
django should provide for most of the technics for this, even they need
to be enhanced.
So, what about the other stuff django model translation should provide:
a) fast: Only one JOIN involved, as you only need one language most of
the time. Otherwise its like solution two.
b) third-party-apps: Work like a charm, no fields changed and - because
of some default language in the query - only return objects that are in
the current site language.
c) transparent: If done like inheritance, this should be like
inheritance, so perfectly transparent.
b) missing translation: Supported by using LEFT JOIN.
e) searchable: Like inheritance.
f) extendable: Like normal models, south, django-evolution or similar
perhaps needed.
g) convert: Script needed for this, like sync_transmeta_db does.
h) keep context: Relations need to mind obj.language, should definitely
be possible.
i) optional: If you don't use translation.register() no translation is
done, not even the table is created.
j) generic: If you have some use-case I'm missing tell me.
k) central fields: slug can be translated, access is simple as fwhen
using inheritance.
l) all translations: Just leave the "AND xxx.language='yy'" out of the
JOIN and you get every translation. Similar to using Book.objects.all()
with my approach.
m) admin: Like solution two, I think people have come up with something
here. I still like the idea of viewing every possible translation ans
being able to edit this like one distinct object. But there might be
better solutions.
I have attached some sample usage example, perhaps this gives you some
more detail on the API I suggest.
I have looked into the code and think implementing this should be
possible, but needs some changes in the django-ORM itself. If should be
possible to implement this creating some TranslationQuery-object, but
you would have to copy many code to keep behavior in sync with the
normal Query.
If you read down until here, thank you. I know this is a lot of text
(hey, 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. Perhaps we can
share ideas and 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
--~--~-~--~~~---~--~~
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 email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
=> Just some basic idea
=> Needs to rewrite things down till the django Query objects, so implementing
this is non-trivial
>>> class SomeObj(models.Model):
>>> foo = models.CharField(...)
>>> bar = models.CharField(...)
>>>
>>> class SomeObjTranslation(translation.ModelTranslation):
>>> class Meta:
>>> fields = ('foo',)
>>> # use INNER or LEFT JOIN (LEFT JOIN means you get None back,
>>> # if selected translation does not exist, INNER JOIN means
>>> # objects without a translation get skipped)
>>> allow_empty = True
>>>
>>> translation.register(SomeObj, SomeObjTranslation)
=> Removes field 'foo' from SomeObj
=> Creates a new class with this field (+ language + object)
=> Sets up some useful methods, see below
=> Better: Change field 'foo' to point to SomeObjTranslation, like
model inheritance
--> Gets rewritten to:
>>> class SomeObj(models.Model):
>>> @property # has setter, too of course
>>> def foo(self):
>>> return self.translationsfoo
>>> @property
>>> de
Re: I need a pony: Model translations (aka "my proposal")
> I have looked into the code and think implementing this should be > possible, but needs some changes in the django-ORM itself. I read some of the code around Queryset, Model Inheritance and the Query-object itself. I _think_ the parts where django needs some adjustments can be limited to two patches: 1. conditional joins: Add the ability to use more complex conditions for the ON-clause in JOINs, meaning allow JOINs to be more than just "left_table.left_field = right_table.right_field". Perhaps WhereNode (django.db.sql.where.WhereNode) can be used, as this seems pretty generic (used for WHERE and HAVING already). Not sure about the dependencies WhereNode has on JOINs, so perhaps this ends in an chicken and egg problem. 2. foreign (model) fields: Add the ability to use fields from other tables as if they are present in the current Model. Model inheritance 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? 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 email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: I need a pony: Model translations (aka "my proposal")
> I don't research your idea deeply but for first look it seems very > similar or same to django-multilingual. > http://code.google.com/p/django-multilingual/ >From the database perspective it is similar, meaning it uses the same database structure. What I tried to write down was mostly some usage and API ideas to solve some things which pop up when using django-multilingual and others: * Make it possible to use third party apps in i18n environments even if the app was not designed to do this (This idea was stolen from pluggable-model-i18n.) * Don't add to much overhead for db performance and others (One JOIN, nothing more, this JOIN should be transparent to the user. This idea was stolen from model inheritance.) * Support getting results if no translation is available (sometimes you don't need to have a translation, for example if all fields are optional. This is possible in most model translation projects, even if it involves hammering the database with extra queries for each translation there. Conditional JOIN solves this in my proposal.) In conclusion I try to use the database structure django-multilingual proposes (which should be the best for the job anyway), keep usage as simple as using model inheritance (keep working with translations as simple as possible) while using a register approach to keep this application independent (thats some kind of killer feature). Hope this helps to see the differences here. Perhaps the file I attached helps to see some usage examples. One big advantage of my proposal over any existing solution is the possibility to use third party apps without changing their code. I still think this is very important as developers should not need to worry about internationalization when writing third party apps, because you should not need to use some complex database layout if you don't need translations. pluggable-model-i18n solves this, too, but it has some limitations/flaws. Using the pluggable-model-i18n you cannot optimize the SQL query when using translations and you run into many choices where to find a value, which are most significant if you want to query your database by some translated field (slug is translated: Book.objects.get(slug=...) vs. Book.objects.get(translation__slug=..., translation__language=...)). This are the two most significant disadvantages, others might appear when 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-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms issues
>> #3718 - newforms.Form.clean should have access to field errors [1]
Would like to see this one, too. Some validation I do currently is based
on the not-in-cleaned_data-trick, but this is IMHO not very clean.
And may be due to other reasons. For example if the field-clean-method
you want to validate data with is executed before the field is filled
(can happen when some field depends on data of some other field,
example: clean_password_repeat).
> Call me +0.5. I'd like to see this included, but I'll certainly defer
> to Adrian/Jacob on this one - after all, the status quo does work.
But it is not very DRYish, as you have to write the field-name twice:
* In the function-name
* Inside the function as a parameter to access cleaned_data
This may lead to complicated code when having a clean-function that is
used in multiple forms or inside the same form multiple times with
different field-names. Currently I solve this by using this code
(classes with __call__ defined could be used instead, but this makes
things worse):
--8<--
def clean_foo(field_name):
def real_clean_function(form):
# do something with form.cleaned_data[field_name]
return real_clean_function
class Form1(forms.Form):
clean_foo1 = clean_foo('foo1')
clean_foo2 = clean_foo('foo2')
class Form2(forms.Form):
clean_bar = clean_foo('bar')
-->8--
Additionally passing a parameter wouldn't break the current flexibility
present in clean_FIELD()-methods because other data in cleaned_data is
still accessible through the form-parameter. Anyway changing this would
simplify the most common use-case (and keeping 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
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Ticket #3297 and File uploads
> So the Unicode branch does decoding when
> things in request.GET and request.POST are accessed, not on
> construction, and you can change the encoding to whatever you like via
> an attribute on the HttpRequest (or http.QueryDict) class.
Perhaps request.POST.copy() could do this translation/decoding?
(Or some additional method for form-data, example:
request.POST.form_data([copy_fields=None]))
Changing the encoding after constructing the form does not look useful
to me, so the copy might as well be converted. As a nice side-effect the
encoding inside forms would be set in stone (at least after the
contruction of the form).
So this would work:
new_data = request.POST.copy() # converts data to DEFAULT_CHARSET
new_data.update(request.FILES) # raw data, not converted
f = MyForm(new_data)
If there are performance issues - because too much fields getting
converted - you may do something like this:
def init_form(request, form, data_fields=None):
if data_fields:
new_data = {}
for field in data_fields:
new_data[field] = request.POST.get(field, request.FILES[field])
else:
new_data = request.POST.copy()
new_data.update(request.FILES)
return form(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.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Ticket #3297 and File uploads
> Perhaps request.POST.copy() could do this translation/decoding?
Shouldn't request.{POST,GET}.copy() return an decoded version anyway?
Otherwise the copy() might look different to the vars under request:
post_copy = request.POST.copy()
if post_copy['foo'] == request.POST['foo']:
print 'all ok'
else:
print 'things get broken or at least very confusing'
request.encoding = 'some_other_encoding' # don't know your API here
if post_copy['foo'] == request.POST['foo']:
print 'maybe true, 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 missing something?
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: contrib.thumbnails approval?
> Maybe we can create a "thumbnails" folder inside the
> upload_to path and store thumbnails inside this folder. Remove based
> just on filename isn´t very good because the user can try to upload a
> thumbnail (or a file named like a thumbnail) and when removing based
> on filename, I will remove the original file too, do you understand
> me?
What about putting thumbnails into a folder named after the original
file _inside_ a thumbnail-folder. So if the file gets removed you can
delete the whole thumbnail-folder very easily. So the thumbnail-file
would be:
{{file_path}}/thumbnails/{{file_name}}/{thumbnail_method}}-{{thumbnail_size}}.{{file_extension}}
Example:
foo/bar/foobar.jpg -> foo/bar/thumbnails/foobar.jpg/crop-100x100.jpg
Perhaps the thumbnails-folder could be put into MEDIA_ROOT, so all
thumbnails can be deleted very easy or excluded from some
backup-strategy (this is IMHO even nicer):
foo/bar/foobar.jpg -> thumbnails/foo/bar/foobar.jpg/crop-100x100.jpg
Now a recursive delete will do the job of cleaning all thumbnails. A
script (cronjob-based) could just call os.path.exists() with the
excepted original name and delete the thumbnail-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 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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Shared memory across processes
> I have not yet used your app (although I had intended to until I read > this) so I assumed you had worked this out already. Same goes for me, but I try to answer something useful anyway. > The thing is, if > each process has to look to a central location to retrieve/update, why > not use the db as that central location? Or why not use a python-file as "cache"? AFAIK Django already reloads the settings-file if is has changes. So why not use this and put the settings generated from the DB there (or in some file imported in settings.py). A post_save-handler in the 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. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unicode branch - last call for comments(?)
> Merged in [5609].
Great!
There is only one thing I ran into so far. And I would not bring this up
now, if the commit didn't say "This should be fully backwards compatible
for all practical purposes.". (And I did not bring this up earlier,
because I thought this was intended)
Templates break if they use something like {{ object|escape }}. This is
due to the fact, that the object gets implicitly converted to a string
here. Now django.utils.encoding.force_unicode gets called (by the
template-filter), figures, that the model is some kind of basestring
(line 36), without __unicode__ (line 37) and tries to convert it into a
unicode-string (line 40). To do this it first calls str(s), this - in
detail - triggers:
* call object.__str__
* convert result to a normal string
As object.__str__ now returns an unicode-string (default implementation
of __str__ might look like "return self.title") str() will try to
convert this to a normal byte-string. If the unicode-string contains any
special chars this will fail ("'ascii' codec can't encode character
u'\xfc' in position 18: ordinal not in range(128)").
In any case this is bad if you look at the performance: you have an
unicode-string, which you need to convert to a byte-string only to
convert it back to unicode.
The solution is quite simple: Just write __unicode__ instead of __str__
in all your models. And I thought this might be needed to use the
unicode-branch anyway. But after you commit-message I thought you might
be interested in this edge-case.
Could be fixed by testing if the object has as __str__-method and test
if the result is unicode. Could be even better fixed by writing docs to
tell the user what changes are needed.
And perhaps it could be fixed by adding some __unicode__-method to
models.Model which tries to use __str__ or overwrite __str__ in the
models.ModelBase to always return a byte-string or...something like
this, just an idea.
Anyway (again), great work, thank you!
Fixed some special cases with unicode-strings 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 to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Unicode branch - last call for comments(?)
> 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.... 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Problem in current svn TRUNK
> Basically django simply exists whenever it gets data based from postgresql.. > anywhere. syncdb, inspecdb, /admin/ and everything else that access the db > simple die/exit with an "Aborted" message.. As the changeset mentioned earlier was the unicode-merge: Is the datebase-encoding set to unicode? Are all other steps towards unicode-support done? (Can't see any reason, why this matters when the table is empty - as shown in your example...but just to be sure) See: http://www.djangoproject.com/documentation/unicode/#creating-the-database http://code.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 django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #4001 - newforms commit=false and m2m data loss
> However, if commit=False, the m2m function is dynamically added to the > form instance. This means that the user can choose to invoke save_m2m > whenever they need. No m2m data loss! Why not add a handler for the post_save-signal of the Model? This way the user doesn't even have to know, that there is any difference (only if he tries to use m2m-relations that are not in the database yet). Of course an additional parameter to Form.save() could be added (m2m_autosave=True) to skip this and save_m2m() could be added to Form anyway...and even be the signal-handler or get 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
I did some thinking about the "aka"-parameter you use to name the old
fieldname/modelname and some things that would be nice to have when
schema _evolution_ is supported by django. I highlighted evolution,
because that means more than just "model changes, db needs update" I think.
I think the aka-method has some shortcomings:
* You have to change all your code at once to match the new name
(evolution is a slow process in nature ;-)
* The old name cannot change the type of the field
(for example ForeignKey -> ManyToMany)
* The change-info can only contain a name, nothing more
(goes hand in hand with the last point)
So after thinking some time about this I came up with this idea:
Old:
class SomeModel(models.Model):
new_fieldname = models.FooField(..., aka='old_fieldname')
New:
class SomeModel(models.Model):
new_fieldname = models.FooField(...)
# Not sure if new_fieldname as string or the
# new_fieldname-object ist better here.
# But I think the string might be easier.
old_fieldname = evolution.RenamedField('new_fieldname')
For Models:
class NewModel(models.Model):
pass
# May use models from other applications.
OldModel = evolution.MovedModel(NewModel)
In the following text I will only use fields as examples, but I think
models will be similar.
Because the old name is still an attribute in the model it can change
the new attribute/return the new attribute if it is returned. So all
code will work without changes. Now - because this is nonsense in the
long term - it will write logs/print warning/... (you name it). This can
be extended by using parameters:
evolution.RenamedField(..., obsolete=True) -> writes warning
evolution.RenamedField(..., deprecated=True) -> raises exception
(Perhaps I mixed the meaning of "deprecated" and "obsolete" here...not
sure about them)
...you could even give it a date where the old name gets rejected. I
think that would give users a great advantage other the current solution.
So the new use-case:
Users can change the model, change every code they know of directly, but
get warnings when they missed something (but code works). Now after some
time they can mark the old name to be deprecated, so access to it will
be rejected after they think they got all pieces. If the code works the
old name can be removed from the code (and should be removed...think
that goes for "aka" as well), if not the exception tells them what is
missing.
The next thing you could do now would be things like "Replace a
ForeignKey with ManyToMany" (which might a common use-case for
db-evolution I think), example:
class SomeModel(models.Model):
some_others = models.ManyToManyField(...)
some_other = evolution.ForeignKeyToManyToMany('some_others')
This now can first do some nice translation to fill the m2m-tables with
the old data. "some_other" might just return the first object in the
m2m-relation or None if the relation is empty. If this behavior doesn't
fit the user-idea of doing this deprecated/obsolete could be used to
reject access from the start (or some callback could be given to do it
"nicer").
Of course this is only one example on how this idea may help doing more
advanced stuff. Another use-case I can think of now is replacing an
BB-Code-field with some XML/Textile/Rest/...-field where the content
needs to be converted. Or a DateTimeField that gets replaced by a
DateField and a TimeField, so the data needs to be split up (or the
other way round).
Of course this means that the translation must be done inside python,
which is bad for performance, but at least its possible (and the
translation is only done once).
What do you think about this? In my opinion that could help big sites to
do model-changes in a productive 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 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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: How submit a patch with files not in subversion?
> The point is that I don't have write permissions on the subversion > tree... If you want to keep a log of your changes try using some decentralized version control system. I use svk, but git/mercurial/darcs/... might work similarly. I prefer svk, because it integrates very well into the existing svn-solution. Short introduction to svk: * Initialize your local repository: svk depotmap --init * Create a django-mirror: svk mirror http://code.djangoproject.com/svn/django/trunk/ //django-mirror/ * Synchronize the mirror (this will take some time): svk sync //django-mirror/ * Create your local branch: svk copy //django-mirror/ //django-my-great-feature/ * Checkout your branch: svk checkout //django-my-great-feature/ /to/some/path/ * Now just work with your local branch, like you would to with svn, but use svk to commit. svk commit (can be done multiple times) * If your changes are ready to create a patch, just do so: svk push -P django-my-great-feature * Not svk has created a patch in ~/.svk/patch/, you can view (and save) this using: svk patch --view django-my-great-feature * To update you branch to the latest svk-trunk (without removing you changes) use: svk pull * If you commit changes to your branch now (or if you did update you branch to trunk) you can update your patch using svk patch --update django-my-great-feature svk patch --regen django-my-great-feature For further information visit http://svk.bestpractical.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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: usability issues
> And again, I'll reiterate that the type of user who doesn't understand > case-sensitivity is the type of user who -- verified by repeated > real-world usability testing -- finds MySpace by going to Google and > typing "myspace.com" into the search box. An astonishingly high > percentage of web Full ACK In addition people who try to type URLs themselves often use what they learned from Wikipedia: "Type it in your style". Which means the following URLs are the same, too: * xx.wikipedia.org/wiki/Some Thing * xx.wikipedia.org/wiki/Some_Thing * xx.wikipedia.org/wiki/some thing Or to sum this up: Most of the time there is more needed to fit all the needs professional users want (slash appended or not, whitespace/dash/underscore are the same, URL is case-insensitive, special chars are translated on the fly (e.g. umlauts, ä -> ae)). 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 group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
About Changeset [5819]
First: Nice, that a working FileField got merged! (see: http://code.djangoproject.com/changeset/5819) After browsing the source to update my own patches I found that FileField.save_form_data() joins the filename and self.upload_to (see http://code.djangoproject.com/browser/django/trunk/django/db/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 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ModelChoiceField's clean() uses default manager instead of query set
> However, I'm a little confused now. I > thought the problem was only validation, and not the actual data that > was added to the choice list. The problem is, that validation does not use the actual data of the choice list. I think doing so may even become a security issue, as people 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, 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: manage.py idea?
> 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 --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
> I'm not particularly attached to these method names, but adding > methods on ModelAdmin, say, log_action() and send_user_message(), and > having the object-saving code call those methods instead of directly > handling logging and messages, would solve this pretty cleanly (and > also add a little bit more useful functionality for someone who wants > to roll their own implementation of these features). > > Anyone have strong feelings one way or another? Correct me if I'm wrong, but doesn't this miss the big parts when writing your own auth-application. After adding this two methods the tables for LogEntry and Message still exist in the database, but are unusable. If you want to use a similar functionality you have to replace all parts of the code using Message and/or LogEntry-models as User.message_set/logentry_set are not valid any more. For the re-usability of applications this does not help either. If you need your own auth-system in one application there is no way to get third-party-applications to use your auth-system without really ugly hacks. Currently it looks like parts of generic-auth are going into newforms-admin (permission-check-functions). I think this is not ideal, because now you have a nice designed system to authorize users, but it comes bundled to the admin. So I think having independent application for authorization would be better, newforms-admin could still use this. (Additionally I would split "auth" into authorization (has the permission?) and authentication (is login valid?)) As I did write my own auth-system I know that beeing able to fix the ForeignKeys to User in _one_ application is mostly not enough (this change does not fis django.contrib.comments for example). Anyway, it looks like this does not get fixed here at all, as the ForeignKeys _do_ still exist, but are not usable any more. So you need to skip message/log-creation at all or replace the code by using your own copy of LogEntry/Message with replaces ForeignKeys (To get this clear: 100% copy with only the import of User-model is enough). Thats sad, even if only because you have to duplicate code (no DRY) and can't use the things provided by django any more (without creating a copy). I once tried to get a solution by being able to _really_ replace the auth-application (meaning you can replace django.contrib.auth.models.User and similar), but this did not get much attention. Proof of concept: https://svn.webmasterpro.de/django-auth-rewrite/ ...works fine in my own application, but I did not patch django, instead I put it into my own application and replaced the imports in the current admin to get it working. I really think things could get a little less coupled to the auth-system django provides, as I needed this myself. So strictly speaking I'm for every change getting closer to a solution. But I don't think "fixing" (or working around) things in one application is enough, there needs to be a solution that provides this functionality everywhere or it needs to get fixed everywhere. See http://code.djangoproject.com/browser/django/trunk/django/views/generic/create_update.py#L42 for an example of coupling to django.contrib.auth: The generic view assumes request.user is available (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 --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
Sorry, i forgot this in my previous mail. > I'm not particularly attached to these method names, but adding > methods on ModelAdmin, say, log_action() and send_user_message(), and > having the object-saving code call those methods instead of directly > handling logging and messages, [...] Everybody who replaces the auth-system could simply provide User.message_set/logentry_set. Thats how I did it, this "fixes" things in more places than only the admin (e.g. generiv views). Example: class DjangoMessageUserSet(object): # dummy object def create(self, *args, **kwargs): pass class User(models.Model): # [...] message_set = DjangoMessageUserSet() So having log_action() and send_user_message() would mainly be nice to clean the code, but does not really provide any additional flexibility when replacing the auth-system. As 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 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
hods help people running the admin without
django.contrib.auth, but that's all. No django.contrib.comments or other
stuff that needs User-objects (and no re-usablility of third-party-apps
without code-changes). But after all I think only unbundling the admin
could be done with some if-statements inside the admin-code without
needing the user to do anything at all. Doing so you might even skip
having LogEntry (if is_installed("django.contrib.auth"): class
LogEntry()...). As for log_action() this could be done this way:
---8<---
class ModelAdmin(...):
[...]
if is_installed("django.contrib.auth"):
def log_action(self, user, action, ...):
user.logentry_set.create(action, ...)
else:
def log_action(self, user, action, ...):
pass
--->8---
(Note: is_installed() is some imaginary function I used, there might be
something in django to do this, but I think it's clear what I try to say
even if the function name is wrong)
As stated some weeks/month ago in an email about my
"auth-rewrite"-branch: I'm willing to help. Being able 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
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
> OK, so what you want is very very different from what I'm getting at here. Yes and no, see below. > What I want == newforms-admin can be run without django.contrib.auth, > and people who do so understand that in doing so they are jettisoning > anything which relies on django.contrib.auth. True, but I think it would be nice being able to keep the log if users have their own User-model. > What you want == django.contrib.auth becomes a magical wrapper which > transparently switches out the entire auth codebase on demand so that > 'from django.contrib.auth.models import User' might do practically > anything depending on the configuration. Half true. Actually I'm trying to tell you that even if you change the admin the way you propose users will still run into serious trouble when trying to replace django.contrib.auth. This begins with not being able to use all generic views and probably ends with other apps using django.contrib.auth (django.contrib.* or third-party). > These are so very much unlike each other that I'm not even sure why > one came up in a discussion of the other. Perhaps I'm missing > something? As you try to improve the situation for users who want to replace django.contrib.auth I think it is the right place. First because there are some things that remain unresolved even with your proposed change, second because I don't think fixing every application on it's own is the right way to get the situation resolved in the long term. At least third-party apps will remain problematic even if everything inside django.contrib is fixed. But perhaps I'm to focused on the idea of reusable apps like the documentation states: "A project can contain multiple apps. An app can be in multiple projects." (http://www.djangoproject.com/documentation/tutorial01/#creating-models) If you are only interested in fixing the admin it might be displaced, but please consider the things that will remain broken even with your changes. One example still is: Being able to override/disable send_user_message() inside the admin does not do the job, as Message comes from django.contrib.auth, so apps outside of the admin will probably count on having user.message_set. And reading the code even generic views (which are outside of _any_ app!) do rely on Message. (see previous mails) Additionally I think putting solutions for common problems into the admin is the wrong approach. This was done when putting has_FOO_permission() into the admin instead of focusing on something like the "generic-auth" branch and using the permission checks introduced there (why should I need 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, 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: API question for model saving
> Sometimes when calling save(), we know (for business reasons) that it
> must create a new object or raise an error. Similarly, in other cases,
> it either must update an existing object or raise an error.
I think discussion about this issue has been on this list before, last
time someone suggested adding create() and update()...and keeping save()
as an method calling these two, like:
-8<
class Model(...):
def save(self, ...):
if self.has_pk() and self.pk_exists():
self.update()
else:
self.create()
def update(): ...
def create(): ...
>8-
So what is the big advantage of having an new parameter in save() like
you suggested? With having create()/update() you can do similar things.
Additionally it would be possible to override only parts of the
save()-logic in classes extending Model (for example when needing to
calculate field-values on create, but not on insert...which is currently
difficult).
And, of course, you would have no problems 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 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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: API question for model saving
> For this particular case it saves a whole line. One concern I have is > that if there's more complex logic in your overridden save method, some > of it is going to be useful in both cases and now you have to create > extra sub-functions for the common bits and remember to call them both > times. It leads to duplication. If you look around at sample code on > django-users and other places, you can see people doing a number of > pieces of auxilliary processing as a result of save happening on the > instance, so this isn't a trivial issue. No, it does not duplicate code, as you still could use save() for common code. >> BTW, create()/update() sounds more explicit to me than save(). > > Which immediately leads to one of the problems with it. Suppose I'm > writing a function that accepts objects, does something to them and then > wants to save them. Do I call create() or update()? There's no way to > tell. Currently, I call save() with no ambiguity problem. > > Also, this presents an unnecessary backwards-incompatibility. Every > single piece of code now has to change to use one or other of these > methods. Every save() call. Currently and with the parameter approach, > *zero* existing code has to change initially. If you want to support the > must insert vs. must update difference, you can add a parameter (or two, > depending on which approach we take) and it's still backwards > compatible. Sorry, but this sounds like you did not read my email at all (to which David Larlet sent a reply). I proposed still having save(), but implementing it like this: -8< class Model(...): def save(self, ...): if self.has_pk() and self.pk_exists(): self.update() else: self.create() def update(...): ... def create(...): ... >8- I don't think this will break _any_ code using the old version of save(). > Finally, there's a namespacing problem. The current create() method, > which is really just a shortcut for __init__() + save() lives on the > model manager. An update() method (and presumably your version of > create()) would live on the class instance. "Update" 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 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
