Comparing BoundField values in templates

[ekellner]

Hi, I am having trouble working with a BoundField value in a template.

What I have is a IntergerField that is represented by a set of Radio
Buttons in html. I want to lay out these buttons myself, and plus
there's javascript involved.  I don't believe there's a way to do this
while letting the field render itself.

I need to have the "checked" attribute set for the appropriate radio
button, according to the bound field value on the form.I am trying
to do this manually -- to print out "checked" inside the input element
a manual comparison of the bound field's value, but it isn't working.
 Note that I need to do this even when the form doesn't validate, so I
need to pull the value from form.field.initial or form.field.data
selectively, and so I have a template filter tag to do this.

Here's the code, isolated:

### a filter to get the bound field value independent of whether it
comes from initial/data
@register.filter
def boundvalue(boundfield):
"Copied from BoundField.as_widget"
if not boundfield.form.is_bound:
data = boundfield.form.initial.get(boundfield.name,
boundfield.field.initial)
if callable(data):
data = data()
else:
data = boundfield.data
return data

### My Template


### The HTML page:


As you can see, I am getting some kind of string-typed output on the
page, so I've got *some* value. It casts to boolean true, but I
haven't been able to successfully compare it to 0.

If there's a better way to do this overall, I would also welcome
suggestions.  I am not especially attached to solving this using
string comparisons but the form.data hash seems to force me down this
road.

Thank you
Elizabeth

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Absolute URL vs Relative URL, or ~ ?

[ekellner]

On Tue, Sep 16, 2008 at 10:02 AM, est <[EMAIL PROTECTED]> wrote:

>
> Today, my boss came to me and asked: "Please move our django site from
> http://xxx.com/ to http://xxx.com/v2/";
>
> It's killing me. Just image how huge mount of HTML source code to
> modify.


> I STRONGLY suggest django implement a 'project url' like asp.net, say
>
>  media="screen" />
>
> where ~ always points to the current django project's top URL path.
>

I think you can use the django.root setting in mod_python to solve this
problem.  You can use it to strip the /v2 out of the base of the url.

Take a look at the docs for it:
http://docs.djangoproject.com/en/dev/howto/deployment/modpython/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: utf-8 text in models with coding: keyword

[ekellner]

2008/9/11 Jarek Zgoda <[EMAIL PROTECTED]>

>
> Coding cookie has nothing to do with bytestring literals decoding,
> it's only for unicode literals. If you try to coerce bytestring with
> unicode, decoding will be done using default system encoding, if
> encoding is not specified explicitly.
>

Indeed, that's why changing the python default encoding (no matter how
'dangerous' this is supposed to be) is the only technique that worked.

Please correct me if I am wrong then, but if the coding is supposed to be
specified explicitly, it seems like django is failing to do that in its
handling of __str__.  If my model is returning utf-8 data in its __unicode__
function, that shouldn't cause any problems.  That's the point of
__unicode__.


>
> Just do not use bytestrings to represent textual data. Soon (with
> Python 3) it will be considered bad habit.
>

This means changing every "string" into u"string", right?  This is where I
thought that the coding: cookie was supposed to fix things; you tell python
that your bytestring is in utf-8 so you don't have to label every single
string in your code individually.  Forcing each expression into a specific
type seems very un-pythonic.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: DateTimeFields not showing up in Admin page

[ekellner]

On Wed, Sep 10, 2008 at 5:04 PM, Guillermo
<[EMAIL PROTECTED]>wrote:

> Hi Steve,
>
> Actually I only wanted to have them displayed in the Admin interface
> somehow but in a way that the user can't modify them. A sort of meta
> information to the entry.
>
> I'm only getting my feet wet with Django, so I'm basically
> experimenting. I'm sure there's a way of doing this elegantly.
>

There are a couple patches on Django snippets for this:

http://www.djangosnippets.org/snippets/937/
http://www.djangosnippets.org/snippets/1008/

The first one I believe works for simple-valued fields, and I derived the
second one from that for Foreign Keys.

Elisabeth

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: ProgrammingError at /admin/, date/time field value out of range

[ekellner]

On Fri, Sep 5, 2008 at 1:41 AM, Benedict Verheyen <
[EMAIL PROTECTED]> wrote:

>
> Because the datestyle in the sql statement is passes as Ymd, i tried to
> set

the datestyle in the postgres.conf file als datestyle = 'iso, ymd' and

datestyle = 'sql, us' but they all resulted in the same error.


Does postgres cache the settings into a database table?  Is there some kind
of flush command?  I am surprised that this didn't work.  This should have
been the thing that you needed to do to fix it.  Maybe there's a bug in
postgres (seems unlikely), or you've done something wrong.  I would still
work on this front, because this fix is going to be far, far easier to
implement and maintain than the alternatives.

Is there anyway i can force Django to present dates to the database backend
> as
> dmY instead of Ymd. Setting DATE_FORMAT and DATETIME_FORMAT doesn't seem to
> have an effect on this.
>

