Non-conventional use of django templates.
I'm writing an application which is kind of event handling app, and
the important functionality is sending emails. User can create his own
email template, and when an event occurs the email is built using this
template and sent. An event is nothing but a python dictionary with
some values. As you may guess, I want to give the user a possibility
to create an e-mail template which would use the variables from this
dictionary (context).
In fact, I would like to do something as simple as this:
#Create email body
email_body = render_to_string(emailtemplate.emailbody, event.context)
# Then send email...
So when the user defines the email body template he could make it like
"Hey {{receipent_name}}, event {{eventid}} has occured for device
{{device_name}}". You get the idea: my application not only uses
django template language internally to output html, but I must also
offer a template language as a functionality for the users. I don't
want to reinvent the wheel and write my own template language for
handling all the variable placeholders, filters etc. But if I use
django template engine to do this, the following issues arise:
1) I don't want django to process some of the tags. For example if
somebody creates email template that contains {% url something %} - I
don't want this to work. I want this tag to be disabled (and some
others too) Is it possible?
2) I don't want filters and missing variables {{value}} to fail
silently. When a variable is missing in context while rendering the
email content - this is an error that I wish to handle (tell the user
that his template is broken). Is this possible?
Did anyone use a django template language in that fashion in a web
application that, itself is written in django? Does it make sense? Is
it safe?
--
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.
bug in defaulttags.py ?
Hi
I think I've found a bug in django.template.defaulttags.py
get_nodes_by_type() is not implemented for IfEqualNode class. It seems
like it should be implemented the same way as in IfNode.
Check out this simple test:
def test_get_nodes_by_type(self):
template_string1 = "{%ifequal x 0%} something {%else%}
something else {%endifequal%}"
template_string2 = "{%if x %} something {%else%} something
else {%endif%}"
t1 = Template(template_string1)
t2 = Template(template_string2)
nodes1 = t1.nodelist.get_nodes_by_type(Node)
nodes2 = t2.nodelist.get_nodes_by_type(Node)
self.assertEqual(3, len(nodes2)) #this will work OK, we'll get
IfNode and 2x TextNode
self.assertEqual(3, len(nodes1)) #this will fail, only
IfEqualNode is returned
I'm almost sure this missing implementation is a bug and I'm curious
how this got unnoticed. Seems like this get_nodes_by_type() function
is never used internally? I've found it only because I needed to do
some extra validations on the template structure after it is compiled.
I'm using django 1.0 but I've checked that in 1.2 it's the same.
--
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: bug in defaulttags.py ?
> 1.2 does not exist yet so I'm not sure what you mean when you say you > checked there. Current SVN is certainly different from 1.0 and 1.1 in this > area, see changeset 12654: > > http://code.djangoproject.com/changeset/12654 > > Does that change fix the problem you are referring to here? Yup. This fixes the problem. By 1.2 I meant beta release, available here: http://www.djangoproject.com/download/1.2-beta-1/tarball/ which does not seem to have this change. I guess official 1.2 will be OK :) Thanks. -- 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.
Iterating tree-like data structures with django
I have a model which has a tree-like structure (not exactly a FK on self but we can assume that's the case). I want to visualise this tree using all records from the db. It seems impossible to do with QuerySet, if I have say 100 records (100 nodes in the tree) and I try building the tree recursively django will execute a SELECT for each node so it will hit the db 100 times to build the tree. I thought I could pull the data in one query using objects.all() and then build the whole tree by iterating objects in memory. But again, the structures returned by QuerySet are not the best for this purpose. I can get either list of dictionaries or list of tuples. No dictionary! So, to get a list of child nodes for each node I'd have to iterate thru the whole collection which is not efficient at all. I can't find a way to immediately lookup already fetched records by id! Am I missing something? Iterating tree-like data structures seems something quite common problem and someone must have done it already with django. -- 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: Iterating tree-like data structures with django
OK, I've got it. It's in_bulk() :) Nevermind the question. On Oct 6, 5:27 pm, Paweł Roman wrote: > I have a model which has a tree-like structure (not exactly a FK on > self but we can assume that's the case). > > I want to visualise this tree using all records from the db. It seems > impossible to do with QuerySet, if I have say 100 records (100 nodes > in the tree) and I try building the tree recursively django will > execute a SELECT for each node so it will hit the db 100 times to > build the tree. > > I thought I could pull the data in one query using objects.all() and > then build the whole tree by iterating objects in memory. But again, > the structures returned by QuerySet are not the best for this purpose. > I can get either list of dictionaries or list of tuples. No > dictionary! So, to get a list of child nodes for each node I'd have to > iterate thru the whole collection which is not efficient at all. I > can't find a way to immediately lookup already fetched records by id! > > Am I missing something? Iterating tree-like data structures seems > something quite common problem and someone must have done it already > with django. -- 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: Iterating tree-like data structures with django
Yuck, in_bulk() is useless! I thought it would return a nice
dictionary just as expected, but instead it makes me deliver a list of
keys first. Why?
Eventually I wrote something more usable:
mydict = {}
for model in MyModel.objects.all().iterator():
mydict[model.id]=model
Correct me if I'm wrong but this is hundred times more useful than
current in_bulk() implementation.
On Oct 6, 5:31 pm, Paweł Roman wrote:
> OK, I've got it. It's in_bulk() :) Nevermind the question.
>
> On Oct 6, 5:27 pm, Paweł Roman wrote:
>
> > I have a model which has a tree-like structure (not exactly a FK on
> > self but we can assume that's the case).
>
> > I want to visualise this tree using all records from the db. It seems
> > impossible to do with QuerySet, if I have say 100 records (100 nodes
> > in the tree) and I try building the tree recursively django will
> > execute a SELECT for each node so it will hit the db 100 times to
> > build the tree.
>
> > I thought I could pull the data in one query using objects.all() and
> > then build the whole tree by iterating objects in memory. But again,
> > the structures returned by QuerySet are not the best for this purpose.
> > I can get either list of dictionaries or list of tuples. No
> > dictionary! So, to get a list of child nodes for each node I'd have to
> > iterate thru the whole collection which is not efficient at all. I
> > can't find a way to immediately lookup already fetched records by id!
>
> > Am I missing something? Iterating tree-like data structures seems
> > something quite common problem and someone must have done it already
> > with django.
--
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.
I have an idea for a new tag
When rendering dictionary, there is absolutely no way to display
values sorted by keys. The only workaround is to copy all the dict
items to a sortable structure e.g. list and pass the list to the
template, instead of the dictionary.
Why not introduce a new tag to solve this problem:
I say, it should be called {%secretfor%} and the usage would be
{%secretfor k,v in mydict %}
... do stuff
{%endsecretfor%}
would work like sorted(mydict.keys)
I won't stick with the tag name, but you see my point.
--
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.
Formatting datetimes - simple question
Hi all, Django has this DATETIME_FORMAT setting, which allows to format all datetime values, whenever they are displayed. But the problem is this is a _global_ setting, so whoever uses the application would see all the datetimes formatted exactly the same way. I'd like to allow individual users to select their own favorite datetime format. What I don't know is which method I should override to be able to manually format a datetime field on a model when it is being rendered. Thanks in advance PR -- 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.
Why is django returning only naive datetimes?
I've noticed that django always fetches 'naive' datetimes from the database. Tzinfo property on a datetime object is always set to null, even if the database stores a value WITH a timezone. This is a bit tedious because such datetime cannot be later converted to any timezone. Each time I want to display a datetime on the screen (converted to user's time zone) I have to copy it applying UTC as a tzinfo (this is how it is stored in the database) and then convert to relevant timezone with astimezone(). OK, that's one line of code :) but I have a feeling that this line should be somewhere inside in the django code. -- 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: Why is django returning only naive datetimes?
> This reminds me that we need to open-source our time zone code. We > track entertainment events across several time zones, and Django's > standard time handling can't cleanly deal with that. Database > backends that store time zones as a UTC offset (e.g., PostgreSQL) > actually cause *more* trouble because UTC offsets are not the same > thing as time zones; it's always safest to store times as UTC and > store the time zone separately. That's exactly what I do. The only thing that you should do (in my opinion) is to implement some basic tzinfo for UTC and optionally use it when instantiating datetime value for a DateTime field. e.g. my_datetime = models.DateTimeField(utc_tzinfo = True, ... ) and when a model is fetched, this time field would no longer be 'naive', and could be easily converted to user's local time (using pytz or other library). No extra tricks needed. It would solve the problem for 99% people who deal with timezones, because I guess everyone who wants it done properly, stores all times as UTC. -- 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.
Running django on IIS
I'm trying to run django on IIS and SQL Server 2005. I've found this nice page with all instructions: http://code.djangoproject.com/wiki/DjangoOnWindowsWithIISAndSQLServer I followed all the instructions, installed PyISAPIe, created virtual directory, mapped the .py extension to the PyISAPIe.dll. However I got stuck at this place: "In c:\pyisapie\source\PyISAPIe\Python\examples folder is a file called Info.py. Copy this to your new virtual directory folder, and then try and view http://site/Info.py to test it. It should work. If it doesn't, when you find out why, please come back and explain what happened and how you fixed it. ;) " Well, it doesn't work and I wish I knew why. All I get when trying to view this file is the following: ErrorSpecified module cannot be found. I'm using polish version of windows XP SP3, with IIS 5.1, and the message in is in polish, what you see here is my translation. Anyway, there's no other information: which module could not be found, what, where, why. Nothing. Application log (eventvwr.exe) does not show any errors. I'm stuck. Something with permissions? But what, how and where? I've even tried without firewall but it didnt help. I know this is a problem with PyISAPIe not with django, but I write here because someone might have had similar problem. -- 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: Running django on IIS
> I suspect it is trying to import Http but can't. > > Fire up python (Start -> Python Interactive Shell, or Start -> Run -> > cmd -> type python), and type: > > import Http > If that doesn't work, you haven't installed it properly. See the > following quote from the Django wiki: > > "•Go to c:\pyisapie\source\PyISAPIe\Python\ and copy the entire Http > folder to c:\python25\lib\site-packages. Note: the Http folder is case > sensitive. Saving in 'http' (or any other variation) will not work > [SF]. " > I've copied Http to site-packeges. "import Http" works OK. Interesting thing is that running "from Http import *" fails (AttributeError: 'module' object has no attribute 'Read'), but I guess this has something to do with the fact that Http's __init__.py tries to set __all__ (in other words: import) modules that are not in the filesystem, but somewhere in the pyisapie.dll (?), like the mentioned 'Read'. There is even a comment line that says #From DLL. I don't know how this is supposed to work, i.e. how python can import modules from dll (?), I even included tha path to the DLL in the pytonpath, just in case, but it didnt help. -- 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.
Can django admin log be trusted?
This is serious. A customer I've been working for, claims that he had been adding data via django admin panel (100+ or so records, and one record is really big, using many 'inlines' each with its own formset etc. so adding 100 such records is quite an effort) and at some point of time, large part of the data vanished. He wants us to manually type the data in to restore what allegedly was wiped out. He claims the data was gone after we've done the last release. We have not backed up the DB before the release, it was last backed up 2 weeks ago (yeah, I know, shame on us, but milk's spilled already). It is true that during the relase I made one delete operation via the admin panel (as part of the tidying up some stuff that he messed up earlier) which might have cascade-delete the data in question, but I dont remember seeing the warning about related records being deleted. But OK, I might have overseen it. He was so certain the data was missing, I wrote to him and admitted that it might have been my unfortunate delete and we will type it all in again... But then I started investigating. First I checked the 2-weeks old db backup, to restore at least part of the data. It turns out, 2 weeks ago the data certainly wasn't there, in fact there were less data than it is now, after the alleged wipeout! He claims he added the data after the db was backed up... (although I have his first email where he says it was added throught a timespan of month...). First doubt. So I have dumped the django admin panel log and it turned out there were no records of adding those data!! Now, this was very strange. I know that cascade-deletes are not recorded in the log, but if he claims he entered 100+ items of content_type_id=13, then each such operation should be recorded. But it wasn't!! I could identify only about a dozen inserts (action_flag=added) for the relevant content_type id. So I call him and tell him I believe I am not guilty of deleting the data and that I think it never were entered... He went angry and told me he's 1000% sure he spent a hell lot of time entering this data, and he even saw it later at the front-end, and that it can't be serious, the admin loggin mechanism must be fucked up, because he surely wasn't hallucinating when he was adding these data, etc etc. I was trying to convince him that the logger worked ok because other operations (other content_types) are logged correctly, there are no time gaps (in fact there are different operations every day, proving data on other tables added by other people matching perfectly with the current db state), but eventually he got really pissed off and hanged up. Then I investigated further. And... to my surprise I have found some pieces of data on the database that i coudn't find in the django_admin_log. WTF!? There is physically no other interface to enter these data other than the bloody django admin panel, I am 100% sure of this!!! I can see a piece of data in the db, but no trace of adding it in the django_admin_log!!! Aghrrr! Some of the data of the same content type are there, but some arent there. I am 100% sure it must've been entered via the admin panel, but if this was the case - why isnt there any trace in the django_admin_log? Maybe he is right and I am wrong? The data structure has not change since the last few months, no tables deleted/added, nothing like this. I don't get it and I am totally confused now. So, the question is, can I trust the django_admin_log records? Is it possible that it captures only some of the user actions, and some of them might be missing? If that's true, then he might be right: he added the data (somhow not recorded by django_admin_log???), then I accidentally deleted it by deleting the master record On the other hand, the guy owes me few thousands $ for the last stage but I know has a difficult financial situation now (the whole financing is collapsing due to completely irresponsible behaviour of his partner) and I suspect he MIGHT have a reason to lookf for an excuse to break the contract and don't pay. Which is in fact a biggest doubts of all in this situation. I would feel so much better if I knew this wasn't my fault, but like I said, I am a bit confused over what I found in the django_admin_log... Imagine, you have 24 records of type X in the database, and you dump FULL log of django_admin_panel and find out it only recorded 14 insert operations on this table since the very beginning. And there's no other interface for adding these data other than via the admin panel. Help! -- 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: Can django admin log be trusted?
You're right, I've just checked it and there's a gap for 100+ ids, so he must be right. But does that mean that the django admin log is broken and cant be trusted? How come there isnt any trace of adding those items? On May 10, 11:28 pm, Shawn Milochik wrote: > For what it's worth: > > Regardless of logging you should be able to identify any gaps in > the table's primary keys. Your database should guarantee that. -- 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.
Memcached backend - caching data with infinite timeout
Python-memcached docstring for set() says this: """ @param time: Tells memcached the time which this value should expire, either as a delta number of seconds, or an absolute unix time-since-the-epoch value. See the memcached protocol docs section "Storage Commands" for more info on . We default to 0 == cache forever. """ So it says, zero means forever. But django wrapper class for memcache has this line in set(): timeout = timeout or self.default_timeout Which means that it will never accept zero as a value unless I specify a default timeout of zero in settings (which I don't want to do, because I want to have the default value other than 'forever'), I only need infinite timeout in few cases. Either python-memcached docstring is wrong (i.e. setting time to zero doesnt mean "forever") or django doesnt implement it 100% correctly. -- 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.
