Question about scope of variables in template blocks

[Alex Rades]

Hi,
I'm sorry for asking this here, but the question was raised several
time on the -users mailing list and I don't think we users have a
solution for it.

Basically, the problem is that if I call a templatetag into a block
and it fills me a variiable with the usual context[varname]=something,
then if I need that variable into another block, I have to call the
templatetag again. This for me means extra db queries, which is really
something I'm trying to avoid.

This templatetag is called in a base template which is extended by
many other templates, so I can't just change all the views to pass
something to the context, it makes no sense (WET principle?)

Even a context processor would be not good because I don't want to
call it for every page rendered in the site, even the ones not based
on that template.

I was thinking about writing a templatetag which would use the
internal context structures to put the variable in a global context,
but I'd feel too guilty doing it.

How would you solve this problem?
Thank you!
-- 
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.

Ordering of ManyToManyField using a field of the intermediate table

[Alex Rades]

Hi,
I've also asked on the users ml but got no anwser. Maybe you can
undestand the question better?

Hi,
I have a couple of models like:

class Album(models.Model):
   title = models.CharField(max_length=255)

class Image(models.Model):
   image = models.ImageField(upload_to='images/')
   albums = models.ManyToManyField(Album, blank=True)

the schema of the intermediate table is, of course:

 `id` int(11) NOT NULL auto_increment,
 `image_id` int(11) NOT NULL,
 `album_id` int(11) NOT NULL,

Is it possible to order album.image_set with respect to the ID field
of the intermediate table?
I'd like to do this so i can efficiently sort images in the order they
were added to the album.

Thank you!

--~--~-~--~~~---~--~~
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: Default manager

[Alex Rades]

On Tue, Dec 16, 2008 at 11:55 PM, Alex Rades <alera...@gmail.com> wrote:
> On Tue, Dec 16, 2008 at 5:49 PM, James Bennett <ubernost...@gmail.com> wrote:
>>
>> On Tue, Dec 16, 2008 at 10:21 AM, Alberto Donato
>> <alberto.don...@gmail.com> wrote:
>>> I don't see any downside in this proposal.
>>
>> His proposal seems to center around forcibly making "objects" *always*
>> be a manager returning an unfiltered QuerySet, so I'm not sure where
>> it'd allow for that. And that's a downside (not to mention the fact
>> that it's really not that hard to get stuff right currently -- the
>> default behavior works, and if you start customizing the documentation
>> explains clearly what will happen and what to do).
>
> Hi,
> I don't want to forcibly make "objects" always  be a manager returning
> QuerySect.
Sorry... better to write stuff like this when you're awake. I mean
"manager returning unfiltered QuerySet"

--~--~-~--~~~---~--~~
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: Default manager

[Alex Rades]

On Tue, Dec 16, 2008 at 5:49 PM, James Bennett  wrote:
>
> On Tue, Dec 16, 2008 at 10:21 AM, Alberto Donato
>  wrote:
>> I don't see any downside in this proposal.
>
> His proposal seems to center around forcibly making "objects" *always*
> be a manager returning an unfiltered QuerySet, so I'm not sure where
> it'd allow for that. And that's a downside (not to mention the fact
> that it's really not that hard to get stuff right currently -- the
> default behavior works, and if you start customizing the documentation
> explains clearly what will happen and what to do).

Hi,
I don't want to forcibly make "objects" always  be a manager returning
QuerySect. Infact with my proposal, if you want to restrict somewhat
the "objects" manager, you just override it.

--~--~-~--~~~---~--~~
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: Default manager

[Alex Rades]

On Mon, Dec 15, 2008 at 3:12 PM, Karen Tracey <kmtra...@gmail.com> wrote:
> On Mon, Dec 15, 2008 at 5:51 AM, Alex Rades <alera...@gmail.com> wrote:
>>
>> Hi,
>> my understanding about custom managers is that if you want to define a
>> custom manager, you also HAVE to remember to define the "objects"
>> manager first, otherwise some parts of django (eg. admin) will not
>> work.
>
> What does "will not work" mean, exactly?  I recall looking at this in
> response to a ticket at one point, and the admin behavior I observed was
> internally consistent and made logical sense to me (if I recall correctly,
> if something was excluded in the default manager, it didn't show up in the
> change list, and an attempt to get to its individual edit page by manually
> constructing the appropriate url returned a 404).  I can't tell from what
> you've said if this behavior constitutes what you mean by "will not work",
> if this behavior has changed, or if there is something else about admin's
> behavior in this situation that you are objecting to.

With "not work" I mean nothing is displayed in the admin listing pages
(UNLESS you remember to define the "objects" manager. )