I suspect not, but you can dive into the django code to check.

You might be able to hook into the database connection routines, and do a
SET DATESTYLE on each connection.  You probably can get away with doing this
in your application code on each connection, and avoid making changes to the
Django source; although you do have to then mind django's connection
management a bit.  It's not efficient, it's not the right way to do it, but
for testing it could work.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: ProgrammingError at /admin/, date/time field value out of range

[ekellner]

>
>
> When i use wrong dates in a query and execute that directly on the
> database,
> then i get the same error message.
> Judging from the error message, it seems as if the date is in a different
> format than expected by the database.
>

The expected date format is a per-connection level setting. (Called
"DATESTYLE" in postgresql).  There is also a default format if the
connection doesn't specify.

I strongly suspect that this mismatch between formats is actually happening
between the database and the python postgresql driver, and does not involve
django.

You should be able to test this my executing a "SHOW DATESTYLE" using
django's db connection, and also in the working client, and comparing.
 Another third thing is to open a python shell, create a connection, and
execute the sql there and see if that works.

I don't have a postgres database currently so I can't be certain about this,
but that's where I would start investigating.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Determine if model item is subclassed

[ekellner]

On Tue, Sep 2, 2008 at 1:27 PM, gauteh <[EMAIL PROTECTED]> wrote:

is there a different way to accomplish what im trying to do? or do i
> need to check in my view function for which subclass that exists:
> try:
>n = items.newsitem
> except DoesNotExist:
>pass
> try:
>l = items.linkitem
> except DoesNotExist:
>   pass
>

There was a thread on this list from a couple weeks ago that was relevant to
your question:
http://groups.google.com/group/django-users/browse_thread/thread/52f72cffebb705e/b76c9d8c89a5574f?lnk=gst&q=vietnam#b76c9d8c89a5574f

Your above code is going to hit the database n times, once for each
subclass.  If you put a flag on the BasicItem object that indicates which
type it is, you can get that down to one lookup.  Once you have all the
correctly typed objects in memory, you can write a single tag that displays
any type. I think that type-checking like this doesn't belong in templates.

You might want to consider making the parent BasicItem class abstract, and
abandoning the BasicItem.manager.all() call.   You could replace that with
an index that you manage yourself, or write a custom query.  Since you have
no stand-alone BasicItem types, you don't need model inheritence that splits
an object's data across multiple tables.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Missing traceback for 500 errors

[ekellner]

Thanks, indeed that is all I was missing.  I somehow managed to miss the
setting documentation and instead found some information on the 500 view.

On Tue, Jul 1, 2008 at 3:11 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:

> On Tue, Jul 1, 2008 at 8:15 AM, Elizabeth Kellner <[EMAIL PROTECTED]>
> wrote:
>
>>
>> The full python traceback is missing from my apache logs.  In fact,
>> I've just seen that the only notification of a 500 error is in
>> access_log and the browser.  Can anyone suggest any place to look to
>> see why this is the case?
>>
>> Here is the python view that I am using to test...
>> def view500(request):
>>"Throws a server 500 error for testing"
>>
>>msg = "Test 500 error.  This is not a real malfunction"
>>logging.error(msg)
>>raise MyRequestException(msg)
>>
>> My apache error_log says...
>> [Tue Jul 01 14:01:33 2008] [notice] Apache/2.2.8 (Unix) mod_ssl/2.2.8
>> OpenSSL/0.9.7l mod_python/3.3.1 Python/2.5.1 configured -- resuming
>> normal operations
>> licenseserver: [2008-07-01 07:01:35,084 10.10.20.38 iAt9asypuEk root
>> ERROR] Test 500 error.  This is not a real malfunction
>>
>> I receive my rendered 500.html template in the browser.
>>
>> (One potentially funky thing I must mention is that I am using the
>> drlog middleware (http://www.fairviewcomputing.com/blog/2008/03/05/
>> django-request-logging/),
>> but I tried commenting it out from my
>> MIDDLEWARE_CLASSES, and the problem persists.  The log message changes
>> format, but still no traceback.  I doubt this is the cause.)
>>
>> I'm running Django trunk, revision 7629, on Mac OS X Leopard.
>
>
> I think this is normal.  The only time I recall seeing tracebacks in the
> Apache logs is for errors that Django didn't successfully "handle", that is
> things like a missing 500.html template -- stuff that causes an exception to
> get thrown out to mod_python/Apache and causes its error handling to get
> involved.  Django's method for 'recording' the traceback is to send it in an
> email to the IDs listed in ADMINS in settings.py,.
>
> Karen
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Model inheritance and primary keys

[ekellner]

On Tue, Jun 3, 2008 at 2:49 PM, Etienne Robillard
<[EMAIL PROTECTED]> wrote:

