Re: Localisation and timezones

[koenb]

Tom,

I  think you can create a custom format file for that (see [1] ).

Koen

[1] : 
https://docs.djangoproject.com/en/1.4/topics/i18n/formatting/#creating-custom-format-files

Op woensdag 10 oktober 2012 12:40:52 UTC+2 schreef Tom Evans het volgende:
>
> Hi all 
>
> If you enable USE_L10N=True, then datetime, date and time formats are 
> all taken from the definition for the current locale. However, none of 
> these formats seem to include the timezone of a non-naive datetime 
> field, which I can add by disabling USE_L10N and defining an 
> appropriate DATETIME_FORMAT. 
>
> Is there any way around this? I can have sane datetime formats, but 
> only if I disable all localisation? 
>
> Cheers 
>
> Tom 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/G5Q3m2FaZJgJ.
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: Server error caused by too many database look-ups

[koenb]

You should use DEBUG=True in your development settings, so you get a proper 
traceback of what is going on. 

As far as I can see, you do have syntax errors in your models.py file (eg 
line 266). You should fix them first.

As a side note, your unicode methods are not all correct, some of them are 
returning bytestrings (this may bite you once you start using non-ascii 
data).

Koen

Op woensdag 2 mei 2012 21:37:30 UTC+2 schreef Jonas Ghyllebert het volgende:
>
> Hi everybody,
>
> I've got a problem while accessing a model in the Django Adminpanel.
> I uploaded the models file, i hope this makes it easier for you to 
> understand my problem.
>
> When I try to add or view a *Region *in the adminpanel, the server 
> usually gives me an 500 server error.
> This is what i get to see:
>  
> Error: Server ErrorThe server encountered an error and could not complete 
> your request.
>
> If the problem persists, please 
> report your 
> problem and mention this error message and the query that caused it.
>
> Now, in the uploaded file you may (or not) have seen that I want to have 
> 25 fields from Zip.
>
> My guess is that Django connects to the database for every listbox it is 
> generating.
> Is there a way to cache the 2000+ zips?
> Or, am I seeing it wrong? What should I do then?
>
> Greetings
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/-6OzpusVZSMJ.
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: Am I overlooking something or is this a bug in ModelForm?

[koenb]

On 31 aug, 17:12, Wim Feijen  wrote:
> Hello,
>
> I am using a form which (simplified) looks like this:
>
> class AdvancedSearchForm(forms.ModelForm):
>     email = forms.CharField(label='Emailadres', required=False)
>
>     class Meta:
>         model = Address
>         fields = [
>             'last_name',
>             'middle_name',
>             'first_name',
>             'email',
>             'street',
>         ]
>
> Because it is a search form, I do not want to validate the e-
> mailfield. However, whenever I add 'email' to get the order of the
> meta fields right, default email validation is used.
>
> I am very surprised at that. Why doesn't it honor my specified email
> field which is a CharField? It should get precedence, right?
>
> Am I overlooking something? Or is this a bug?
>
> For further reading, 
> see:https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#overri...
> and:https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#changi...

I do not think it is a bug. You are using a modelform, so it is normal
that model validation takes place. The fact that that field is not
validated when you leave it out of the fields list is because
otherwise partial forms would not be able to be validated (which was
needed for backwards compatibility).

It would seem more natural to use a normal form for a search form, and
not trigger model validation at all (since the goal of this form is
not creating a model instance)

If you really want to keep using a modelform here, you could reorder
the fields by setting the keyOrder attribute on the fields OrderedDict
in the forms __init__. I still think you would be better off switching
to a "normal" form here though.

K

-- 
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: Reporting Library??

[koenb]

On 11 aug, 03:15, ydjango  wrote:
> I need a reporting library for web based (HTML) reporting with support
> for standard features
> 1) header
> 2) footer
> 3) pagination
> 4) Totals/summary
>
> Reportlab is too low level for my needs and their pro version license
> does not work for me.
>
> Is there any other good python based reporting library.
>
> My only option at this time is JasperReports which is java based which
> would be an overkill.

If you mean creating pdf documents, you may check out pisa [1], which
allows you to use html/css to define your reports. It uses reportlab
to generate them.

Koen

[1] : http://www.xhtml2pdf.com/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Many to Many...so many queries

[koenb]

On 18 mrt, 10:12, bruno desthuilliers <bruno.desthuilli...@gmail.com>
wrote:
> On Mar 18, 8:42 am, koenb <koen.bierm...@werk.belgie.be> wrote:
>
> > Take a look at something like django-selectreverse [1] for inspiration
> > on how to reduce your querycount for M2M relations.
>
> > Koen
>
> > [1]http://code.google.com/p/django-selectreverse/
>
> I must be missing the point, but it looks seriously like reinventing
> the wheel ? How is it better than using select_related ???

Select_related only populates forward one-to-many relationships
(foreignkeys).
It does not work for many-to-many relationships or reverse one-to-many
relationships (the XX_set descriptors on the other side of fk's).
You can not load those in one and the same query, but you can load all
those objects in one single query instead of N extra queries.
That is what selectreverse helps you to do. Look at the example on the
introduction page of the project to see what kind of queries I mean.

Koen

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Many to Many...so many queries

[koenb]

Take a look at something like django-selectreverse [1] for inspiration
on how to reduce your querycount for M2M relations.

Koen

[1] http://code.google.com/p/django-selectreverse/



On 17 mrt, 18:55, TheIvIaxx  wrote:
> I made a mistake in my model definitions above.  The Term field on
> Image is a ManyToMany() not ForeignKey().
>
> Anyhow I did look into value_list, however it didn't add much, if any,
> performance gain.  But the select_related did!  That was exactly what
> I needed.  Thanks Bruno for the tip.
>
> On Mar 17, 1:38 am, bruno desthuilliers
>
>  wrote:
> > On Mar 17, 4:24 am, TheIvIaxx  wrote:
>
> > > Hello all, i have a question about a certain query i have.  Here is my
> > > model setup:
>
> > > class Term():
> > >     term = CharField()
>
> > > class Image():
> > >     image = FileField()
> > >     terms = ForeignKey(Term)
>
> > > These have been abbreviated for simiplicity, ut you get the gist of
> > > it.  Anyhow i have to query for a few hundred Image objects, then get
> > > a list of Term objects for each of these.  Really i just need the IDs
> > > of the Terms.  Currently i have my query like this:
>
> > > images = Image.objects.all()
>
> > you can use 'select_related' here - it'll use a join to prefetch
> > related Term objects:
>
> > images = Image.objects.select_related('terms').all()
>
> > > responseImages = []
> > > for i in images:
> > >     terms = [term.id for term in n.terms.all()]
> > >     responseObjects.append({'image': n, 'terms': terms})
>
> > I guess this is not your real code !-)
>
> > I don't know what this 'responseObjects' is - , but if you use Django
> > templates, you just don't need all this above code. Just pass 'images'
> > in the template's context and you'll be fine:
>
> > 
> > {% for image in images %}
> >    
> >       {{ image.title }}
> >      
> >         {% for term in image.terms.all %}
> >             {{ term.id }}
> >         {% endfor %}
> >         
> >    
> > {% endfor %}
> > 
>
> > HTH

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Project optimisation stage: Advice to boost speed of database queries across tables?

[koenb]