Lets take a closer look... if you write something like:

class DummyManager(models.Manager):
def get_query_set(self):
return EmptyQuerySet()

class MyModel(models.Model):
[...]
dummies = DummyManager()

"dummies" now is the default manager, and the admin listing page is
empty. This is fine since the default manager returns an empty qset.
This is also fine since the admin uses MyModel._default_manager to
access it.

So, yes the admin behaviour complies with the documentation. While its
behaviour is correct, I think the general idea behind the declaraction
of managers it is counterintuitive. Why? Imagine we want to _add_ a
manager to our model which does some kind of filtering. If you want to
retain the ability to access ALL of your MyModel objects, you are
forced to write an additional manager. The previous example becomes:

class MyModel(models.Model):
   [...]
   amanager = models.Manager()
   dummies = DummyManager()

I think that a general manager, which returns all the model
instancies, should be always present and accessibile. Of course if you
really need, you canoverwrite it. But I think that having to add 2
managers when you just need to add one is wrong.
Another +1 for this is that if you want to access the default manager,
at the moment you have to use

MyModel._default_manager

Which relies on an implementation detail and looks very bad.

So, my proposal is to make the "objects" manager always present and
accessible, and remove the _default_manager stuff. If you want to
change the default manager, just override "objects". If you want to
access the default manager, just access "objects".

>
>>
>> I find this suboptimal.
>>
>> I think that "objects" should always be the default manager, always
>> present and working. If you want to define a new one, this should not
>> interfere with "objects" being present and working. Of course you can
>> overwrite "objects" if you need to (eg. when you want to customize the
>> initial queryset).
>>
>> The downside of this solution is that you cannot use a field named
>> "objects", but this is a feature for me, as it improves readability.
>>
>> What do you think?
>>
>
> I'd think it unlikely at this point a change would be made that would
> prohibit having a field named 'objects'; the time for such a
> backwards-incompatible change was pre 1.0, if ever. If no one pre-1.0 found
> the exisitng behavior troublesome enough to make a convincing argument that
> such a change was needed I'm doubtful a case can be made now.  Also, due to
> the fact that you haven't defined "broken" I'm unconvinced that whatever
> troublesome admin behavior is involved here couldn't be fixed with some
> other, backwards-compatible, change.  So if you really want to pursue this
> you need to lay out exactly what admin behavior causes problems in this
> area, and show how it couldn't be fixed in some other way than introducing
> such a backwards-incompatible change.

I've never said I'd like to see this behaviour in 1.0 :)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Default manager

[Alex Rades]

Hi,
my understanding about custom managers is that if you want to define a
custom manager, you also HAVE to remember to define the "objects"
manager first, otherwise some parts of django (eg. admin) will not
work.

I find this suboptimal.

I think that "objects" should always be the default manager, always
present and working. If you want to define a new one, this should not
interfere with "objects" being present and working. Of course you can
overwrite "objects" if you need to (eg. when you want to customize the
initial queryset).

The downside of this solution is that you cannot use a field named
"objects", but this is a feature for me, as it improves readability.

What do you think?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

validator_list still in docs

[Alex Rades]

Hi,
validator_list in model fields (and maybe in form fields too) isn't
working at the moment.

Could we remove it from the docs?

--~--~-~--~~~---~--~~
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: Checkboxes in admin

[Alex Rades]

In the admin site, all fields have this kind of placement:

label_a: formfield_a
label_b: formfield_b

but checkboxes are:

formfield_c: label_c

I think introducing this different behaviour only for checkboxes is
aesthetically and logically wrong.

