Re: Model inheritance redux
Hi Bjørn,
Sure. In this case you would need a discriminator attribute on Place.
I'm thinking of code along the lines of:
class Place(models.Model):
...
discriminator = models.CharField(maxlength=50)
def save(self):
self.discriminator = self.__class__.__name__.lower()
models.Model.save(self)
def autocast(self):
return self.getattr(self.discriminator)
Then in your view:
def detail_view(id):
place = Place.objects.get(id).autocast()
return render_to_response(
"templates/place_%s.html" % place.discriminator,
place=place)
I'd be pleased to see Django require discriminator attributes on
superclasses, and then automagically retrieve the correct subclasses
at the correct times. It seems to work well enough in ORMs such as
Hibernate. However, I think I could happily live with Malcolm's
proposal too, even if it means writing code like the above every
now-and-then.
Alan
On 8/8/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote:
>
> Okay, I've got one more question. If we're not going to support
> querying for an object's real type, it becomes quite cumbersome to do
> anything polymorphically, which kind-of is the point of
> object-orientation.
>
> For example, to use the same URI spec & view for all the subtypes.
>
> OPTION 1: lots of if-then-else's
>
> def detail_view(id):
> place = Place.objects.get(id)
> if place.isinstance(Place): model_name = 'Place'
> elif place.isinstance(Restaurant): model_name = 'Restaurant'
> ...
> return render_to_response("templates/place_%s.html" % model_name,
> place)
>
> OPTION 2: embed the type in the URI
>
> def detail_view(model_name, id):
> ... # or map to a different view altogether
>
> Neither seem like very good solutions to me. Am I missing something?
>
>
> >
>
--
Alan Green
[EMAIL PROTECTED] - http://bright-green.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Model inheritance redux
On 8/8/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Tue, 2006-08-08 at 07:35 +0800, Russell Keith-Magee wrote: > [...] > > > > For those late to the discussion, it should be noted that this was one > > of the ideas proposed for implementing inheritance. It was rejected on > > two grounds: > > > > 1) Lack of support for legacy databases > > 2) The number of joins that would be required for queries in the > > general case. > > More for the first reason than the second, I thought. > > The join numbers are as small as possible when you have a discriminator > (because you can work out precisely the right tables to join); it's one > of their advantages. As soon as we threw out discriminators, true > transparent polymorphism (duck typing) became harder because the join > numbers now became O(# of nodes in the inheritance tree). Even with discriminators the queries would be very wide. When querying to retrieve a bunch of objects, you don't know which tables to join until after you've selected the discriminator value, so you have to outer join them all anyway. I didn't say so yet, but I think the proposal you outlined is a sensible compromise between functionality and implementation complexity. Cheers, Alan. > > Regards, > Malcolm > > > > > > -- Alan Green [EMAIL PROTECTED] - http://bright-green.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Model inheritance redux
On 8/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Next time I'm picking two Place types that have absolutely nothing in > common so that you can't twist my examples into cases like this. > Restaurants and SmallCometsInTheOortCloud, for example. I'm making this > too easy for you. Here's a use case where the functionality you've proposed would be just fine. My current application which has Person and Organisation classes. As people and organisations have certain attributes and relations in common (e.g addresses, emails and telephone numbers), my model includes another class named Party. That is: - Person has foreign key to Party - Organisation has foreign key to Party - Address has foreign key to Party - A party may have many addresses, and will either have a related Person, or a related Organisation It will be great to be able to make Party a "real" superclass. Furthermore, because of the two-levels deep relationships between Person, Party and Address, I have had to build custom CRUD pages for Person administration, and for Organisation administration. With inheritance, I'm supposing the Django admin app will now be able show Addresses on the Person and Organisation pages, so that's about 6 boring pages I won't have to write next time. Cheers, Alan. -- Alan Green [EMAIL PROTECTED] - http://bright-green.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: make templatetag loading magic a little more invisible
On 8/11/06, James Bennett <[EMAIL PROTECTED]> wrote: > The reason for this is that django/templatetags/__init__.py, when it > loops over INSTALLED_APPS to find templatetag libraries, > indiscriminately quashes ImportError -- apparently on the assumption > that any ImportError being raised is a result of a non-existent > 'templatetags' module. > > This is both frustrating and counterintuitive. I agree. Similar ignoring of ImportErrors in core/management.py has caused me many hours of unproductive head-slapping. > > There are two ways I can think of to solve this problem: > 2) Tweak django/templatetags/__init__.py to introspect the ImportError > it gets and figure out whether the exception came from a non-existent > 'templatetags' module (in which case it can be safely quashed) > Obviously I prefer the latter, since it results in more intuitive > behavior, but I'm interested in hearing what other people think about > this. I agree. Django should not be asking it's users to write boiler-plate code, even if that boiler-plate may be found somewhere 'obvious' in the documentation. a --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
A model_object.is_saved() method
Hi Everyone, I'd like to propose a small change to django.db.models.Model to make it neater to determine whether or not a model object is already stored in the database. Either: Option 1: Rename the _get_pk_val() method to get_pk_val(), marking it safe for public use. Option 2: Add a method named is_saved() which checks the value of the primary key. Here's the situation that inspired the proposal. I'm in the midst of some code to push objects in and out of custom FormManipulators. At several points, the code needs to determine whether or not the model objects are stored in the database, in order to know whether the object should be deleted. Since my model classes don't explicitly define primary keys, this is fairly simple - it's just a matter of checking model_object.id. Since I was doing it several times, I made up a utility method, "is_saved(model_object)". I now have this kind of code: if is_saved(object): object.delete() However, that doesn't look right - model objects know whether or not they've been saved, and should be able to communicate that without requiring the programmer to know the primary key name. I would have used django.db.models.Model._get_pk_val() method, except for the leading underscore marking the method as being for private use. Hence the first option, at the top of this email. If exposing the primary key value like that would be undesirable, a more modest option would be a simple "is_saved()" method. Does either of these options sound reasonable? If so, I'm happy to make up a patch, including changes to db-api.txt. Alan. -- Alan Green [EMAIL PROTECTED] - http://bright-green.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: A model_object.is_saved() method
On 8/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > This is an interesting feature request/idea. If we were to add a > default method along the lines of is_saved(), I think it would make > the most sense if that method actually *checked* the database rather > than just checking that the primary-key value is set. Ah yes. I was forgetting about records that may have their primary key hand-allocated rather than auto-allocated, and about data changes over an object's lifetime. Checking the database would also more closely match the logic of the save() method. > But, if I > understand correctly, that would be overkill for your situation, > right? Certainly it's more thorough than is required, but the small overhead of a query against a table's primary key would be acceptable at that point in the application. Alan. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Default escaping -- again!
On 7/29/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> We are trying to keep the auto-escaping environment completely within
> the control of the template author.
Thanks.
This is really important as even a plain old HTML file can require
several different kinds of escaping in different parts (e.g inside an
href attribute, in Javascript) and some parts that you never want to
escape (e.g {{ form.field }}). I'd hate to have to be switching back
and forth between the template and the view code each time there's a
little tweak to the UI.
I'm looking forward to seeing how it works in my templates,
Alan.
--
Alan Green
[EMAIL PROTECTED] - http://bright-green.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Admin "View on site" link broken
Hi,
I'm having a problem with the Admin "View on site" button. According
to http://www.djangoproject.com/documentation/model_api/#get-absolute-url
all I need to do is add a get_absolute_url() method to my model
objects and the admin interface will gain a "View on site" button that
links to my application's view of the object.
My model objects have a get_absolute_url() method, and the View on
site button appears as expected, however, the "View on site" button
links to strange relative urls like "../../../r/10003".
I dug around a little. The change_form.html template contains this code:
{% if has_absolute_url %}{% trans "View on site"
%}{% endif%}
This looks like a bug with some history. What is going on here?
Alan.
--
Alan Green
[EMAIL PROTECTED] - http://bright-green.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: RDBMS vs ODBMS
On 8/31/06, Karl Guertin <[EMAIL PROTECTED]> wrote: > > On 8/30/06, GinTon <[EMAIL PROTECTED]> wrote: > > I wanted to know your opinions. Since of my view point I think that the > > web frameworks with ODBMS will be the next big step. > > I prefer an RDBMS because I tend to integrate with other > projects/languages at the RDBMS level. The other advantage is that the > RDBMS are much better tested because they're in wider use. Leaving aside technical considerations, OODBMS's are simply unacceptable to many organisations. My company's clients are even wary of what they would call "new and untested" RDBMSs, such as MySQL and PostgreSQL! Alan. -- Alan Green [EMAIL PROTECTED] - http://bright-green.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Comment on auto-escaping proposals
On 9/13/06, SmileyChris <[EMAIL PROTECTED]> wrote: > > This suggestion was dismissed pretty fast last time it brought up. I > don't think this is the direction that the Django developers want to go > down. > You can find that discussion here: http://groups.google.com/group/django-developers/browse_thread/thread/9d14bc19120c2d49/5c7bf721a18a0465?#5c7bf721a18a0465 Cheers, Alan. -- Alan Green [EMAIL PROTECTED] - http://bright-green.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: RequiredIfOtherFieldsGiven validator
Hi Andy, Yep, this little corner of the validator module is a bit messy. I ran into exactly the problems you describe. It turns out that Matt Rigott first reported problems in this area in June, along with a patch. I noticed in July, updated the patch, and added unit tests (very topical!) I've been a bit wary of pestering Adrian, Jacob et. al. to apply the patch, given their current workloads. However, if you could have a look at the patch and comment and/or fix, then that would definitely help get these problems fixed. http://code.djangoproject.com/ticket/2266 Cheers, Alan. On 9/14/06, Andy Dustman <[EMAIL PROTECTED]> wrote: > > I noticed (after inferring it probably exists) the > RequiredIfOtherFieldsGiven validator, though it is currently > undocumented. The default error message is, "Please enter both fields > or leave them both empty." The actual test is: > > def __call__(self, field_data, all_data): > for field in self.other: > if all_data.get(field, False) and not field_data: > raise ValidationError, self.error_message > > Since field_data is a constant, this is equvalent to: > > def __call__(self, field_data, all_data): > if field_data: return > for field in self.other: > if all_data.get(field, False): > raise ValidationError, self.error_message > > i.e. if this field is set, then if any of the other fields are not > set, it's invalid. So the error message is wrong or there's a bug. > Based on the name of the validator, I think the problem is in the > error message. It should be more like "Please either enter this field > or leave the other ones empty." > > What I actually need for my app is OnlyIfOtherFieldsGiven, which in > fact is what the RequiredIfOtherFieldsGiven validation error claims to > be doing. The test for OnlyIfOtherFieldsGiven would be: > > def __call__(self, field_data, all_data): > for field in self.other: > if bool(all_data.get(field, False)) ^ bool(field_data): > raise ValidationError, self.error_message > > (Yes, bitwise-exclusive-or actually will work on booleans.) > > If there's some interest in actually having this in Django, let me > know and I'll write up a ticket with patch. > -- > This message has been scanned for memes and > dangerous content by MindScanner, and is > believed to be unclean. > > > > -- Alan Green [EMAIL PROTECTED] - http://bright-green.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
newforms feedback
Hi Adrian, I've been using newforms to implement a short form. Generally, it's been a smooth ride, and I appreciate the flexibility and simplicity of rendering compared to the old way. Between the doco, the examples in the test case and the code, using it was straightforward too. I have just three nits for you: 1. It would be nice if EmailField and URLField had max_length attributes. 2. When I tried to specify an empty label, with label='', I get the automatically generated label. For example, here I try to give the url field an empty label: >>> from django.newforms import * >>> class F(Form): url = URLField(label='') ... >>> F().as_p() u'Url: ' 3. maxlength vs max_length is going to annoy me until it is made consistent. I know you're working on it. :) Cheers, Alan -- Alan Green [EMAIL PROTECTED] - http://bright-green.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
