> unless I've missed something whoever gets the position, would definitionally
> get it before they've done anything!
I strongly suggest you should take a look at grappelli ... some people
*are* doing things ;)
> In conclusion, there is 0 reason design needs to be treated different from a
> pro
> Grappelli has done a great job of skinning the admin interface.
It depends which version you check. We are currently in the decision
of breaking appart from the Django admin and
create a standalone app or stick with it[0]..
We have started to be a lot more than a "skin". We are currently in
the
Good to see you guys are progressing.
I've red lots of interesting and valid input, but from what I can see
there is tearing decisions ahead and whoever
will take the design lead will be invariably limited by the current
state of the admin.
If you want to achieve something like we are doing with
Hello,
I would like to introduce a project I've just released in the wild.
For the moment it is still just a working prototype, but hopefully it
will grow and stabilize with time.
On Google Code:
http://code.google.com/p/django-ray/
Introduction blog post:
http://haineault.com/blog/125/
Comment
It might just be a crazy idea .. but sometimes I wish something like
this existed:
https://gist.github.com/1414209
On Nov 30, 10:36 pm, Ned Batchelder wrote:
> On 11/30/2011 5:22 PM, Jeremy Dunck wrote:
>
>
>
>
>
>
>
> > Hi all,
> > I've got a codebase with a fair bit of fixtures and have bee
I tried and double checked the given possibilities and ended up
finding that cookies were diabled on my phone..
Would be nice if there was a hint about this in the debug page.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
I would also like to know more about the rational behind ditching the
idea of
multilinetags.
{% trans with
varname=myobject.proprety1
someothervar=myobject.some.other_property
yetanothervar=myotherobject.with_a_painfully_long_method_name
"Even with line-wrap, it's a pain to rea
I've submitted a ticket[1] with two patches as a follow-up to this
discussion:
http://groups.google.com/group/django-developers/browse_thread/thread/ca34924871e3c00b/b29cd0e17c010f54?lnk=gst&q=csrf+cookie+haineault#b29cd0e17c010f54
In short, the first patch add a bullet point in the CSRF error pa
> If you'd like to make an argument as to *why* it's useful, that's useful, but
> we don't take polls.
I think the argument as to why it's useful as been made quite
extensively.
On the flip side, beside the ivory tower philosophical stance, I did
not see much
compelling argument as to *why* this
rver to host it.
[1] For the curious, the client part is getting quite stable
lately. We use it on a couple of projects and the number of saved
keystrokes is pretty amazing so far: https://github.com/h3/django-duke-client
--
Maxime Haineault
--
You received this message because you are
anch)
Alternatively the branch on my fork works pretty well with 1.4:
https://github.com/h3/django-grappelli/tree/grappelli_2_4
Cheers
On Apr 26, 7:06 pm, Victor Hooi wrote:
> Hi,
>
> Is there any news on the Django Admin rewrite front?
>
> I remember around a year ago, there w
idk .. but I'll make one anyway.
I whish there was something like this for django: http://brainstorm.ubuntu.com/
Good news: the site's engine is Open Source
Bad news: it's ROR (http://bbyidx.com/)
Pretty decent alternative: http://www.google.com/moderator/
On Aug 6, 3:12 pm, rvanhoepen wrote:
I've submitted a patch[1] which makes the "random" template filter
accept QuerySet and adds a "shuffle" filter which also works on both
lists and QuerySet.
I think it would make sense that the random filter accept QuerySet
instances since most of the time when working in templates we are
dealing w
I'm not sure suppressing templates errors for the admin is such a
great idea.
I work on two projects[1] where I would lose a useful debugging
information and
it would be the same lost to anyone working on the admin or extending
the admin.
Of course we could use a settings to toggle on/off the adm
hink Django should advocate good practices, but also try to make
developers' life easier.
At the end of the day it would pay off.
For those who are interested, my project is hosted there:
https://github.com/h3/python-dad/tree/master/dad
Most of the docs are still hosted there (moving to docs/
> Beyond that, what I am wondering is how much users will be able to understand
> how Django work if they can't do the installation.
Each year I accept foreign students for internship in my company and
most of then either never heard of Django or didn't bother to learn
how it works just to try it
There's numerous time where I found myself wishing for type casting
filters in templates..
For example, the following won't work because one is a string and the
other is an integer:
{% if request.GET.year == object.date.year %}
...
{% endif %}
So when I need to compare a string with an int with
I'd like the settings file to be more convenient too, but most of the
suggestion are too specific.
It's an excellent idea to automate more things, but it's a really bad
idea to pretend that we know
everybody's needs.
Personally here's what I'd like to see in the generated settings.py:
import os
I think for the moment, the easy fix for anonymous forms it either to
put them on a different page or
to load them with ajax.
This way the forms and thus the tokens gets generated only when
needed.
If caching and performances are a big concern, I think those
alternative are win/win solutions.
Yo
19 matches
Mail list logo