On Fri, Aug 22, 2008 at 9:35 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
>
> On Fri, Aug 22, 2008 at 1:12 PM, Alex Rades <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>> Is there a reason for checkboxes (BooleanField) in admin having the
>> label on the right side instead of left?
>
> Isn't that how check boxes are generally displayed? I don't recall
> them the other way anywhere - and would find that confusing.
>
> --
> 
> Waylan Limberg
> [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
-~--~~~~--~~--~--~---

Checkboxes in admin

[Alex Rades]

Hi,
Is there a reason for checkboxes (BooleanField) in admin having the
label on the right side instead of left?

--~--~-~--~~~---~--~~
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: IPAddressField not working

[Alex Rades]

Oops I've sent accidentally a draft of this mail 2 minutes ago, while i was
still writing it. Please read this one.

In nfa, IPAddressField with psycopg2 is not working (neither is XMLField, as
already reported, but lets focus on the IPAddressField).

There is a ticket with a patch at:
http://code.djangoproject.com/ticket/5622

The situation is that in some db, IPAddressField is treated as a string (so
null=False is valid), while in pg, you have to pass null=True since a null
value for a inet column is not acceptable.

So basically you have to know which backend you target while you write
models.

I think in this case we should make sure that an empty string value  is
converted to a null in both neforms/fields.py and in
db/backends/postgresql_psycopg2/ so we can remove this null=True requirement
from the model, and make the situation omogeneous among databases.

Basically, i think that we should fix the patch in the ticket (which deals
with newforms/fields.py and register a filter into
db/backends/postgresql_psycopg2/base.py which converts an empty string to a
null, but I can't find how to do this.

(moreover the psycogp2 site is dead since months and there is no
documentation of these inner workings, please resurrect it!).


Could you help me to understand what to do?

Thanks

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

IPAddressField not working

[Alex Rades]

Hi,
in nfa, IPAddressField with psycopg2 is not working (neither is XMLField, as
already reported, but lets focus on the IPAddressField).

There is a ticket with a patch at:
http://code.djangoproject.com/ticket/5622

The situation is that in some db, IPAddressField is treated as

I've tried the patch but  it is not working for me, and anyway it seems this
should be fixed at the db layer.

I'd like to fix this issue, so i went into db/backends/postgresql_psycopg2/
to understand what to do.
Basically, i think that we should fix the patch in the ticket (which deals
with newforms/fields.py and register a filter which converts an empty string
to a null, but I can't find how to do this.

(moreover the psycogp2 site is dead since months and there is no
documentation of these inner workings, please resurrect it!),

--~--~-~--~~~---~--~~
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: Non editable fields in admin

[Alex Rades]

You mean this?

http://code.djangoproject.com/wiki/NewformsHOWTO#Q:HowdoIchangetheattributesforawidgetonasinglefieldinmymodel
.

It seems there is quite a lot of code involved for each readonly field you
want do display... something like readonly_fields would be way better IMHO.

On Fri, Jul 4, 2008 at 10:19 PM, TiNo <[EMAIL PROTECTED]> wrote:

> How about creating a widget that just displays the data? Then override the
> form and use this widget instead of the default widget.
>
>
> On Fri, Jul 4, 2008 at 6:14 PM, Alex Rades <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>> I'm writing an application which makes a pretty heavy use of the
>> newforms-admin administrative site.
>>
>> One recurring need is displaying of informative fields (fields which
>> should not be editable from the admin site, but only viewed).
>> For example, imagine to have a DateField field into a Story class, which
>> is automatically updated every time a user writes a new story. It is
>> desiderable to see this value in the admin site, but has no sense (actually
>> is wrong) to allow modifications to it.
>>
>> Note that this is different from the purpose of the 'editable' attribute,
>> what I'm talking about is a presentation-only feature, and for this reason
>> we could put it into ModelAdmin classes:
>>
>> class StoryOptions(admin.ModelAdmin):
>> readonly_fields = ('lastupdate',)
>>
>> People have been asking this a lot of times, at least here:
>>
>> http://code.djangoproject.com/ticket/342
>> http://code.djangoproject.com/ticket/611
>> http://code.djangoproject.com/ticket/1714
>> http://code.djangoproject.com/ticket/3990
>>
>> Is there a working solution to display this kind of readonly data in the
>> admin site?
>>
>> Thank you
>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Non editable fields in admin

[Alex Rades]

Hi,
I'm writing an application which makes a pretty heavy use of the
newforms-admin administrative site.

One recurring need is displaying of informative fields (fields which should
not be editable from the admin site, but only viewed).
For example, imagine to have a DateField field into a Story class, which is
automatically updated every time a user writes a new story. It is
desiderable to see this value in the admin site, but has no sense (actually
is wrong) to allow modifications to it.

Note that this is different from the purpose of the 'editable' attribute,
what I'm talking about is a presentation-only feature, and for this reason
we could put it into ModelAdmin classes:

class StoryOptions(admin.ModelAdmin):
readonly_fields = ('lastupdate',)

People have been asking this a lot of times, at least here:

http://code.djangoproject.com/ticket/342
http://code.djangoproject.com/ticket/611
http://code.djangoproject.com/ticket/1714
http://code.djangoproject.com/ticket/3990

Is there a working solution to display this kind of readonly data in the
admin site?

Thank you

--~--~-~--~~~---~--~~
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

[Alex Rades]

Shouldn't this be marked as somewhat blocking for 1.0-alpha? Is there any
good reason why the code you wrote has not been accepted?

On Tue, Jul 1, 2008 at 6:46 PM, David Danier <[EMAIL PROTECTED]>
wrote:

>
> > 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
-~--~~~~--~~--~--~---

XMLField in nfa

[Alex Rades]

Hi,
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?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---