I'm not sure if this is the place but here are some other issues or
questions I have if this were to happen...
* The jQuery question is a big one. I've taken strides to make the
debug toolbar interoperate with other popular JS frameworks (mootools
and prototype, namely). But if jQuery were deci
Take a look at ticket 3011:
http://code.djangoproject.com/ticket/3011
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
On Thu, Aug 20, 2009 at 1:03 PM, Nicolas Steinmetz wrote:
> Maybe you can inspire from the Jobeet [1] tutorial which consists at the
> beginning as an advent calendar (a one hour tutorial published
> everyday). Jobeet is a Job board and allow to deal with all aspects of
> Symfony framework from fr
Or: Why is HTML4 such a PITA to get right?
Outline:
* What I know about HTML4 and Django
* Some info about past efforts and discussions
* Thoughts and curiosities about what we can do
What I know about HTML4 and Django
First, let's not let this turn into an argument
On Sat, Sep 26, 2009 at 2:13 AM, Simon Willison wrote:
> Yes - I looked briefly at how much work was involved in doing this and
> it's not insubstantial, which is why I opted for string replacement
> just to demonstrate the API. I'm confident the exact functionality of
> django-html could be repl
On Sat, Sep 26, 2009 at 11:33 AM, Simon Willison
wrote:
> I don't think it would involve form widgets being rendered with
> templates simply because of the performance overhead - even with the
> template caching improvements it's still a lot of work just to output
> an input tag. It might involve
On Mon, Sep 28, 2009 at 6:38 AM, Russell Keith-Magee
wrote:
> By way of greasing the wheels towards trunk: if the outcome of this
> mailing list thread was a wiki page that digested all the ideas,
> concerns and issues into a single page, it will make the final
> approval process much easier. Luk
I'd like to propose the addition of a new tutorial that represents a
complete website, describing everything from start to finish. This
would allow for many more topics to come into play -- things we all
deal with at some point in developing websites using Django. This
would also allow for those
I, too, like the idea of a conference site. It fills a void and
sounds useful for upcoming conferences. I wasn't too crazy about the
blog idea, and was convinced away from the snippets idea. So shall we
call it a conference site and move on? :)
For a nice reference implementation, I'd like to
On Sat, Oct 10, 2009 at 6:04 AM, Ned Batchelder wrote:
> My strong feeling is that these two goals will quickly become impossible to
> reconcile. I think the idea of a conference site is a good one (everyone
> will understand the problem domain, lots of interesting avenues to explore,
> it's not
On Wed, Oct 21, 2009 at 12:22 PM, mrts wrote:
> A DVCS mm-tree
> --
>
> Quoting
> http://en.wikipedia.org/wiki/Andrew_Morton_(computer_programmer)
>
> "He currently maintains a patchset known as the mm-tree,
> which contains not yet sufficiently tested patches that
> might later be ac
On Wed, Oct 21, 2009 at 6:38 AM, David Chandek-Stark
wrote:
>
> The values_list() query set method is useful for dumping data to CSV,
> etc. However, I find that I often want to use it without specifying
> the field names (to get them all) and yet also include the field names
> as the first row i
On Tue, Nov 24, 2009 at 3:36 PM, Russell Keith-Magee
wrote:
>
> Time zone handling is definitely something that Django could handle
> better, but simply switching to UTC for certain functions isn't the
> solution.
>
I like the solution proposed on ticket 10587:
http://code.djangoproject.com/ticke
I've battled many of these same issues when working on the debug
toolbar... it needs to work the same in any environment it gets loaded
into and, as such, has slightly different requirements put on it. It
is seeming the admin is heading the same direction to some degree.
While certain parts of the
On Fri, Feb 19, 2010 at 8:58 AM, Luke Plant wrote:
> IMO, using 'library agnostic' javascript in the admin will mean we
> just end up implementing our own library, which will end up being an
> ad hoc, informally-specified, bug-ridden, slow implementation of half
> of jQuery/dojo/etc, and even less
On Tue, Apr 27, 2010 at 6:38 PM, Leo wrote:
> Digging deep into Python's innards reveals that this is a somewhat
> esoteric protection in case you're writing out Unix mailbox files. The
> specific issue is here:
> http://docs.python.org/release/2.6.2/library/email.generator.html#email.generator.G
If I recall correctly, there's another branch on the that project that
was refactoring the autocomplete widgets so that there were
essentially 2 widgets: A widget intended to be used in your own
Django code, and an admin widget that was a subclass for use in the
admin.
To me that would be a nice
Russell Keith-Magee wrote:
> You are correct (and it's not just with MySQL). This is a bug born of
> the way that syncdb installs applications. For some reason, it doesn't
> defer to install - it duplicates the install logic, but doesn't include
> indexes.
>
> I intend to refactor this code wh
patrickk wrote:
> 2. when using a custom manipulator for letting the user change his
> personal values (first name, last name, address, zip_code ...), I
> have to change 2 different tables (user and userprofile). that doesn
> ´t seem to be clean ... ???
Can you not put first name, last name, and
I've been slowly trying to work my way into helping out with Django,
but mostly at the outset I'm reading all the docs, reading the source,
and trying to figure out how it all ticks. Some areas are easier to
get than others. But as an interested person who'd love to contribute,
what's the best a
Joseph Kocherhans wrote:
>
> form = ContactForm()
> if request.method == POST and form.bind(request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':form})
>
> Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> the
I'd like to see some flexibility to output HTML4 as opposed to XHTML
(or whatever flavor comes along next).
Currently in 0.95 it looks like all the render() calls on the various
"generic widgets" output XHTML form elements. I've been pretty much
convinced not to use XHTML by Ian Hickson (at leas
Matthew Flanagan wrote:
> cd django_tmp_src
> svn merge -r 3332:HEAD http://code.djangoproject.com/svn/django/trunk
>
> [resolve and conflicts and test your code]
> svn co -m 'merged latest changes from trunk'
I think that should be:
svn ci -m 'merged latest changes from trunk'
After you resolve
The Wiki page on the API Stability says this about the comment system:
> The comments framework, which is yet undocumented, will likely get a complete
> rewrite
> before Django 1.0. Even if the change isn't quite that drastic, there will at
> least be
> moderate changes.
Are there goals or doc
James Bennett wrote:
> On 10/26/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>> Are there goals or docs about what this might become? There seem to be
>> enough people using the comments systems that maybe people could work
>> on a patch (or at least get started in th
> I hacked on the forms thing a bit more on a 3-hour plane ride today
> and came to the same conclusion. I've attached the newest version of
> this file (gee, progressing like this is going to get unwieldy unless
> I check this into SVN), which has changed Widget.render() to take the
> name and va
I think it would be a good idea to have a bug-squash/testing day on IRC
for certain branches. Maybe the developers of those branches let
someone (?) know they'd like some testing. A day is picked and that's
the testing day. Try to raise awareness on the mailing lists and that
IRC will be the pl
Would there be a way to do something like this:
If contrib.contenttypes are in settings.INSTALLED_APPS:
Add to models.Model a method:
get_content_type that returns the ContentType object?.
That way, any model I have will have that method available to easily and
quickly get its content type
Jacob Kaplan-Moss wrote:
> Try this::
>
> from innovate.innovation.models import Innovation
> from django.contrib.contenttypes.models import ContentType
>
> i = Innovation.objects.get(id=1)
> ct = ContentType.objects.get_for_model(i)
Yeah, that's not so hard. I updated my
Jay Parlar wrote:
> The core devs tell people all the time that it's generally safe to run Django
> off the trunk
I think this is a self-imposed limitation to allowing a branch that's
close to be merged to trunk to get more testers. For myself, I'd much
rather see some broken things on trunk on
Adrian Holovaty wrote:
> That's exactly what we're using the branches for: Things get broken on
> the branches as branch owner merge in new features. Eventually, bugs
> get worked out, and they do a code freeze prior to the merge to make
> the branch as stable as possible.
I suppose the disadvant
Michael Radziej wrote:
> Let's have a branch of the month, announced on devel and users. The
> branch is then frozen, merged with trunk, and will be merged at a fixed
> date into trunk if no critical and unfixable bugs are found. This would
> encourage at least me to check this branch out and test
I stumbled across this ticket with patch a couple months ago. I
thought of it recently and wanted to bring it to the attention of the
developers. I like the idea and it looks like it simplifies the
edit_line stuff a lot...
http://code.djangoproject.com/ticket/2248
--~--~-~--~~
Aidas Bendoraitis wrote:
> Not a bad change, but much more important, in my opinion, would be to
> have an ability to set the fields of inline edited models according
> the formatting set in fields list/tuple; with all the features as
> collapsible groups of fields, placing fields next to each oth
I was just playing with trying to run the tests this morning as well.
Doing "python runtests.py" in the django/tests directory gives me an
error about the DJANGO_SETTINGS_MODULE. I couldn't figure out what
needed to be in my environment setting to get the tests to work.
Searching Google didn't t
James Bennett wrote:
> So I've been poking around in the newforms code, and it appears that
> the pre-defined widgets will be producing XHTML-style output.
I had the same thought but I wrote a quick test with an HTML 4 strict
doc-type, put an input tag in it like this: , and it was still valid.
This looks pretty cool. I'm excited by the new forms development and
hope to play with some of it soon.
It seems a little out of place to me to instantiate an object in
urls.py:
(r'^post/$', MyFormPreview(MyForm)),
(There was some thread talking about urls.py becoming more of a
"controller
On 20061207.0851, Adrian Holovaty said ...
> This would be a great addition. Rather than requiring sessions, what
> do you think of passing intermediate form data in hidden fields? It's
> simpler, it wouldn't require cookies and I can't immediately think of
> any downsides to the approach.
One do
There was a discussion a long time ago about Django t-shirts (at
OSCON?). My question for the core devs is: Why not set up a quick Cafe
Press site for a couple simple t-shirts and use the money to help fund
development? Maybe put up bounties for some bugs or features? Or
simply split the proce
Isn't the session a natural place to store these kinds of things? Is
there a reason for the avoidance of sessions? Are they buggy? Do they
require some sort of over-head people are trying to avoid?
Just curious,
Rob
On 20061211.1152, Kevin said ...
>
> I like the idea of storing an encoded-p
I agree that it's more intuitive to tie messages to sessions.
I remember reading many articles on PHP sessions and about session
hijacking, etc. Has Django's sessions been looked at from this
perspective or can Django's sessions have similar issues?
Some reference material by Chris Shifflett, o
Jeremy Dunck wrote:
> But I agree session hijacking is a concern, though totally unrelated
> to the discussion of whether to move messages to sessions. :)
Yeah, I kind of got off topic. My apologies. Maybe I should post the
same message in a new thread... I think session security is important
It looks like these same articles have been checked against Django's
session code in this bug:
http://code.djangoproject.com/ticket/362
Cool. :)
-Rob
On 20061212.1819, Rob Hudson said ...
> Yeah, I kind of got off topic. My apologies. Maybe I should post the
> same message in a
Benjamin Slavin wrote:
> Django does use an algorithm that generates difficult-to-guess session
> IDs; however, no current implementation of sessions (by anyone) is
> completely safe.
I've verified this, actually, with WebScarab, retrieving 1000
consecutive session ids and visualizing them on a p
* Benjamin Slavin ([EMAIL PROTECTED]) wrote:
> The get_new_session_key method would probably be a good place to
> start, though I have little familiarity with the interface to the
> session middleware. I'm swamped right now, so I'll look into it in
> the next few days. If you need any assistance
Michael Radziej wrote:
> > To go with the 80/20 rule, I'd imagine that for 80% of Django developers
> > something like this would work pretty well and be useful. [...]
>
> I don't think so.
>
> Isn't session cleanup a natural candidate for a cron job (and
> whatever is the equivalent in the Micros
limodou wrote:
> I saw that newforms has meny output methods, just like: as_table,
> as_p, as_ul, etc, and someone also want to add as_dl. And I also saw
> that the output is hardcoded in the source code. In my personal
> woodlog project, I made an easyform app, and I can render a form with
> a su
I've got a particular case that I wonder if it is worth submitting a
patch for...
I do not have an /accounts/profile/ URL and for the site I'm building
it doesn't make sense to have a profile page. But I do need
login/logout functionality and am using django.contrib.auth. I'm also
providing "L
Karen wrote:
That would certainly do the trick, and is easy enough.
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers
Would Michael Radziej's suggestion work better for those who develop
against trunk but whose servers are running stable releases (ie: 0.95)?
That's my case and I just ran up against this issue.
For now, I'm going to revert my local workstation to using 0.95.
--~--~-~--~~---
I ran into another spot where not having my login at /accounts/login
made things difficult...
I'm using the password reset functionality. When the user enters their
email and they get sent a password it is including a link to the
password change form. When the user isn't yet logged in,
passwor
Or perhaps you have a test server which is running the same codebase
as prod?
Yes. We have a development server running 0.95 that matches our
production server.
Generally there hasn't been much different from 0.95 to trunk so I've
been keeping up to date with trunk on my workstation just to
Kenneth Gonsalves wrote:
I did create my own login decorator for this site for my own views that
are using it. But to use my decorator for the password views would
mean duplicating (or copying) all that code.
use user_passes_test - it allows you to specify the url you want.
Yes, that's wha
I just wanted to say that this is the reason I'm reluctant to use
Django's forms (new or old) no matter how stable it is. I like that
any major chunk of HTML code is visible for tinkering in my template
files. Maybe a template solution would be more work (probably some
repetition, I haven't re
James Bennett wrote:
> I'm using HTML 4.01 (quite happily, I might add) and running into
> annoyance with the fact that both Django's newforms and the old
> manipulator system default to XHTML-style tags with no way to override
> that.
James,
I'm in the same boat. I'm curious why you don't use
I was trying to write a fairly complicated query to pull in content
across tables in one query rather than having to break it up into many
queries. In playing with this I think I found a bug.
Note: I've simplified the call slightly by using a different part of the
data model than what I'm rea
I posted a bug (http://code.djangoproject.com/ticket/3280) before I
left work which quickly got shot down by Adrian. :) He's right in
that it's a pretty general bug so I bring the conversation here. I'm
curious what the Django devs will make of my reasoning...
I realize some of these aren't di
Michael Radziej wrote:
> I'm not sure what you mean exactly with "HTML agnostic". Could you
> explain it, please?
Just that Django shouldn't favor XHTML over HTML4. But I'm actually
not too concerned if it comes with django.forms that default to XHTML,
but they are easily configurable or easy to
I think it's in the other thread, but what's the reason for wanting to
decouple forms from templates? I can think of 2 reasons:
1) Decoupling means you can change the way templates work and not have
to update the forms code. Counter argument: If you change the way
templates work you'd break a l
Michael Radziej wrote:
> BTW, what keeps me from XHTML is simply that my javascript
> library of choice (yui) doesn't support it in all components.
Hmmm. Can you elaborate? We're using YUI for a few things as well and
I wasn't aware of this. (We can take this offline if it's preferable.)
> XH
Jacob Kaplan-Moss wrote:
> Good point. Eugene sent me a windows installer a while ago, but I didn't have
> a chance to test it out and then I lost track of it
>
> Let's table this until closer to the release, but if you want to talk to him
> and anyone else and start lining things up for a wi
There are really at least two distinct audiences for an installer:
experienced python users who will likely have a database and python
version installed along with various add ons, and new python users who
may be thinking about moving from LAMP (where the P is PHP) to either
Ruby on Rails or hop
PS: This could also be used as an example of how to build an installer
for your app to send to someone for reviews. Something we're going to
need where I work in the not so distant future.
--~--~-~--~~~---~--~~
You received this message because you are subscribe
Adrian Holovaty wrote:
> Graham and/or anybody else who wants multi-threading in the
> development server, can you try this patch and see whether it solves
> your problem?
I updated my Django trunk with the ThreadingMixIn patch and looking at
a couple projects that have media served statically (f
On Jan 23, 7:55 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> Keeping in mind the comments about possible thread-safety heisenbugs,
> let's make it so that the threaded behavior is *optional*, but people
> can turn it on if they're concerned about Ajax-induced stalling. What
> do you think? A
Wow, I didn't even know those existed. Besides this bug, are these
considered stable?
Are there plans to document them?
I've got a data model that we may need to implement that could use just
this feature. If we start playing around with them and see how they
work I can try to help provide som
On Jan 25, 10:35 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> and the
> small fraction of people using them probably all subscribe to this
> mailing list
If there's not 100% certainty, I'd argue that it deserves a new point
release. It just takes 1 person for this to bite and post a rant t
I'm getting a weird bug here and this is what I've deduced...
I've got a "Page" model and a "Content" model. Content has a FK to
Page. I also have a "ContentType" model and Content has a FK to
ContentType. This is where I tell it if the content is text or other
media content.
The problem c
> Django has a builtin type called "ContentType",
> http://code.djangoproject.com/browser/django/trunk/django/contrib/con...
>
> I'd just rename yours to something else and be done with it.
As a workaround, sure. I've already worked around the issue.
But I don't think Django would want this typ
> Keep in mind that django.contrib.contenttypes gets installed by
> default, and is used by the comments app, the auth app, the admin app
> and the generic relations framework.
>
> It's hard to escape it :)
I quickly grepped the docs directory and it's not mentioned that you
can't have a model n
> I agree this approach is a huge improvement over the current syntax,
> but I wonder whether it can be expanded even more. Instead of
> dictionaries, let's use objects:
Woah... inline that is specified by objects that can be subclasses?
I'll have to wrap my head around that one.
Would it be pos
I'd like to see more inline documentation of the code. Some .py files
have this but some don't. Just an overview of what the file does, how
things are organized, maybe some concrete examples via doctests.
Something for the average python programmer to get a toehold into what
the code is doing.
#3185 fixes these also: #3372, #3407 (there may be others).
That patch would make me happy.
Thanks,
Rob
On Feb 7, 12:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Forwarding this here, because the problem would go away if we could
> get some attention on ticket #3185:
>
> http://code.djan
Since SHA-1 was recently found to have some collisions, and since sha
is deprecated in Python 2.5 in favor of hashlib, should an attempt to
import hashlib be added to contrib.auth.models (both check_password
and set_password) so when Python 2.5 becomes more mainstream, this
will be picked up by de
On Feb 8, 9:36 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Using hashlib to generate SHA1 when it's available is something I
> could get behind. Deprecating SHA1 hashes, not so much
Totally agree... the news about SHA-1 made me want to look up Python's
cryptographic functions as a curiosity.
Should I file a bug to eventually use hashlib for >= Python 2.5?
Should I provide a patch which attempts to import hashlib and use it
if available, but otherwise falls back on md5/sha1?
Some general confusion about what's going on in contrib.auth.models...
There's 2 check_password methods in the
Malcolm Tredinnick wrote:
> Be careful to ensure backwards compatibility. Otherwise an
> inconsequential Python upgrade (to 2.5) will mean all your previously
> recorded passwords are now unusable. You need to at least be able to
> check for SHA1-style hashes and use those if necessary no matter w
This is obviously borrowed from PHP but I think there are useful
reasons to copy this behavior.
The idea...
If one constructs their HTML forms, naming their form elements as
"name[key]" like so:
etc.
Django would then convert this to a dictionary of form:
f = {
'name': 'value
On Fri Feb 09, 2007 at 02:54:44PM -0800, SmileyChris wrote:
>
> Hi Rob, there's similar functionality in Django already (but it's
> undocumented afaik) using a custom data structure called
> DotExpandedDict:
> http://code.djangoproject.com/browser/django/trunk/django/utils/datastructures.py#L215
I'm wondering if maybe get should raise an error with a name like
"MultipleValueError" rather than "AssertionError" when multiple values
are found...
Yesterday I was wiring up a toggle method. If the row is in the
database, remove it. If it isn't in the database, add it.
I don't have the exact
I saw this changeset go in and am wondering if it is possible to
specify a sequence order for the fields to display. Example:
class Person(Form):
first_name = CharField()
last_name = CharField()
class PersonWithMiddle(Person):
middle_name = CharField()
But where
Cool. I was looking at how I'd do this but I wouldn't have known
about the add_to_class in __new__.
On Feb 16, 12:18 pm, "Gary Wilson" <[EMAIL PROTECTED]> wrote:
> Ticket and patch created:http://code.djangoproject.com/ticket/3511
--~--~-~--~~~---~--~~
You recei
I implemented app completion and would like comments and testing for
those on *nix.
What's the easiest way to provide a patch? Open a new ticket and
attached? Or attach it to the original bash_completion ticket here:
http://code.djangoproject.com/ticket/1240 ? I'm pasting the diff
below so peo
I re-opened bug 1240 and added my patch there:
http://code.djangoproject.com/ticket/1240
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop
This morning I'm working on a few things with this...
> I'd like to change the "grep -v django" line with "grep -v
> django.contrib" so that applications containing "django" as a part of
> their name (ex. djangotestproject.appname) are not discarded.
Good point, I'll add it in to the next patch.
Could we get a design decision on whether to add default, non-django
looking 404 and 500 templates?
It seems pretty minor but important as there are 2 cases where
switching from DEBUG=True in development to DEBUG=False for production
could end up biting you...
1) With DEBUG=False and a 500 occur
On Feb 26, 9:46 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> I've close #760 and #3335 with this comment:
Design decision: Django won't include default 404 and 500 templates.
OK.
But does that invalidate those bugs? The default templates were a
possible solution to fix both of them.
Bo
This patch being:
* good for local testing that more closely resembles a real hosting
environment (eg: with AJAX testing)
* for the development server only
* and disabled by default
you'd think it would be an easy inclusion. I'd like to know more too.
-Rob
--~--~-~--~~---
On Feb 9, 3:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> So after some back and forth about whether this should or shouldn't
> work, there didn't seem to be any resolution. Your gut feeling looks
> right to me Rob: it should probably work as you expect (no collision),
> although it won't
> Could this be related to #2874 ?
2874 looks related in that it is another bug resulting from a similar
type of circular table relationship.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" grou
I like it... I had to do a all encompassing "except" just the other
day because IntegrityError was in MySQLdb.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send e
I was reviewing all the SQL calls in my page views by taking advantage
of the context variable "sql_queries" when DEBUG=True.
I found this query that isn't quoted correctly (I trimmed out some
stuff to make this shorter):
SELECT
-- various fields listed here
FROM
`page_content`
INNER JOIN
On Mar 7, 11:15 am, David Danier <[EMAIL PROTECTED]> wrote:
> AFAIK the queries are logged without quoting but executed correctly.
> (You can see this, if you have a SQL-error and the DB-backends throws an
> exception with the real query)
So somewhere else in the ORM it fixes the quoting before i
> Ok - initial opinion appears to be anti configurability and anti
> changing the default. Another option is to introduce a different tag
> for the 0-spaces case. Opinions? Suggestions for names? Spaceless is
> the obvious choice, but that name is taken :-)
My thought was:
"spaceless" is no spac
> Ok - initial opinion appears to be anti configurability and anti
> changing the default. Another option is to introduce a different tag
> for the 0-spaces case. Opinions? Suggestions for names? Spaceless is
> the obvious choice, but that name is taken :-)
My thought was:
"spaceless" is no spac
On Apr 6, 3:51 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> [An unproven gut feeling: keeping a small reminder, however subliminal,
> that things are relational-database backed is actually a good idea. It
> will stop widely read people from thinking there is a true object
> backing store.
I'd like to hear what others think of this approach b/c it makes a lot
of sense to me and does seem much easier in that:
1) The newly defined user object is in request
2) There's one place to get user info
Thanks for sharing,
Rob
--~--~-~--~~~---~--~~
You receiv
At Mozilla we've used a jinja2 template filter called 'urlparams' for quite
some time. You can see the code in jingo here:
https://github.com/jbalogh/jingo/blob/master/jingo/helpers.py#L116
In Python:
urlparams(reverse('translate', kwargs={'slug': document.slug}),
to_locale=locale)
In Jinja2 temp
I opened bug: http://code.djangoproject.com/ticket/15043
I actually stumbled on this just a few days ago while trying to put a
session_key to user ID mapping into Redis upon login and was stumped
for awhile why it didn't match the session key of my logged in user.
-Rob
On Sun, Jan 9, 2011 at 10:
I'm pretty sure this has been beaten to death, and I was going to pass
on sending this in, but this paragraph made me ask, "What would it
hurt to ask?":
{% block quote %}
Unfortunately, sometimes you are not fully in control of the content
you produce. For example, this very blog, published with
1 - 100 of 171 matches
Mail list logo
