hi
للحصول على وزن مثالي في يوم واحد ادخل هنا http://www.antya7la.com/vb/t26066.html خبر مؤسف ومؤلم اتمنى الدخووول http://www.antya7la.com/vb/t26168.html اختاري لون الصبغ اللي اناسبح ( السايت عجيب) للنساء فقط http://www.antya7la.com/vb/t26211.html السلسلة الوثائقية الشيقة Walking with Dinosaurs كاملة 6 حلقات ومترجمه http://www.antya7la.com/vb/t26210.html اغتصبوها وجروها بدراجاتهم مسافة 500 متر ... صور http://www.antya7la.com/vb/t26207.html صور للتحول الخطير لقبر الشيخ زايد http://www.antya7la.com/vb/t26202.html العثور على جنين في إحدى مدارس الرياض .. http://www.antya7la.com/vb/t26201.html حصلت على البكالوريوس وعمرها 10 سنوات والدكتوراة وعمرها 14 عاماً http://www.antya7la.com/vb/t26183.html شاب ينام في البيوت المهجورة بالرياض والكوابيس تلاحقه.. http://www.antya7la.com/vb/t26200.html ابتهالات للشيخ نصر الدين طوبار http://www.antya7la.com/vb/t26166.html نبذة عن حياة الشيخ علي الطنطاوي http://www.antya7la.com/vb/t22188.html حكم التكبير وذكر والصلاة على النبي في المنتديات..(ارجو التثبيت )للاهمية http://www.antya7la.com/vb/t25842.html جزار مصري أراد حرق »قلب« القتيل والتخلص من دين 1300 دينار http://www.antya7la.com/vb/t26189.html قام بوضع العصا في مؤخرته وتصويره بهاتف محمول!! http://www.antya7la.com/vb/t26187.html صور وسائط مجموعة http://www.antya7la.com/vb/t25923.html كانت ممددة وعاريه والشيطان اغراني http://www.antya7la.com/vb/t25230.html برنامج Sothink من أقوى برامج تفكيك الفلاش http://www.antya7la.com/vb/t1419.html اردني يقتل ابنة عمه امام القاضي ورجال الأمن لرفضها الزواج منه http://www.antya7la.com/vb/t26188.html انتشار صور الجوال يغذي جرائم الشرف بكردستان العراق http://www.antya7la.com/vb/t26185.html الرئيس الغامبي يهدد بقطع رؤوس كل مثليي الجنس http://www.antya7la.com/vb/t26182.html العريس الثرى دعا زوجته للجنس الجماعى فخلعته http://www.antya7la.com/vb/t26177.html زوج اكتشف بالصدفة خيانة زوجته له بعد 15 سنة زواج http://www.antya7la.com/vb/t26169.html كيف تكونين صديقة دائمة لزوجك؟ http://www.antya7la.com/vb/t25690.html ملابس نوم مريحة للحامل http://www.antya7la.com/vb/t26165.html تعلم طريقة عمل بنر اعلاني بالفوتو شوب سهل جدا http://www.antya7la.com/vb/t25843.html ملابس مواليد http://www.antya7la.com/vb/t26160.html خطورة حبس البكــاء!! http://www.antya7la.com/vb/t26033.html هدية المولود http://www.antya7la.com/vb/t26156.html ملابس شيك للحوامل http://www.antya7la.com/vb/t26155.html بجايم للحوامل من La Senza2008 http://www.antya7la.com/vb/t26154.html صور لمفارش البيبي وكيلونات تجنن http://www.antya7la.com/vb/t26153.html مايووهات اطفال http://www.antya7la.com/vb/t26152.html اطقم نوم للعرووس http://www.antya7la.com/vb/t26151.html حذاء العروس http://www.antya7la.com/vb/t26150.html فساتين زفاف من محل الزهور http://www.antya7la.com/vb/t26149.html افكار رائعه لتزين وترتيب جهازالعروسه http://www.antya7la.com/vb/t26148.html صور ابطال مسلسل سنوات الضياع http://www.antya7la.com/vb/t22715.html آكــرٌٍهٍَكَ .. لكَـنْيَ آجـــدًٍكَ جًْــزٍُءآ منْــيَ.,!! http://www.antya7la.com/vb/t25956.html عيش بقلب .. وابتسم بقلب .. وسامح بقلب http://www.antya7la.com/vb/t25961.html هـــل تبكي عندما يموت من جرحكـ يوماً ما ؟؟؟ http://www.antya7la.com/vb/t26032.html طفلة عمرها 12 عاما ومبدعة http://www.antya7la.com/vb/t2014.html الرجل الذي تحول لشجره ... مع الصور.!! http://www.antya7la.com/vb/t25856.html الفرق بين كلمة (الله ) وكلمة ( اللة ) أمر خطييير جداً ... http://www.antya7la.com/vb/t24746.html رفقاً بالعيون http://www.antya7la.com/vb/t24752.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Sites M2M field in Newforms Admin
I am in the middle of porting some code to the newforms admin branch. One of the fields in my models was as follows: sites = models.ManyToManyField(Site) ...where 'Site' is django.contrib.sites.models.Site Before switching to the newforms admin branch, if I created a new entry in admin, by default the active site was already selected, and the user could hit the save button straight away without an error that the field is required. After switching to the newforms admin branch, the default site is not selected anymore on creating a new entry in admin, and the user has to select the site manually before saving, as sites cannot be None otherwise they get an error. This is not what I want, because in admin, sites is in a collapsed fieldset area called 'Advanced' which is not used as much in my app, and I don't want to user to have to worry about it normally. I asked about this in IRC before, and as far as I am aware, I was told I need to create something like the following method: def formfield_for_dbfield(self, db_field, **kwargs): if db_field.name == 'sites': kwargs['widget'] = SelectMultiple return super(MyModelOptions, self).formfield_for_dbfield(db_field, **kwargs) My question is, how (or where) can I set it, so when I create a new entry in admin for my model, by default the active site is selected? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
database schema support
I know this has been touched on a couple times, but I have an itch for database schema support I'd like to scratch. The relevant ticket it #6148 [1]. I was thinking the Options class would grow a db_schema field, which would default to settings.DEFAULT_DATABASE_SCHEMA. Then everywhere that currently deals with db_table will also take db_schema into account, if specified. My initial thought was that it'd be relatively easy to introduce a new Options property, db_quoted_name (or something), that would return an already-quoted "schema"."table" string, then use this in place of db_table pretty much everywhere. This will avoid having to muck with the join tuples and aliases in django.db.models.sql.query, since db_quoted_name will be canonical (db_table no longer will be). There will be certain places (index and sequence SQL generation come to mind) where the schema will need to be dealt with separately. Also, the table introspection code will need to return schema names as well as table names, if applicable. The ticket mentions app-level schema support, which would be nice, but I think can be punted until #3591 [2] lands. Then the app class could take a schema argument that would be propagated to the models when the app is loaded, for models that do not already define db_schema. Any thoughts or suggestions? [1] http://code.djangoproject.com/ticket/6148 [2] http://code.djangoproject.com/ticket/3591 --~--~-~--~~~---~--~~ 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: Many to Many Inline Editing
See ticket #6095 in trac. The fix is on its way. Cheers, Cliff On Mon, 2008-05-19 at 06:53 -0700, JReynolds wrote: > I posted this on django-users before and didn't get much response, so > asking here... > > I have seen this posted a few times on the list here, but it always > seems to become a discussion about the many to many implementation and > move away from making it work as the one to many inline editing works > in the newforms-admin branch. > > So... does anyone have a fix for being able to add/edit/delete objects > on the other side of a many to many relationship from the edit view of > a model? I have tried to hack up a fix by copying and changing the > current inline implementation, but can't even get the forms to > generate. I can elaborate on my failure if no one else has any > working ideas... > > I'm sure I'm not the only one that needs this and can't seem to get it > done myself, so maybe this is a useful feature that could be added by > someone with a better understanding of the admin internals? > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Where should I start? (#2539, #3544, #6915, #7154, #7215, #7312)
Hello,
I'm quite new to django (first real project) and stumbled across several
bugs/features that I'd like to see in trunk. And I'm willing and
hopefully able
to help. Here they are: #2539, #3544, #6915, #7154, #7215, #7312, and
(cosmetic)
#5537.
The following should probably be split into different threads, but I
did't feel
like spamming the list ..
1. Abstract base classes should be able to provide Managers (#7154).
Then the first manager definition for each subclass will be the
abstract base
class' manager and therefore become the subclass' default manager
(if it's not
overwritten). Now you can either specify a different default
manager or keep
the base class' manager - you can't do both.
I've not been bitten by this so far (not shure I ever will,
because I stick to
a single Manager and subclass as necessary), anyway:
I'd suggest changing default manager resolution from "whichever
comes first"
to "whichever is called `objects`" - imho that would be much
cleaner, even
without the abstract base class usecase.
I'm aware this is probably a big backwards-incompatible change,
but it could
be worth it, for the sake of clarity.
2. I would have expected custom Model.delete() methods to called
whenever the
ORM wants to delete objects in that model. However, QuerySet.delete
() uses a
single SQL statement and you only get a signal. This is #6915.
So either prohibit custom delete() methods (a dont-call-delete-
unless-you-
really-mean-it policy) or make sure delete() is called every time.
In the latter case QuerySet.delete() could easily be patched to
work on sliced
QuerySets too - and should probably rollback if any custom delete
() call
fails.
3. Namespaces. I really like namespaces. That's why I like #2539. And
why I dis-
like the app_label concept. It's a crippled one-word namespace
and makes me
think about save app_labels far to long (might there be a usefull
3rd-party
app that happens to use this?). Proposal:
INSTALLED_APPS = (
AppConfig('django.contrib.auth', db_table_prefix = 'xauth'),
)
AppConfig could optionally take a `settings` keyword argument so
custom
settings would not need a 'MYAPP_' prefix. This would obviously
require an
api to retrieve those settings.
4. add_to_query() needs documentation. And tests. And a fix: see #7312.
I would start this, but after reading
django.db.models.sql.query.Query, I'm
scared.
Where should I start?
__
Johannes
--~--~-~--~~~---~--~~
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: Interaction between [Multiple]ModelChoiceField and its widget
> Also, when the number of choices is big, none of the provided widgets > are very usable, so I have for instance created a TreeSelect widget > which groups choices into categories (columns in the table) and > displays them in a tree whose branches are collapsible (see an example > at [1]). But in order to do that, the widget needs to know its > field's queryset, not just its choices. > > But as far as I can see, there is no builtin way, when you change the > queryset property of a [Multiple]ModelChoiceField, for this change to > propagate automatically to its widget. I totally agree. A common use case I've encountered when using the admin (specifically, I'm using newforms-admin) is the ability to override the Model[Multiple]Choice field to only display the related objects associated with a given model in the admin. Otherwise, the browser buckles under the pressure of having to populate a element with thousands of possibilities. I believe such a customization hook would benefit newforms-admin, and as customization hooks are currently being discussed in a separate thread [1] perhaps it should be mentioned again there. Now before someone comes saying "use raw_id_fields", they are insufficient because they are, well, too "raw" -- forcing a client to input integer ids is not my idea of user friendly. I had to come up with my own form fields, widgets, and a `ModelAdmin` subclass to accomplish the customization of the queryset displayed to the user [2]. Much of the code would be unnecessary if it was possible to easily override the queryset. [1] Simon Willison, "newforms-admin customisation hook suggestions", http://groups.google.com/group/django-developers/browse_thread/thread/53eaa25074ff4369 [2] http://geodjango.org/hg/limited_related/ --~--~-~--~~~---~--~~ 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: Ability to specify a skeleton project
On 28 May 2008, at 3:12 pm, phillc wrote: > i would use it as well. > i was actually thinking how on earth could i simplify the same thing i > do for every single project > (splitting settings.py to allow for revision control, splitting > urls.py, etc.) Ok, thanks everyone for your feedback, I'll have a stab at coding it. -- David Reynolds [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Runtime initialisation of db_table from context
Thanks Ben, That looks like it'll do it, I'll give it a whirl. Chris On May 29, 3:34 pm, "Ben Ford" <[EMAIL PROTECTED]> wrote: > Hi Chris, > > You could copy the whole model, ala DynamicModels on the wiki > [http://code.djangoproject.com/wiki/DynamicModels], I've sketched out a more > complete example here:http://www.djangosnippets.org/snippets/442/. This > example (I say example as it's a bit rough around the edges - especially the > field copying code!) was needed when working with the old multi-db branch to > specify a different database, so there are some things that won't work with > trunk (the references to "connections" for example). The advantage of > copying the whole model is that you can then do anything you want with it > and the django API doesn't change. > > Cheers, > Ben > > 2008/5/29 ChrisStoyles <[EMAIL PROTECTED]>: > > > > > Hi Everyone, > > > I've been doing some prototyping with django to see how good of a fit > > it will be for an upcoming project, and would like to run an idea past > > you guys. I'll try and explain my situation first, and then ask the > > question afterward. > > > At a very high level, I have an application, which holds many > > organisations, and these organisations each contain many products. I > > may need to at times, partition the product data, so that some > > organisation products are stored in table 'a' and others are stored in > > table 'b'. However the Product as a model class is the same between > > both of these, and I won't know the names of these tables until > > runtime (they may be based on organisation names, which would be > > created by users). > > > So as you might already have guessed, I would like to be able to use > > my "Product" model class across many tables. I would do this by > > changing the value of db_table. This however only works for saving an > > instance of Product (I can change the db_table value for that > > instance, prior to saving, and it will be committed to said table). I > > cannot however change the db_table property for a single thread, so as > > to fetch a Product from any arbitrary table name. > > > I believe what would be needed is the ability to supply a context at > > runtime, from which db_table could be determined, i.e. > > Product.objects.all(ctx) where ctx.db_table is the name of the product > > table I wish to use > > > That is a very quick and dirty example, however I hope I have still > > made sense and might be able to get some feedback from the developer > > community. > > > Thanks! > > Chris > > -- > Regards, > Ben Ford > [EMAIL PROTECTED] > +447792598685 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Interaction between [Multiple]ModelChoiceField and its widget
Hi, I would like to suggest a modest change in some newforms objects, namely ModelChoiceField and MultipleModelChoiceField, and how they interact with their widgets. Before I describe the change, let me explain an example in which I think this is desirable. There is also the possibility that I have not understood newforms correctly, in which case please forgive me! == Example == I find it quite common to create a form with a [Multiple]ModelChoiceField which I have to assign dyamically (according to what choices are accessible to the current user, for example). Also, when the number of choices is big, none of the provided widgets are very usable, so I have for instance created a TreeSelect widget which groups choices into categories (columns in the table) and displays them in a tree whose branches are collapsible (see an example at [1]). But in order to do that, the widget needs to know its field's queryset, not just its choices. But as far as I can see, there is no builtin way, when you change the queryset property of a [Multiple]ModelChoiceField, for this change to propagate automatically to its widget. Instead a ModelChoiceIterator is built from the queryset and is passed to the widget as its new choices attribute. For example, I have a form for creating a 'loop game': class CustomLoopForm(forms.ModelForm): questions = forms.ModelMultipleChoiceField( None, label="Questions", widget=TreeSelect(grouper='category')) Now when I build the form, the questions available depend on who is logged in, so I have to do something like this # Taylor available questions according to current user avail_questions = Item.objects.visible_by(request.user) loopform.fields['questions'].queryset = avail_questions loopform.fields['questions'].widget.queryset = avail_questions and repeat myself. I think there should be a way for the 'questions' fields to propagate its new queryset to its widget, just like a normal ChoiceField propagates its new choices to its widget. == What I would like == At the moment, in django.newforms.models.ModelChoiceField we have: def _get_queryset(self): return self._queryset def _set_queryset(self, queryset): self._queryset = queryset self.widget.choices = self.choices queryset = property(_get_queryset, _set_queryset) This could be changed like this: def _set_queryset(self, queryset): self._queryset = queryset if hasattr(self.widget, 'queryset'): self.widget.queryset = queryset if hasattr(self.widget, 'choices'): self.widget.choices = self.choices So that widgets that want to use extra information about the choices (such as my TreeSelect widget) can be updated by their field accordingly. Another solution would be to let widgets have a 'field' attribute telling them what field they are a widget for, but I don't know how that would work as several fields can share the same widget. -- Arnaud [1] http://www.marooned.org.uk/qmm/games/bingo/new/ --~--~-~--~~~---~--~~ 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: Runtime initialisation of db_table from context
Hi Chris, You could copy the whole model, ala DynamicModels on the wiki [ http://code.djangoproject.com/wiki/DynamicModels], I've sketched out a more complete example here: http://www.djangosnippets.org/snippets/442/. This example (I say example as it's a bit rough around the edges - especially the field copying code!) was needed when working with the old multi-db branch to specify a different database, so there are some things that won't work with trunk (the references to "connections" for example). The advantage of copying the whole model is that you can then do anything you want with it and the django API doesn't change. Cheers, Ben 2008/5/29 ChrisStoyles <[EMAIL PROTECTED]>: > > Hi Everyone, > > I've been doing some prototyping with django to see how good of a fit > it will be for an upcoming project, and would like to run an idea past > you guys. I'll try and explain my situation first, and then ask the > question afterward. > > At a very high level, I have an application, which holds many > organisations, and these organisations each contain many products. I > may need to at times, partition the product data, so that some > organisation products are stored in table 'a' and others are stored in > table 'b'. However the Product as a model class is the same between > both of these, and I won't know the names of these tables until > runtime (they may be based on organisation names, which would be > created by users). > > So as you might already have guessed, I would like to be able to use > my "Product" model class across many tables. I would do this by > changing the value of db_table. This however only works for saving an > instance of Product (I can change the db_table value for that > instance, prior to saving, and it will be committed to said table). I > cannot however change the db_table property for a single thread, so as > to fetch a Product from any arbitrary table name. > > I believe what would be needed is the ability to supply a context at > runtime, from which db_table could be determined, i.e. > Product.objects.all(ctx) where ctx.db_table is the name of the product > table I wish to use > > That is a very quick and dirty example, however I hope I have still > made sense and might be able to get some feedback from the developer > community. > > Thanks! > Chris > > > -- Regards, Ben Ford [EMAIL PROTECTED] +447792598685 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