On 31 dec 2009, 01:56, Sam Walters  wrote:
> Thanks for the replies.
>
> Yes, there is the option of going to raw MySQL. However the project
> requirements mean i can't use raw SQL. (portability, readability)
> From what i can see using django's db API i have to execute the
> queries 500 times.
> I am very familiar with the query documentation and i know that
> select_related will prevent foward facing foreign keys translating to
> an individual sql queries which hit the db and would slow it down.
>
> Fact is even when i dont use 'select_related' the major performance
> problem occurs with the 'many-to-many' and 'reverse foreign' keys
> (some 75% of the performance penalty for my package method is with
> these) and only 20% can be solved by select_related.
>
> To be specific about how the multiplicities unfold:
>
> search_querySet is a Directory.objects.filter(...
>
> for s in search_querySet:
>         address_info = s.address_set.all() #.select_related(depth=2) -
> yes i can/will put select related here but it really does not help
> that much 20% tops
>         #address_info is usually 2-3 rows from an address table
>         for a in address_info:#.select_related(depth=2):
>             if a.addresstype.adrtype == 'Physical' and
> a.addradmin.addr_enabled == True:
>             #further reduction in the number of rows which we need to
> get values from.
>             related_phone=a.phone_set.all()
>             related_email=s.email_set.all()
>             #phones and emails are a small number of rows 2-3 tops
>
> It is these lines which produce the performance hit.
> I cant see a way of using django's query language to avoid having to
> descend into each of the 500 'directory' objects because of the
> necessity to get all rows from the related tables in phones an emails
> and to inspect the type of 'address' object.
>
> thanks for the ideas. will continue testing and looking for answers
>
> -Sam
>
> On Thu, Dec 31, 2009 at 2:41 AM, Nick Arnett  wrote:
>
> > On Wed, Dec 30, 2009 at 7:15 AM, Adam Playford 
> > wrote:
>
> >> I'm not an expert on this, but a few thoughts.
>
> >> First, if I'm reading your message right, it sounds like your problem
> >> probably isn't with the query, but with how many times you're running
> >> it.
>
> > I'll echo that... the problem is not the database - the queries are as good
> > as it gets.  The problem is running them repeatedly.
>
> > If all else fails, I'd replace those queries that execute 500 times with raw
> > SQL that uses the IN operator to get the required rows.
>
> > E.g.: SELECT `common_addresstype`.`id`, `common_addresstype`.`adrtype` FROM
> > `common_addresstype` WHERE `common_addresstype`.`id` IN (1,6,8,52,173)
>
> > I imagine there's an ORM query that will do the same thing, but I know MySQL
> > far better than I know Django.
>
> > Nick
>

You can take a look at apps like django-selectreverse [1] or django-
batch-select [2] for some ideas to make this kind of optimisations
easier.

Koen

[1] http://code.google.com/p/django-selectreverse/
[2] http://github.com/lilspikey/django-batch-select
-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: ManyToMany lookups

[koenb]

On 20 okt, 21:19, r_f_d  wrote:
> Why not do this:
>
> for p in products.objects.all():
>     for c in p.categories.all():
>          print p,' - ', c
>
> -richard
>
> On Oct 20, 7:57 am, Михаил Лукин  wrote:
>

This will obviously leave you with a lot of queries. Take a look at eg
django-selectreverse [1] for some help reducing your querycount for
this type of nested lists.

Koen

[1]: http://code.google.com/p/django-selectreverse/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

announcing django-selectreverse

[koenb]

It is quite common to have templates with lists traversing reverse
foreignkey relationships or m2m relationships, which generate a lot of
queries, for example:

{% for building in buildinglist %}
  Building: {{ building }}
  Appartments:
  
{% for appartment in building.appartment_set.all %}
  {{ appartment.number }}
{% endfor %}
  
{% endfor %}

to reduce the querycount you can use some tricks to fetch the child
items for each parent in a separate query.

I abstracted these tricks into a custom manager and created a project
for it, called django-selectreverse.

It allows you to reduce the querycount in the example above to only
two queries, regardless of the number of buildings.

All you need to do is use this custom manager and in your view use it
to prefetch the child elements like this:
buildinglist = Building.objects.select_reverse({'appartments':
'appartment_set'})

Want to know more? Check out django-selectreverse at
http://code.google.com/p/django-selectreverse/ .
--~--~-~--~~~---~--~~
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: Global custom tags

[koenb]

On 3 jul, 04:59, diogobaeder  wrote:
> But where do I put the custom template, than? If I load it from an app
> template, I must create it under /templatetags/, and what if I
> want to call it from the base template? /templatetags/?
>
> Thanks!
>
> Diogo
>

I think you are missing something here: there really is no app
namespacing in templatetags: if you try to load a tag library, django
will search the templatetags folders located underneath all installed
apps. If it finds one that matches, it will use that one. This means
that you can use a tag library from app X in any template you use (no
matter where it is located), as long as app X is in the installed
apps. The downside of this is that you need to name your tag libraries
wisely, because tags.py in app X and tags.py in app Y will conflict.

Koen
--~--~-~--~~~---~--~~
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: Django form: Allow user to insert a date in dd-mm-yyyy format and then convert in yyyy-mm-dd

[koenb]

On 18 mrt, 13:01, MarcoS  wrote:
> Hi Adi, thanks for your reply!
>
> I had just tried the DateField.input_formats, but the problem was that
> I'm using the date admin widgets.
> If I specify input_formats like: '%d.%m.%y', I can't use the admin
> widgets 'cause it insert the date in the format: '%Y-%m-%d' (how you
> can see in django/contrib/admin/media/js/admin/DateTimeShortcuts.js
> line 239)...
>

Marco,

look at my solution here: 
http://groups.google.be/group/django-users/msg/50eba033580c7536

to use the admin date picker, you need to tell your widget to add the
correct attrs so the last line becomes something like this:

super(DateWidget, self).__init__(format=settings.DATE_OUTPUT_FORMAT,
attrs={'class': 'vDateField'})

good luck,

Koen
--~--~-~--~~~---~--~~
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: DateField with Django

[koenb]

> Does anybody know how to control a form's output format of a stored
> DateField? Unfortunately, different countries use different customs to
> represent dates and I'd like to represent the date in another
> international format (%d-%m-%Y). Any help would be very much
> appreciated!

I use the following combination of formfield and widget:

as formfield:

class DateFormField(forms.DateField):
def __init__(self, input_formats=None, *args, **kwargs):
super(DateFormField, self).__init__(*args, **kwargs)
self.input_formats = input_formats or
settings.DATE_INPUT_FORMATS

def clean(self, value):
super(forms.DateField, self).clean(value)
if value in forms.fields.EMPTY_VALUES:
return None
if isinstance(value, datetime.datetime):
return value.date()
if isinstance(value, datetime.date):
return value
for format in self.input_formats:
try:
y, m, d = time.strptime(value, format)[:3]
if y == 1900:
y = datetime.datetime.now().year
return datetime.date(y, m, d)
except ValueError:
continue
raise forms.util.ValidationError(self.error_messages
['invalid'])

note that I defined the input formats in my settings as

DATE_INPUT_FORMATS = (
'%d/%m/%Y', '%d/%m/%y',  # '25/10/2006', '25/10/06'
'%d/%m', # '25/10'
'%Y-%m-%d',  # '2006-10-25'
)

subclassing clean() allows me to enter dates without a year specified.
If you don't need this you can leave out the clean method definition.


and as widget:

class DateWidget(forms.DateTimeInput):
def __init__(self, attrs={}):
super(DateWidget, self).__init__
(format=settings.DATE_OUTPUT_FORMAT)

where my setting for the output format is:

DATE_OUTPUT_FORMAT = '%d/%m/%Y'

(to be honest my real widget also defines some media to use the jquery
datepicker)

Maybe this helps somebody,

cheers,

Koen
--~--~-~--~~~---~--~~
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: Using BaseInlineFormSet with customized form

[koenb]

On 3 mrt, 14:32, koenb <koen.bierm...@werk.belgie.be> wrote:
> Do you think this is worth a ticket ?

I created ticket #10403 for this.

Koen
--~--~-~--~~~---~--~~
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: Using BaseInlineFormSet with customized form

[koenb]