> I agree with you, and think this should be better expressed. Perhaps without
> words which refers to abstract C++ concepts like pointers, and using a 
> vocabulary
> more adapted to Python. At least this would be more helpful for understanding 
> whats going
> on there.

Sorry that what I am trying to say is not clear.  I suppose that I am
too close to it.  Let's suppose the simplest example possible:

class Place(models.Model):
# primary key here is called "id"
pass
class Restaurant(Place):
# primary key here is called "place_ptr_id"
pass

Now suppose I do this:

>>> r = Restaurant(pk=1)

This does NOT set r.id = 1.  My first question is, should it?

Second, suppose there already is a place with id=1, and I do the above.

>>> p = Place.objects.create(pk=1)
>>> r = Restaurant(pk=1)
>>> # modify r ...
>>> r.save()

Maybe I've done something wrong already here, it's possible this
already isn't supported.  But this statement will do an UPDATE into
the restaurant table, and an INSERT into the place table.  At the end,
we have

>>> r.pk
2
>>> r.id
2

This may be trying to do something that isn't supported, but
nonetheless getting a totally new key cannot be right.  I think that r
was in an inconsistant state, a state that Django does not support.
Specifically, before we save,

>>> r._get_pk_val( Place._meta)  # returns None
>>> r._get_pk_val( Restaurant._meta)
1

The point I was trying to make in the original message is that this is
already weird, on 2 counts.  First, logically an object only has one
primary key.  It doesn't depend on anything except the object.  If
you're asking for the key into a different table, then that's a
foreign key.

Second, if r.id and r.pk are different, then you have two different
objects! The database rows do not point to each other, and so an
attempt to save the object to the database should not succeed.

I can see two possible ways to fix this, one is to raise an exception
when you try to save the inconsistent objects.  The other is to set
all database primary key columns (primary for this object, not
counting foreign keys) when the object's primary key is set.  I'm
trying to ask which is the right fix.

Elizabeth

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Model inheritance and primary keys

[ekellner]

As I was looking at model inheritance with admin recently, I came
across this issue:
http://code.djangoproject.com/ticket/6755

I'm thinking now that the underlying issue that I'm seeing, and what
the patch in 6755 is fixing, doesn't actually have anything to do with
newforms at all.  I think it has to do with consistancy of primary
keys in derived models.   I don't know if this is a bug, or my own
misuse, but I have a feeling something isn't right here.

Using the Place,Restaurant example (class Place(models.model), and
class Restaurant(Place)), let's consider what exactly a primary key of
a restaurant is.

At the database, both the restaurant and place tables have a primary
key.  By default, the names are place.id and restaurant.place_id_ptr
(I think -- but they aren't the same).  And so, in memory, a
Restaurant object r has a property "pk" which is mapped to
r.place_id_ptr.  Similarly, a place object's property "pk" is mapped
to p.id.

So what exactly does r.pk = 1 do?  It sets r.place_id_ptr.  Is this
wrong?  Shouldn't it also set r.id?  To me, this is one object, with
the same primary key across 2 tables. If it were 2 keys, then one
would be a foreign key.  But it's not, so it's conceptually one key.

Alternatively, this is my own bug if it should be the responsibility
of the user to manage both keys independently.


In any case, this fix is what the patch for 6755 kind of does.  In the
save_base model method, it sets the parent's primary key (r.id) from
the child's (r.place_id_ptr) before saving the parent.  I don't think
in any case this is the right design.  If the parent's primary set is
to be set from the child's it should be set *on assignment* to r.pk,
or r.place_ptr_id, or both, and not *on saving* to the database.

It is more intuitive to me that an assignment to r.pk should set the
primary key in the Restaurant class, as well as the primary key in all
parent classes, as the "pk" property is not a database column -- it
refers to a value of the object that is stored in 2 locations.  What
does the list think?

Elizabeth

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: model inheritance and admin (qs-rf & nf-a)

[ekellner]

> Have you done any experimentation to see how far off working it is in the
> newforms-admin branch...and whether it's any easier to fix there?  I believe
> the plan is to implement this support exclusively in newforms-admin and not
> worry about getting it to work on the old admin.  (Someone changed the
> ticket to specify a version of 'SVN'...which is accurate insofar as the
> problem exists in SVN trunk, but inaccurate in that I don't believe a fix
> will be developed for trunk, only newforms-admin which will get to trunk at
> some point.)

I haven't, because I am wary of using anything other than trunk
because of future maintenence issues.  This particular app will
probably not receive a lot of development effort after the first
release.  If it's on a branch the next time we come back to the app,
it might just be stuck there.

Is newforms-admin any closer to being merged?  This group's archives
says that it's quite stable and has been for some time, but I don't
have the impression that the merge is going to be easy or soon.


> It does seem to me that the doc should mention that Admin doesn't currently
> support model inheritance (care to open a ticket/provide a patch?).

(Done, #7349.  I didn't realize that the web docs were synthesized
from .txt in source)

Elizabeth

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---