On 3 mrt, 14:09, Alex Gaynor  wrote:
>
> AFAIK the intention was always to eventually have a metaclass so it looked
> more like model forms, but the usecase wasn't as strong, and no one who
> wanted it ever wrote any code AFAIK
>
> Alex

Thank you Alex,

something like this seems to work:

class InlineFormSetMetaclass(type):
def __new__(cls, name, bases, attrs):
# TODO: add some checking

try:
parents = [b for b in bases if issubclass(b,
InlineFormSet)]
except NameError:
# We are defining InlineFormSet itself.
parents = None
new_class = super(InlineFormSetMetaclass, cls).__new__(cls,
name, bases,
attrs)
if not parents:
return new_class

if 'can_order' not in attrs:
new_class.can_order = False
if 'can_delete' not in attrs:
new_class.can_delete = False
if 'max_num' not in attrs:
new_class.max_num = 0
if 'extra' not in attrs:
new_class.extra = 3
parent = attrs.pop('parent')
model = attrs.get('model')
new_class.fk = (i for i in model._meta.fields if i.name ==
parent).next()

return new_class

class InlineFormSet(forms.models.BaseInlineFormSet):
__metaclass__ = InlineFormSetMetaclass


Do you think this is worth a ticket ?

I guess modelformset needs the same kind of love ?

Koen

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

Using BaseInlineFormSet with customized form

[koenb]

Hi all,

I want to use a inlineformset with a highly customized form (it is
based on a specific metaclass and has a customized __init__ function).

Due to the way the inlineformset_factory function works, if I specify
my form in the form argument, the specific form instantiation does not
seem to work (because a new form class is created based on my form). I
acknowledge that this may be because my metaclass may be lacking and
therefore does not allow subclassing correctly.

In case you are wondering: this is entirely outside of the admin.

I found a way around this in creating my inlineformset as a class
directly off of BaseInlineFormSet like this:

class ReportDaysFormset(BaseInlineFormSet):
form = InlineReportDayForm
model = ReportDay
fk = (i for i in model._meta.fields if i.name == 'report').next()
can_order = False
can_delete = True
max_num = 0
extra = 3

This works well, and looks nice (I don't much like factory functions
BTW) but I wonder if this could be done easier:
1. I have to specify can_order, can_delete etc. that is there are no
default values for these
2. setting the fk attribute this way seems hackish

I think it would be nice to have a 'InlineFormSet' based on
BaseInlineFormSet that would allow to use a declarative syntax to
specify formsets and that
a. specifies defaults for can_order etc
b. allows setting the fk using a string that specifies the fieldname
of the foreign key to the parent

Am I missing the point here completely ?

Does anybody have similar experiences ?

Koen

--~--~-~--~~~---~--~~
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: Date and Times

[koenb]

H René,

This is what I use on all my forms (I use my own modelform subclass to
insert these for date fields, but that is not relevant):

as formfield:

class DateFormField(forms.DateField):
def __init__(self, input_formats=None, *args, **kwargs):
super(DateFormField, self).__init__(*args, **kwargs)
self.input_formats = input_formats or
settings.DATE_INPUT_FORMATS

def clean(self, value):
super(forms.DateField, self).clean(value)
if value in forms.fields.EMPTY_VALUES:
return None
if isinstance(value, datetime.datetime):
return value.date()
if isinstance(value, datetime.date):
return value
for format in self.input_formats:
try:
y, m, d = time.strptime(value, format)[:3]
if y == 1900:
y = datetime.datetime.now().year
return datetime.date(y, m, d)
except ValueError:
continue
raise forms.util.ValidationError(self.error_messages
['invalid'])

and as widget:

# like admin date widget with proper date formatting
class DateWidget(forms.DateTimeInput):
class Media:
js = (settings.ADMIN_MEDIA_PREFIX + "js/calendar.js",
  settings.ADMIN_MEDIA_PREFIX + "js/admin/
DateTimeShortcuts.js")

def __init__(self, attrs={}):
super(DateWidget, self).__init__
(format=settings.DATE_OUTPUT_FORMAT, attrs={'class': 'vDateField',
'size': '10'})

and in settings:

DATE_INPUT_FORMATS = (
'%d/%m/%Y', '%d/%m/%y',  # '25/10/2006', '25/10/06'
'%d/%m', # '25/10'
'%Y-%m-%d',  # '2006-10-25'
)

DATE_OUTPUT_FORMAT = '%d/%m/%Y'

This way the field accepts all my formats (also the format the
calendar widget returns) and the output is rendered the way I want it.
Notice that the custom clean is there because I want to accept dates
like 18/02 without the year and use the current year for those.

Hope this helps somebody, and would appreciate to hear if there are
better ways,

Koen
--~--~-~--~~~---~--~~
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: Optional m2m relationships in Admin

[koenb]

>     def save_model(self, request, obj, form, change):
>         super(GamesAdmin, self).save_model(request, obj, form, change)
>         if not change:
>             #get a tag
>             tag = Tags.objects.get(pk=1)
>             #associate tag with newly created object
>             obj.tag.add(tag)
>

Shouldn't this be obj.tags.add(tag) ? (your m2mfield is called tags
not tag)
--~--~-~--~~~---~--~~
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: #7210 - F() Query Expressions

[koenb]

On 30 jan, 13:46, Russell Keith-Magee  wrote:
> If you are interested in implementing this, I'm happy to give you
> pointers. The first pointer I can suggest is that you will be looking
> at the SQLEvaluator class contained in
> django/db/models/sql/expressions.py. This class traverses the
> expression tree, turning it into raw SQL. The actual expression tree
> is a series of tree.Node objects defined in
> django/db/models/expressions.py.
>
> Also - anything you do here shouldn't be date-specific. Other data
> types - such as strings and GIS types - will require similar
> capabilities. Try to keep that in mind when you are looking to
> potential solutions for the date problem.
>
> > It seems though that the different backends will certainly need
> > different handlings:
>
> Indeed. The Postgres option should be fairly easy to implement - you
> just need to replace leaf nodes on the expression tree that are
> timedeltas with matching "interval X" statements. SQLite style
> expressions will be a little harder.
>
> Yours,
> Russ Magee %-)

I made a first attempt, see ticket #10154.

Idea is to use a specific node (and leaf) for combinations of an
expression with a timedelta.
I put the backend specifics into the relevant Operations classes (for
now only base (= sqlite implementation) and postgres).
sqlite and postgres pass the test.
The dispatching based on 'other' being a timedelta needs refining
though, since this is obviously not generic enough.

Koen


--~--~-~--~~~---~--~~
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: #7210 - F() Query Expressions

[koenb]

>
> As committed, the expressions framework is fairly dumb - it is really
> just a way to do two things:
>  1) Expand Django-style field references into column names (and joins
> if required)
>  2) Turn Python expression trees into SQL expression trees.
>
> This means that the operations that are allowed depend somewhat on the
> database in use. For example, on MySQL, you can perform mod operations
> on floats; under Postgres, you can't.
>
> Constants in expressions are rendered as-is, so whether dates are
> allowed depends on what your database allows. From some quick tests,
> date + integer works on SQLite and MySQL -- or, at least, doesn't
> throw an error. I haven't confirmed that the answer it gives is
> actually meaningful. Postgres complains with an error "operator does
> not exist: timestamp with time zone + integer".
>
> However, I'm certainly interested in entertaining any modification to
> support more interesting expressions - for example, converting the
> expression "F('date') + timedelta(days=3)" into meaningful SQL.
> Patches welcome.

I will have a look at how expressions are implemented (I am aware of
the patches philosophy).

It seems though that the different backends will certainly need
different handlings:

I think

filter(enddate__gt=F('startdate')+timedelta(days=3))

will need to become in SQLITE:

where enddate > date(startdate, "3 days")

and in Postgres:

where enddate > (startdate + interval '3 days')

Koen

--~--~-~--~~~---~--~~
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: #7210 - F() Query Expressions

[koenb]

This is really great! Thanks all for the good work.

Just curious, has there been any work done to make this also work for
dates ?

like in

longevents = Event.objects.filter(enddate__gte=F('startdate')+10)

or something like that ?

Koen

--~--~-~--~~~---~--~~
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: Update: Date formatting between model and form output

[koenb]

On 26 sep, 16:00, Gerard Petersen <[EMAIL PROTECTED]> wrote:
> Getting closer. This works: product.period_start_date.strftime('%d-%m-%Y')
>
> But I definitely do not want this in all view handlers. It should go in the 
> model .. or the modelform.
>
> Thanx again!
>
> Gerard.
>
> Gerard Petersen wrote:
> > Hi all,
>
> > I'm trying to have a formfield filled with a correlctly formatted date 
> > value.
>
> > Validation is already in place. It only accepts "dd-mm-" on submitting 
> > but when it gets the existing value from the model it shows it in the 
> > formfield like "-mm-dd"
>
> > So the sequence is almost complete. But where do I format the value so the 
> > formfield shows the correct formatted value when editing. In the model, the 
> > form or the view method?
>
> > Thanx a lot.
>
> > Gerard.
>
> --
> urls = { 'fun':  'www.zonderbroodje.nl',  'tech':  'www.gp-net.nl'}

Hi Gerard,

the DateTimeInput widget already accepts a format parameter.
What I do is I have a subclass of ModelForm that in its init goes over
the fields and replaces the widget for Datefields with a datetimeinput
with the correct format. I also change the input format their (I
prefer dd/mm/).

something like:

for field in self.fields:
if isinstance(self.fields[field], forms.Datefield):
self.fields[field].input_formats = settings.DATE_INPUT_FORMATS
self.fields[field].widget = forms.DateTimeInput(format =
settings.DATE_OUTPUT_FORMAT)

as you can see, I put the formats in my settings file, but of course
you could just plug them right in here too.

I am not sure this is the best way to do this, but maybe this helps.

Koen
--~--~-~--~~~---~--~~
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: formset issue

[koenb]

Something like this might work I think:

attachment_formset = BookingAttachmentFormSet(prefix = "attachments")
for form in attachment_formset.forms:
form.fields['attachment'].queryset =
Attachment.objects.filter(user=request.user)

Koen

On 2 sep, 13:05, patrickk <[EMAIL PROTECTED]> wrote:
> hmm, if the data won´t be received twice this might be a solution.
> do you have any idea about the syntax?
>
> attachment_formset = BookingAttachmentFormSet(prefix="attachments")
> for form in attachment_formset:
>     ??? how do I set initial_data here ???
>
> thanks,
> patrick
>
> On Sep 1, 3:39 pm, koenb <[EMAIL PROTECTED]> wrote:
>
> > Are you sure the data will be retrieved twice ? I thought those
> > queryset definitions were lazy, so they are only executed when the
> > widgets are rendered.
> > Hmm, I'll try that out some time to check.
>
> > Koen
>
> > On 1 sep, 14:18, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > that seems to be possible. on the other hand, it also seems to be a
> > > strange way to go: instantiating the formset (retrieving all data/
> > > querysets) and then changing the querysets? performance-wise, this is
> > > probably not a good solution. and I doubt that this is a good decision
> > > design-wise ...
>
> > > thanks,
> > > patrick
>
> > > On Sep 1, 1:51 pm, koenb <[EMAIL PROTECTED]> wrote:
>
> > > > I have not tried this, but can't you just in your view instantiate the
> > > > formset and then loop over the forms and set the queryset on your
> > > > field ?
>
> > > > Koen
>
> > > > On 1 sep, 09:24, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > > found a solution: with using threadlocals, it´s possible to define a
> > > > > custom manager which only returns the data assigned to the currently
> > > > > logged-in user. since threadlocals has been considered a "hack"
> > > > > recently by one of the main django-developers (I think it was
> > > > > malcolm), this is probably not the best thing to do though.
>
> > > > > On Aug 31, 4:35 pm, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > > > sorry for being so annoying with this issue, but I´m asking this one
> > > > > > more time.
>
> > > > > > - with using inlineformset_factory, my problem is that limiting the
> > > > > > choices to the currently logged-in user seems impossible. I´ve just
> > > > > > tried to write a custom manger with "use_for_related_fields = True",
> > > > > > but it´s also not possible to limit the basic queryset to the 
> > > > > > current
> > > > > > user.
>
> > > > > > so - before going back to pure forms and re-writing the main part of
> > > > > > my application, I´m just asking this question for the last time ...
>
> > > > > > thanks,
> > > > > > patrick
>
> > > > > > On Aug 27, 9:04 am, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > > > > anyone?
>
> > > > > > > On Aug 26, 12:19 pm, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > > > > > scenario: users are uploading documents (e.g. images, files, 
> > > > > > > > ...).
> > > > > > > > these documents are saved in a model "Attachment" assigned to 
> > > > > > > > the
> > > > > > > > currently logged-in "User". now, every user has the possibility 
> > > > > > > > to
> > > > > > > > attach documents to a blog-entry. these attachments are saved 
> > > > > > > > in a
> > > > > > > > model "BlogEntryAttachment" assigned to a "BlogEntry".
> > > > > > > > the best way to achieve this is probably using formsets. when 
> > > > > > > > writing
> > > > > > > > a BlogEntry, the user has the option to attach his/her 
> > > > > > > > documents to
> > > > > > > > that BlogEntry. to achieve this, I have to limit the choices 
> > > > > > > > (of a
> > > > > > > > select-field) to the currenlty logged-in User.
>
> > > > > > > > questions & notes:
> > > > > > > > ### how can I limit the choices of

Re: formset issue

[koenb]

Are you sure the data will be retrieved twice ? I thought those
queryset definitions were lazy, so they are only executed when the
widgets are rendered.
Hmm, I'll try that out some time to check.

Koen

On 1 sep, 14:18, patrickk <[EMAIL PROTECTED]> wrote:
> that seems to be possible. on the other hand, it also seems to be a
> strange way to go: instantiating the formset (retrieving all data/
> querysets) and then changing the querysets? performance-wise, this is
> probably not a good solution. and I doubt that this is a good decision
> design-wise ...
>
> thanks,
> patrick
>
> On Sep 1, 1:51 pm, koenb <[EMAIL PROTECTED]> wrote:
>
> > I have not tried this, but can't you just in your view instantiate the
> > formset and then loop over the forms and set the queryset on your
> > field ?
>
> > Koen
>
> > On 1 sep, 09:24, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > found a solution: with using threadlocals, it´s possible to define a
> > > custom manager which only returns the data assigned to the currently
> > > logged-in user. since threadlocals has been considered a "hack"
> > > recently by one of the main django-developers (I think it was
> > > malcolm), this is probably not the best thing to do though.
>
> > > On Aug 31, 4:35 pm, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > sorry for being so annoying with this issue, but I´m asking this one
> > > > more time.
>
> > > > - with using inlineformset_factory, my problem is that limiting the
> > > > choices to the currently logged-in user seems impossible. I´ve just
> > > > tried to write a custom manger with "use_for_related_fields = True",
> > > > but it´s also not possible to limit the basic queryset to the current
> > > > user.
>
> > > > so - before going back to pure forms and re-writing the main part of
> > > > my application, I´m just asking this question for the last time ...
>
> > > > thanks,
> > > > patrick
>
> > > > On Aug 27, 9:04 am, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > > anyone?
>
> > > > > On Aug 26, 12:19 pm, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > > > scenario: users are uploading documents (e.g. images, files, ...).
> > > > > > these documents are saved in a model "Attachment" assigned to the
> > > > > > currently logged-in "User". now, every user has the possibility to
> > > > > > attach documents to a blog-entry. these attachments are saved in a
> > > > > > model "BlogEntryAttachment" assigned to a "BlogEntry".
> > > > > > the best way to achieve this is probably using formsets. when 
> > > > > > writing
> > > > > > a BlogEntry, the user has the option to attach his/her documents to
> > > > > > that BlogEntry. to achieve this, I have to limit the choices (of a
> > > > > > select-field) to the currenlty logged-in User.
>
> > > > > > questions & notes:
> > > > > > ### how can I limit the choices of a select-field using formsets?
> > > > > > ### I've tried inlineformset_factory, but there's no argument
> > > > > > "initial". besides that, I´m not sure how to use "initial" for
> > > > > > limiting a queryset ...
> > > > > > ### with using formset_factory on the other hand, I could use a
> > > > > > ModelChoiceField with queryset=Attachment.objects.filter(user=user),
> > > > > > but how do I get the "user" there?
> > > > > > ### Overriding __init__ within BlogEntryAttachmentForm and passing 
> > > > > > the
> > > > > > currently logged-in user seems possible, but then I also have to
> > > > > > override the BaseFormSets __init__ and _construct_form, which just
> > > > > > seems ugly and far too complicated.
>
> > > > > > MODELS:
>
> > > > > > class Attachment(models.Model):
>
> > > > > >     user = models.ForeignKey('auth.User')
> > > > > >     title = models.CharField('Title', max_length=100, blank=True,
> > > > > > null=True)
> > > > > >     filename = models.CharField('Filename', max_length=100,
> > > > > > blank=True, null=True)
> > > > > >     path = models.CharField('Path', max_length=200, blank=True,
> > > > > > null=True)
> > > > > >     ...
>
> > > > > > class BlogEntryAttachment(models.Model):
>
> > > > > >     blogentry = models.ForeignKey(BlogEntry)
> > > > > >     attachment = models.ForeignKey(Attachment)
> > > > > >     
--~--~-~--~~~---~--~~
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: formset issue

[koenb]

I have not tried this, but can't you just in your view instantiate the
formset and then loop over the forms and set the queryset on your
field ?

Koen

On 1 sep, 09:24, patrickk <[EMAIL PROTECTED]> wrote:
> found a solution: with using threadlocals, it´s possible to define a
> custom manager which only returns the data assigned to the currently
> logged-in user. since threadlocals has been considered a "hack"
> recently by one of the main django-developers (I think it was
> malcolm), this is probably not the best thing to do though.
>
> On Aug 31, 4:35 pm, patrickk <[EMAIL PROTECTED]> wrote:
>
> > sorry for being so annoying with this issue, but I´m asking this one
> > more time.
>
> > - with using inlineformset_factory, my problem is that limiting the
> > choices to the currently logged-in user seems impossible. I´ve just
> > tried to write a custom manger with "use_for_related_fields = True",
> > but it´s also not possible to limit the basic queryset to the current
> > user.
>
> > so - before going back to pure forms and re-writing the main part of
> > my application, I´m just asking this question for the last time ...
>
> > thanks,
> > patrick
>
> > On Aug 27, 9:04 am, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > anyone?
>
> > > On Aug 26, 12:19 pm, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > scenario: users are uploading documents (e.g. images, files, ...).
> > > > these documents are saved in a model "Attachment" assigned to the
> > > > currently logged-in "User". now, every user has the possibility to
> > > > attach documents to a blog-entry. these attachments are saved in a
> > > > model "BlogEntryAttachment" assigned to a "BlogEntry".
> > > > the best way to achieve this is probably using formsets. when writing
> > > > a BlogEntry, the user has the option to attach his/her documents to
> > > > that BlogEntry. to achieve this, I have to limit the choices (of a
> > > > select-field) to the currenlty logged-in User.
>
> > > > questions & notes:
> > > > ### how can I limit the choices of a select-field using formsets?
> > > > ### I've tried inlineformset_factory, but there's no argument
> > > > "initial". besides that, I´m not sure how to use "initial" for
> > > > limiting a queryset ...
> > > > ### with using formset_factory on the other hand, I could use a
> > > > ModelChoiceField with queryset=Attachment.objects.filter(user=user),
> > > > but how do I get the "user" there?
> > > > ### Overriding __init__ within BlogEntryAttachmentForm and passing the
> > > > currently logged-in user seems possible, but then I also have to
> > > > override the BaseFormSets __init__ and _construct_form, which just
> > > > seems ugly and far too complicated.
>
> > > > MODELS:
>
> > > > class Attachment(models.Model):
>
> > > >     user = models.ForeignKey('auth.User')
> > > >     title = models.CharField('Title', max_length=100, blank=True,
> > > > null=True)
> > > >     filename = models.CharField('Filename', max_length=100,
> > > > blank=True, null=True)
> > > >     path = models.CharField('Path', max_length=200, blank=True,
> > > > null=True)
> > > >     ...
>
> > > > class BlogEntryAttachment(models.Model):
>
> > > >     blogentry = models.ForeignKey(BlogEntry)
> > > >     attachment = models.ForeignKey(Attachment)
> > > >     
--~--~-~--~~~---~--~~
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: How to create a Generic Show View ?

[koenb]

Hi Mario,

I do not think that is possible with the builtin generic views.

I have created my own set of 'generic' views, one of which is also an
object_display.
You pass it a form definition (based on my displaymodelform class),
which gets instantiated with the display_only=True parameter.
Something like this (I left out some stuff to make it more readable, I
put in a lot of personal extras in there).

def object_display(request, Model=None, object=None, object_id=None,
Form=None, extra_context={}, template="crud/display.html"):
"Display single object"
if not Model:
raise ImproperlyConfigured, 'object_display requires a Model'
if not object:
object = get_object_or_404(Model, pk=object_id)
ec = {'object': object}
if Form:
form = Form(instance=object, display_only = True)
ec['form'] = form
ec.update(extra_context)
return render_to_response(template, ec, RequestContext(request))

You also need a template that has {{ form }} in a table definition
(you can leave out the  tags).

To call it, I always use wrapper functions in views.py, because I find
that a lot more readable (and often I need to define a lot of extra
context).

Koen

On 27 aug, 18:17, "Mario Hozano" <[EMAIL PROTECTED]> wrote:
> Hi Koen,
>
> I think your code snippet will work fine in my application too. But, how
> instantiate the DisplayModelForm directly in my urls.py showed below?
>
> (r'^core/user/show/(?P\d+)/$', 'object_detail',
> dict(queryset=User.objects.all(),
>
> template_name="baseshow.html",
>
> extra_context={'model_entity':'user'}))
>
> Should I use the 'django.views.generic.create_update.create_object' view? I
> want only to use the urls.py without write in views.py to instantiate the
> form.
>
> Is it possible?
>
> Thanks.
> Mario Hozano.
>
>
>
> On Wed, Aug 27, 2008 at 3:34 AM, koenb <[EMAIL PROTECTED]> wrote:
>
> > Hi Mario,
>
> > a few months ago I posted a snippet on djangosnippets [1] that kind of
> > does something like this: it takes a form (can be the same one you use
> > for editing) and displays it as read-only. The disadvantage is it uses
> > the entire form machinery just to display some values, which is a lot
> > of overhead, the advantage is I have quick and dirty display of data
> > without much extra work (I have my own generic view wrapped around
> > this).
> > It needs a lot of improvement, but it works ok for me for now.
>
> > Koen
>
> > [1]:http://www.djangosnippets.org/snippets/758/
>
> > On 26 aug, 20:00, Mario Hozano <[EMAIL PROTECTED]> wrote:
> > > Hi People.
>
> > > I am new in Django and I am using the django support to create generic
> > > views (CRUD) in my app. To handle Create and Show actions, i have
> > > written 2 main pages with the code snippets described below.
>
> > > baseform.html
> > >         {% for field in form %}
> > >             {{ field.label_tag }}{% if field.field.required %}*{%
> > endif
> > > %}
> > >             {{ field }}
> > >             {% if field.help_text %}{{ field.help_text }}{%
> > endif %}
> > >             {% if field.errors %}{{ field.errors
> > }} > > dd>{% endif %}
> > >         {% endfor %}
>
> > > baseshow.html.
> > >         {% for key, value in object.as_dict.items %}
> > >             {{ key.capitalize }}
> > >             {{ value }}
> > >         {% endfor %}
>
> > > These pages are called directly from my urls.py that uses the Generic
> > > views supported by django. In this sense, the baseform.html can be
> > > used by all model classes, because the ModelForm handles the
> > > presentation of each model attribute (excluding id) transparently.
>
> > > In baseshow.html I need to show the same attributes of a given model
> > > class, as done in baseform.html. In this case, the attributes
> > > (excluding id) must be presented in a read-only mode, with html labels
> > > instead of input widgets. To do it, i've implemented a "as_dict"
> > > method in each model class. This method only returns the
> > > "self.__dict__" attribute of the model classes, hence, the private
> > > attributes cannot be acessed from templates.
>
> > > The solution presented works, but it is ugly, because the id attribute
> > > must be verified on template and it needs to adjust the model class to
> > > work fine.
>
> > > Does Django offer another way to present the model attributes in a
> > > Show view? Is it possible to use a ModelForm class to sho

Re: how to locate the OS currently logged in user??

[koenb]

Did you look at the information attached to ticket 689 [1] ?

This is about using the credentials provided by the webserver. Typical
use case is having apache authenticate the user (eg via mod_ntlm,
mod_auth_sspi or another authentication system), pass the username
into the django app and use this info in django to authenticate (and
authorise) the user.

I am not sure this is what you are looking for, because I did not
quite understand your explanations. Just giving you the pointer.

Koen

[1]: http://code.djangoproject.com/ticket/689


--~--~-~--~~~---~--~~
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: How to create a Generic Show View ?

[koenb]

Hi Mario,

a few months ago I posted a snippet on djangosnippets [1] that kind of
does something like this: it takes a form (can be the same one you use
for editing) and displays it as read-only. The disadvantage is it uses
the entire form machinery just to display some values, which is a lot
of overhead, the advantage is I have quick and dirty display of data
without much extra work (I have my own generic view wrapped around
this).
It needs a lot of improvement, but it works ok for me for now.

Koen

[1]: http://www.djangosnippets.org/snippets/758/

On 26 aug, 20:00, Mario Hozano <[EMAIL PROTECTED]> wrote:
> Hi People.
>
> I am new in Django and I am using the django support to create generic
> views (CRUD) in my app. To handle Create and Show actions, i have
> written 2 main pages with the code snippets described below.
>
> baseform.html
>         {% for field in form %}
>             {{ field.label_tag }}{% if field.field.required %}*{% endif
> %}
>             {{ field }}
>             {% if field.help_text %}{{ field.help_text }}{% endif %}
>             {% if field.errors %}{{ field.errors }} dd>{% endif %}
>         {% endfor %}
>
> baseshow.html.
>         {% for key, value in object.as_dict.items %}
>             {{ key.capitalize }}
>             {{ value }}
>         {% endfor %}
>
> These pages are called directly from my urls.py that uses the Generic
> views supported by django. In this sense, the baseform.html can be
> used by all model classes, because the ModelForm handles the
> presentation of each model attribute (excluding id) transparently.
>
> In baseshow.html I need to show the same attributes of a given model
> class, as done in baseform.html. In this case, the attributes
> (excluding id) must be presented in a read-only mode, with html labels
> instead of input widgets. To do it, i've implemented a "as_dict"
> method in each model class. This method only returns the
> "self.__dict__" attribute of the model classes, hence, the private
> attributes cannot be acessed from templates.
>
> The solution presented works, but it is ugly, because the id attribute
> must be verified on template and it needs to adjust the model class to
> work fine.
>
> Does Django offer another way to present the model attributes in a
> Show view? Is it possible to use a ModelForm class to show the
> attribute values in html labels?
>
> Thanks.
> Mario Hozano
--~--~-~--~~~---~--~~
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: Random NoReverseMatch

[koenb]

I guess you are seeing the bug reported in #6379. You probably have an
import error somewhere, but it is being hidden by the NoReverseMatch
exception that is raised for anything that goes wrong.

Koen

On 25 aug, 16:13, Robin <[EMAIL PROTECTED]> wrote:
> Hello,
>
> i have the same exception and exactly as Julien explained in the dev
> server works fine ... and also works fine with fast_cgi, but I am
> using apache + mod_wsgi and it didn't work with the same problem:
> NoReverseMatch
>
> Has any of you any clue to this error ?
>
> thanks in advance,
>         r
>
> On Aug 16, 8:16 pm, Alberto Piai <[EMAIL PROTECTED]> wrote:
>
> > On Aug 16, 12:01 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > > Hi,
>
> > > It's likely that there is a typo somewhere in your templates, either
> > > you didn't write the view name properly, or you didn't provide the
> > > right parameters.
> > > In the error message, there should be the name of the view. Look up
> > > every occurrence et double check that you haven't made any typo.
>
> > I'm checking everything again. But actually I don't think the
> > problem's there, as everything works fine when run from django's dev
> > server, and now it's been working fine for some hours even on lighttpd
> > +fcgi. When the problem appears again I'll send the traceback.
>
> > Thanks for you help,
>
> > Alberto
--~--~-~--~~~---~--~~
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: partially edit an object

[koenb]

Robin,

I don't know if this is a 'right' way, but I posted a snippet on
djangosnippets with my DisplayModelForm [1].
Basically, it allows you to reuse your form definitions, but turn them
into a "display_only" mode. You can do all fields or just a few.
I use it to display objects to users, with an edit button, which shows
the same object, but this time in the normal ModelForm way. The
advantage is that the layout is more or less the same for the user,
and for me that I can reuse my form definitions and my templates for
both.
I have put this inside a bunch of custom crud views, because I needed
this same pattern for a lot of objects.
Obviously, using the newforms machinery to just display an object is
not exactly efficient, but for me that is not an issue.

Hope this helps,

Koen

[1]: http://www.djangosnippets.org/snippets/758/

On 15 mei, 15:37, Robin Becker <[EMAIL PROTECTED]> wrote:
> I have a colleague who wishes to restrict the editability of fields 
> dynamically.
> I can see how this arises by considering a Person object. The supervisor role
> might be allowed to edit more than the individual concerned.
>
> We looked in vain for an 'easy' way to do this using old forms, newforms,
> generic views etc etc, but eventually started writing our own views to do 
> this.
>
> Sure I could probably start trying to grok the inner horrors of update_object
> and minulators etc etc, but that seems really overkill for such a simple
> requirement.
>
> I expected to be able to pass in a list of fields that were to be left alone 
> or
> something as easy. Is there no easy way to do these simple extensions; if not
> what's the 'right' way to do this in the various contexts?
> --
> Robin Becker
--~--~-~--~~~---~--~~
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: generic foreignkey and auditTrail

[koenb]

Ok,

just found #5826 which seems to solve my problem. Thanks, kgoudeaux!


On 14 mei, 16:32, koenb <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I was trying to adapt AuditTrail [1] to also automatically add generic
> foreignkey attributes.
>
> The audittrail app now copies all the fields to the audit model, which
> means the contenttype and objectid are copied perfectly, but I would
> like to access the referenced object directly from the audit model (as
> I can on the original model).
> I am having trouble identifying the attributes from the original model
> that represent a generic foreignkey. Whatever I try, I get
> 'AttributeError: object must be accessed via instance'. e.g.
> type(MyModel.object) does not work but raises the error.
>
> Anybody know how get to these generic foreignkeys ?
>
> [1]:http://code.djangoproject.com/wiki/AuditTrail
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

generic foreignkey and auditTrail

[koenb]

Hi all,

I was trying to adapt AuditTrail [1] to also automatically add generic
foreignkey attributes.

The audittrail app now copies all the fields to the audit model, which
means the contenttype and objectid are copied perfectly, but I would
like to access the referenced object directly from the audit model (as
I can on the original model).
I am having trouble identifying the attributes from the original model
that represent a generic foreignkey. Whatever I try, I get
'AttributeError: object must be accessed via instance'. e.g.
type(MyModel.object) does not work but raises the error.

Anybody know how get to these generic foreignkeys ?


[1]: http://code.djangoproject.com/wiki/AuditTrail
--~--~-~--~~~---~--~~
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: Row-level permissions, recommendations?

[koenb]

Why would you want to do this in admin ? Admin is for ... hmm admins.

If you want your users to change their info: make your own view (very
easy with modelforms) and add the permission check in your view (this
really isn't difficult at all).

Koen

On 6 mei, 15:50, Rodrigo Culagovski <[EMAIL PROTECTED]> wrote:
> What's the state of the art for row-level permissions in Django?
> I'm working on an application where I need to allow users to edit
> their own personal info but nobody else's. What app, hack, patch or
> branch should I use in order to be able to do this via the admin site?
>
> Thanks,
>
> Rodrigo
--~--~-~--~~~---~--~~
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: generic delete_object issue on Firefox (redirect bug)

[koenb]

Sorry;

forgot to add, you will need to wrap the generic view in a custom
wrapper view for that.



On 28 apr, 22:42, koenb <[EMAIL PROTECTED]> wrote:
> The problem is FF does not like it if you do not consume the POST
> data.
> Just add the line
> request.POST
> somewhere in your view before redirecting.
>
> Koen
>
> On 28 apr, 17:33, yml <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> > I noticed a very strange behavior with the generic view called :
> > "delete_object". The symptom is the following :
> >   * Firefox return an error message
> > ---8<---
> > The connection was reset
>
> > The connection to the server was reset while the page was loading.
>
> > *   The site could be temporarily unavailable or too busy. Try
> > again in a few
> >   moments.
>
> > *   If you are unable to load any pages, check your computer's
> > network
> >   connection.
>
> > *   If your computer or network is protected by a firewall or
> > proxy, make sure
> >   that Firefox is permitted to access the Web.
> > --->8---
> > It seems that the bug is in Firefox code. The same code is working
> > fine on IE 6.0 and Opéra, I am testing this on windows.
>
> > My code look like this (extracted form urls.py):
> > ---8<---
> >  url(r'^delete/(?P[-\w]+)/$', delete_object,
> > {"model":Survey,
> >  "post_delete_redirect": "/survey/editable/",
> >  "template_object_name":"survey",
> >  "login_required": True,
> >  'extra_context': {'title': _('Delete survey')}
> > },
> > name='survey-delete'),
> > --->8---
> > It would be nice if someone could help me with a workaround or a
> > solution.
>
> > Should I report issues in the django bug tracker ?
> > Thank you for your help.
> > --yml
--~--~-~--~~~---~--~~
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: generic delete_object issue on Firefox (redirect bug)

[koenb]

The problem is FF does not like it if you do not consume the POST
data.
Just add the line
request.POST
somewhere in your view before redirecting.

Koen

On 28 apr, 17:33, yml <[EMAIL PROTECTED]> wrote:
> Hello,
> I noticed a very strange behavior with the generic view called :
> "delete_object". The symptom is the following :
>   * Firefox return an error message
> ---8<---
> The connection was reset
>
> The connection to the server was reset while the page was loading.
>
> *   The site could be temporarily unavailable or too busy. Try
> again in a few
>   moments.
>
> *   If you are unable to load any pages, check your computer's
> network
>   connection.
>
> *   If your computer or network is protected by a firewall or
> proxy, make sure
>   that Firefox is permitted to access the Web.
> --->8---
> It seems that the bug is in Firefox code. The same code is working
> fine on IE 6.0 and Opéra, I am testing this on windows.
>
> My code look like this (extracted form urls.py):
> ---8<---
>  url(r'^delete/(?P[-\w]+)/$', delete_object,
> {"model":Survey,
>  "post_delete_redirect": "/survey/editable/",
>  "template_object_name":"survey",
>  "login_required": True,
>  'extra_context': {'title': _('Delete survey')}
> },
> name='survey-delete'),
> --->8---
> It would be nice if someone could help me with a workaround or a
> solution.
>
> Should I report issues in the django bug tracker ?
> Thank you for your help.
> --yml
--~--~-~--~~~---~--~~
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: serving static content on Windows

[koenb]

The error message says it all: it is looking for
testporject.polls.views.django.views.static. Notice the first part. It
means your view function is taken from within testproject.polls.views
(which is probably on top in your patterns declaration).
You should take this declaration out of there and add it seperately,
something like this:

urlpatterns = patterns('testproject.polls.views',

# your patterns here
)

urlpatterns += patterns('',...

# the static view here

)

Koen

On 16 apr, 23:43, "Andre Meyer" <[EMAIL PROTECTED]> wrote:
> hi all
>
> i am new to Django and trying to figure out a few things. so far, everything
> looks very nice.
>
> but now, i am stuck at something very simple: i cannot manage to serve
> static content (images, css, dojo, ...) from Django itself. i have done what
> is described athttp://www.djangoproject.com/documentation/static_files/and
> here is what i get as a response when trying to access some image file from
> the appropriate location.
>
> in urls.py:
> *(r'^site_media/(?P.*)$', 'django.views.static.serve',
> {'document_root': 'E:\\projects\\django\\testproject\\media',
> 'show_indexes': True}),
> *http://localhost:8000/site_media/django.gif
> ViewDoesNotExist at /site_media/django.gif Could not import
> testproject.polls.views.django.views.static. Error was: No module named
> django.views.static Request Method: GET  Request 
> URL:http://localhost:8000/site_media/django.gif Exception Type:
> ViewDoesNotExist  Exception Value: Could not import
> testproject.polls.views.django.views.static. Error was: No module named
> django.views.static  Exception Location:
> C:\Python25\Lib\site-packages\django\core\urlresolvers.py
> in _get_callback, line 127
>
> what is wrong with *django.views.static*? are modifications necessary to
> settings.py? i have tried various path syntaxes, but none worked.
>
> please, let me know what is going on
> thanks a lot for your help
> André
--~--~-~--~~~---~--~~
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: Read-only connection to database. How to?

[koenb]

You could take a look at the multidb branch (specifically check out
ticket #4747). It is a bit behind on trunk, but the basics should
work. It allows you to define multiple connections, so you should be
able to connect to the same db using different users.

Koen

On 5 feb, 23:47, Julien <[EMAIL PROTECTED]> wrote:
> Thanks guys for the suggestions.
> However, what I'd like to have is that the site runs as per usual with
> a root user (with all priviledges), and that only one particular apps
> runs with a read-only user. Do I have to create a new connection
> object within my app code to override Django's, is it possible to
> ovveride the parameter via a setting file?
>
> In PHP, since you create a connection object yourself, you can select
> which user (and also, which database, host, etc.) to execute a
> particular request. It would be great to make it easy in Django to
> allow that sort of flexibility, at least for custom made hard-coded
> SQL queries.
>
> On Feb 4, 8:15 pm, David Reynolds <[EMAIL PROTECTED]> wrote:
>
> > On 4 Feb 2008, at 1:59 am, Julien wrote:
>
> > > I totally understand what you suggest, having a RO user at the
> > > database (in this case MySQL) level.
> > > But I am fairly new to Django and Python, and I am unsure how to
> > > implement that dual-setting option.
>
> > In the devlopment server you can do
>
> > ./manage.py runserver --settings=yoursite.readonlysettings # for the
> > display side of the site
>
> > and
>
> > ./manage.py runserver # for the admin side of the site
>
> > When you deploy the site you can set up which settings file is used too.
>
> > --
> > David Reynolds
> > [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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: form for display, not edit

[koenb]

I also have something similar: I created a bunch of display widgets
(displaytextinput, displaytextarea, displayselect,
displayselectmultiple etc.), which override the render method of their
parents and created a subclass of forms.ModelForm for this, which has
a display_only argument on the __init__. If that argument is made
True, I replace the widgets on the fields with my custom ones. Pretty
ugly, but works ok for now. In my case, I wanted all elements
display_only or editable, but off course you could fine-tune this.
Notice I am not using the form_for_model stuff anymore, since it will
be deprecated soon.

Koen

--~--~-~--~~~---~--~~
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: Very Easy Question

[koenb]

Especially take note of the hint to use junction.exe [1]. It allows
you to use kind of like symlinks on windows. Especially interesting if
you use different versions and branches.

Koen

[1] http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx

--~--~-~--~~~---~--~~
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: QuerySet.count() inaccurate across ForeignKey relationships

[koenb]

First things first: I would either define a separate Group object
here, or use a many2manyfield if you don't need to know the group
numbers.

Second thing: why use the assembly object if you want to count items ?
You are thinking to much in SQL instead of ORM.
If you say Assembly.objects.count(), I would think you want to count
assembly objects, which should yield 2 no matter what extra stuff you
pull in using select_related(). For the ORM side of things,
select_related just prepopulates some related data, no more, no less
(which is of no use in combination with count).
In that view, it would be better if the filter would automatically use
distinct here and also return 2, since you are still only counting
assembly objects. If you do the same using a many2manyfield, the
result is correct as far as I can tell.
If you want to count items, I would use
Item.objects.filter(whatever_filter).count().

Koen





--~--~-~--~~~---~--~~
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: Markdown problem

[koenb]

Alexander,

A few weeks ago I came across the same issue (I filed ticket #5663).

The good thing is, making your own replacement filter to bypass the
problem is easy.

On the other hand, Malcolm closed the ticket today as wontfix, stating
it is a bug in markdown.
Though that may be true, I do not understand why the markdown filter
in SVN is converting text to bytestrings first if the markdown module
understands unicode (or maybe it didn't before ?).

Koen


--~--~-~--~~~---~--~~
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: multiple database support: oracle backend

[koenb]

In the latest patches for multi-db the QuerySet that is returned is no
longer fixed, but varies with the model's manager. That should fix
that problem for now.

Koen

On 17 okt, 09:03, Ian <[EMAIL PROTECTED]> wrote:
> I don't know anything about the multi-db branch, but I imagine that
> whatever QuerySet does to get the correct connection should work in
> OracleQuerySet as well.
>
> Note the mere existence of OracleQuerySet will still be problematic in
> multi-db environments that mix Oracle databases with non-Oracle
> databases, since OracleQuerySet replaces QuerySet entirely when Oracle
> is used.  However, OracleQuerySet is a hack that will be going away
> after the QuerySet refactor, which solves both problems in the long
> run.
>
> Ian


--~--~-~--~~~---~--~~
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: Multiple Database Support

[koenb]

Hi Mark,

You can find some newer work at ticket #4747. The patches there are
some work in progress trying to bring multi-db back in line with
trunk.
A lot has changed in trunk in the last year, so I think it is worth
trying those out instead of the old branch. Off course there are still
a lot of improvements to be made, but it is a start.

Koen

On 17 okt, 02:23, markg <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I need to support multiple database connections in our Django
> application.
> One option being considered is to use the multi-db branch 
> athttp://code.djangoproject.com/svn/django/branches/multiple-db-support
> which is already in alpha release.
>
> However by examining the code, it seems the development on this branch
> has stalled. Does anyone know the state of this branch and the release
> plan? Is there any other option available?
>
> Thanks a lot,
> mark


--~--~-~--~~~---~--~~
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: multiple database support: oracle backend

[koenb]

Sorry Carlos,

those patches are far from complete, and I don't use Oracle myself.

For the moment the backends in the patches use the following to get
the connection:

connection = self.model._default_manager.db.connection

Removing the import and putting in that line should do the trick.

There is plenty more wrong (certainly with that 6110 patch, the 6453
one is a little better), but I haven't had the time to work on it
further.

Koen

> The problem seems to be in django/db/backends/oracle/base.py on line
> 92:
>
>   from django.db import connection
>
> which is later used to get the cursor.  This seems to bypass the use
> of the database settings in OTHER_DATABASES.  I would expect to use
> connections from django.db rather than connection:
>
>   # Create a manager for named connections
>   connections = LazyConnectionManager()
>
>   # Backwards compatibility: establish the default connection and set
> the
>   # default connection properties at module level, using the lazy
> proxy so that
>   # each thread may have a different default connection, if so
> configured
>   connection_info = LocalizingProxy('connection_info', _local,
> lambda: connections[_default])
>   connection = LocalizingProxy('connection', _local,
>lambda:
> connections[_default].connection)
>
> But I don't see how to get the named connection in oracle/base.py.
>
> If that is clear, I would appreciate any suggestions.
>
> Carlos Hanson


--~--~-~--~~~---~--~~
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: problems with i18n

[koenb]

Hi Heba,

I just tried your project with django trunk r5881: I put everything in
a folder, modified the settings to use sqlite3, created a db, did
manage.py syncdb.
Then I started the development server, looked at 127.0.0.1:8000 and it
seems to work just fine.

What django version are you using ?

Koen


--~--~-~--~~~---~--~~
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: help serving static files (css, images, pdf, js)

[koenb]

There already is a ticket: #4783. Just needs volunteers to do the
writing...

Koen

On 3 aug, 10:41, james_027 <[EMAIL PROTECTED]> wrote:
> hi,
>
> On Aug 3, 4:32 pm, koenb <[EMAIL PROTECTED]> wrote:
>
> > My guess is you are interfering with your admin_media (look at the
> > admin_media_prefix setting).
> > Try using something like r'^sitemedia/... and src="/sitemedia/...".
>
> Thanks koen, that did it. I think it could be nice if it was mention
> on the documentation.
>
> cheers,
> james


--~--~-~--~~~---~--~~
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: help serving static files (css, images, pdf, js)

[koenb]

My guess is you are interfering with your admin_media (look at the
admin_media_prefix setting).
Try using something like r'^sitemedia/... and src="/sitemedia/...".

Koen

On 3 aug, 09:16, james_027 <[EMAIL PROTECTED]> wrote:
> hi,
>
> I already did the
>
> (r'^media/(?P.*)$', 'django.views.static.serve',
> {'document_root':'d:/private/james/documents/django/ksk/media'}),
>
> in my urls.py
>
> and in my template i have something like this
>
> 
>
> but why is it the image still don't appear?
>
> Thanks
> james


--~--~-~--~~~---~--~~
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: i18n on win 32 : make_message.py doesn't find anything to translate

[koenb]

That fix seems to work ok for me now.

Thanks Ramiro,

Koen



--~--~-~--~~~---~--~~
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: i18n on win 32 : make_message.py doesn't find anything to translate

[koenb]

Check ticket 4899. It is the newline thing. The extra chr(13) under
Windows breaks the fix from the ticket.

Koen


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

utf-8 and legacy databases

[koenb]

Do I understand correctly that with the unicode branch, databases are
supposed to be providing and accepting utf-8 data ? This assumption is
ok for self-constructed databases, but I am interacting with a legacy
database that is in iso-8859-1 and I can't change that.
Is there a setting somewhere to indicate what character set the
database is using ?

Koen


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