Re: Django Admin Revamp - Any updates?

[h3]

I don't know the status of this project, but my guess is that you
shouldn't hold your breath for it.

Fortunately, there is Grappelli: https://github.com/sehmaschine/django-grappelli

We are currently working on making it compatible with django 1.4 (see
the "grappelli_2_4" branch)

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 <victorh...@gmail.com> wrote:
> Hi,
>
> Is there any news on the Django Admin rewrite front?
>
> I remember around a year ago, there was quite a bit of talk on revamping
> the Django admin UI - I think Idan Gazit was heading that, right?
>
> Is that still on the Django roadmap? Any idea of whether it'll be in 1.5,
> 1.6, 1.7 etc?
>
> Cheers,
> Victor

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Just a crazy idea..

[h3]

First a little context..

I've been on the django-dev mailing list for quite a while .. since
about 1.0. I'm usually relatively quiet unless I think I have a good
insight about an issue. It's been a great source of learning, but also
a good way to notice recurring patterns.

On the other hand, I've also been working on a Django development
environment for the last few months. It will cut down a lot of
annoying, redundant and harder parts that keeps the bar of Django
development so high. Ultimately the goal is to bring it to a point
where I can hire a designer, set up a Linux virtual machine on his
workstation and make him work on Django sites with a few simple
commands. He has no needs to know about Python, buildout, package
management and other stuff like that. The project is actually a lot
more than that and I will eventually announce it officially [1], but
that's not the point of my email today.

Today I feel the need to share an idea that came from the context
described above and that's been in the back of my head for the last
couple of weeks.

This idea could;

 - Make new features testing a lot more thorough before they are
merged them to trunk
 - Make it possible to actually measure a feature's popularity before
merging them to trunk
 - Make it a lot easier for the community to test new features and use
them long before they hit the trunk
 - Allow people to actually use features that has been rejected for
whatever reason (and that aren't implementable as third party)
 - Increase django's development pace and contributions

And this idea is just: a patch server.

Imagine a site where developers can browse, upload, rate and comment
patches. Something like django snippets, but instead of snippets, it's
patches for django.

A developer can upload a patch (linked or not to a ticket), specify
the django version with which it is compatible and add revisions.
Other users can rate, comment and propose revisions.

Finally, a buildout extension (or other automation mechanisms) could
be created and would allow to easily load and apply patches at
installation time.

In my dreams, applying a patch to a django installation would be
simple as editing a buildout.cfg and add those lines:

[django_patches]
email_username = http://server.com/user/email_username/ rev=12
no_admin = http://server.com/anotheruser/no_admin/

It would make the future development of django a lot more community
centric, more tested and more discussed.

To eager developers who wants new feature implemented in core, we
could just say "go on, make a patch and prove your point" instead of
debating it on a mailing list.

Other people could then try it, use it and improve it before it is
implemented in core.

Like I said, just a crazy idea .. or a cool GSoC project ? :)

Unfortunately I'm too busy to make it myself.. But if a majority think
it's a good idea and some developers wants to make it happen, I will
find a server 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 subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[h3]

> 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 is a bad idea.

If you think it makes your templates look ugly, well just don't use
it. You'd still have the choice.

Meanwhile some other people think it would make their templates more
readable, but
unfortunately they don't have the luxury to choose because an
architect think it's ugly.

At this point I think it's worth mentioning that it's a not a beauty
contest. And even if it was,
I don't see the beauty in lines of code that are 10 feet long.


On Feb 24, 10:15 am, Daniel Moisset  wrote:
> On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor  wrote:
>
> > Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> > it's meaningless.  That's a tiny fraction of this mailing list's readership,
> > much less of the Django community at large.  Django is the way it is
> > because, first and foremost, of taste.  If you'd like to make an argument as
> > to *why* it's useful, that's useful, but we don't take polls.
>
> It's useful because it helps some templaets in some cases be more readable

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Request for review for a small fix in the csrf view

[h3]

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=csrf+cookie+haineault#b29cd0e17c010f54

In short, the first patch add a bullet point in the CSRF error page
which states that this
error can be triggered by disabled cookies.

The second patch fixes the middleware itself to make the page show the
correct error message if the
error is caused by disabled cookies.

The error message was already in the django source code, it was just
not used.

Both are really small patches, but I decided to make two patch to
increase the chances that at least the error
message gets in for 1.4 final (it's only two lines of HTML).

I did not dare to mark it as release blocker, but I do believe it
should be in 1.4..

1. https://code.djangoproject.com/ticket/17732

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[h3]

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 read on a single line."
%}

Forcing a Python developer to write something like this on a single
line
is borderline cruel.

Besides, it's backward compatible (I think so) and it doesn't break
syntax highlighting (in Vim at least).

+1


On Feb 18, 1:04 am, Glenn Washburn 
wrote:
> Hello django devers,
>
> I'd like to reopen discussion on the multiline tag issue 
> (see:https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.
>
> I've done rudimentary testing on a 6 character change in 1.3.1 to
> template.base.tags_re (add the re.S flag to the regex), which appears
> to solve the issue.  So I don't see all the work which was being
> referred to in mtredinnick's point two.  Perhaps the template engine
> has been rewritten since then.  The only test that fails after making
> this change (in 1.3.1) is the one that explicitly tests that tgs should
> not be multiline.
>
> Since this change appears to be so low impact and such a simple
> change.  Are there any reasons why this change shouldn't be included in
> django?  Maybe I'm missing something.
>
> Its interesting to note thathttps://code.djangoproject.com/ticket/3888, which 
> is referenced in the
> issue, is also closed as "won't fix", but appears to be allowed in
> 1.3.1.  So there is a precedent for "won't fix" issues being included.
>
> -Glenn

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Add disabled cookies as possible cause of csrf token 403 debug page

[h3]

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 group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improving test data experience

[h3]

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 been
> > experiencing some pain around it.  One of the pains is migrating the
> > format of fixtures when a schema change occurs.
>
> >    I posted a thread to south-users to discuss the idea of adding a
> > feature to aid applying migrations to fixture data:
> >        
> > http://groups.google.com/group/south-users/browse_thread/thread/e358d...
>
> >    Evgeny responded that perhaps scripting generation of the fixture
> > was a good approach, and Carl responded that he thinks that generating
> > the needed test data in the TestCase itself is preferable.  Both
> > approaches avoid the immediate problem of wishing I could migrate
> > fixture data, because generating the data under their approaches
> > avoids having fixtures as an authoritative source of data.
>
> >    That surprised me a bit since I generally have viewed fixtures as
> > things to set up once.  Have others on the list tried these approaches
> > (or other approaches) and have any thoughts you'd like to share on it?
>
> >     In any case, I think it would be good to do one or both of the 
> > following:
>
> >     1) expand on the testing guide to present fixtures as one option
> > for test data and point out the options to script fixture generation
> > or avoiding fixtures in favor of TestCase-called generation,
> > discussing tradeoffs in the approaches
> >     2) add a django-admin testshell command which would act like
> > testserver - loading fixtures into a test DB and dropping you into the
> > shell to munge it as needed; this would be paired with a south feature
> > for applying migration fixtures.
>
> >    Feedback, please?
>
> FWIW, this is the process I've used in the past:  
> http://stackoverflow.com/questions/4002322/migrating-django-fixtures
> There's got to be a better way.
>
> --Ned.

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: The state of per-site/per-view middleware caching in Django

[h3]

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.

You solve your problem and remove load.

My 2¢

On Oct 21, 2:39 pm, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/21/2011 07:02 AM, Jim Dalton wrote:
>
> > 1. Fixing #9249 and #15855. I hear your philosophical concerns about
> > #9249 but the ubiquity of Google Analytics means we must do fine some
> > way to fix it (IMO). Addressing these two tickets would at least
> > ensure page caching wasn't actually broken. I'll try to jump in on
> > those if I have time later next week. #9249 in particular seems quite
> > close.
>
> > 2. Clarifying the documentation. I think an admonition in the page
> > caching section of the docs which outlined the present challenges a
> > developer might face implementing it would probably have done the
> > trick for me when I was first glancing at it. I can open a ticket on
> > that next week, again if I have time.
>
> > It'd be great if these two got in for 1.4.
>
> Agreed - any work you're able to put in on any of these is very welcome.
>
> > 3. Addressing the other stuff is I guess for now a sort of "some day"
> > goal. I continue to feel strongly that it's a worthy goal,
> > particularly given that CSRF and contrib.auth are such fundamental
> > parts of most projects and that they really are the only two things
> > that stand in the way of page caching being a viable option in many
> > projects. If anyone else gets inspired by this goal let me know,
> > otherwise I'm content for the time being to let it stew.
>
> I take your point that it might be possible to do a cache-tweaking API
> that could allow the cache to be more aggressive around auth and CSRF
> with less coupling (though you'd still end up sprinkling cache-specific
> stuff into auth and CSRF with your approach). I remain pretty skeptical
> about whether this is a good idea; it seems like it could significantly
> increase the surface area for bugs in the cache middleware
> implementation, and just generally make the implementation harder to
> maintain with correct behavior. (I have some painful experience in this
> area: CACHE_MIDDLEWARE_ANONYMOUS_ONLY is the one existing, and
> relatively simple, instance of the type of enhanced caching logic you're
> talking about, and I made some fixes to it in the 1.3 cycle that I then
> later had to fix again due to unanticipated side effects of the first
> change). But at this point this is all kind of hand-waving without code
> to look at.
>
> You might also consider what's possible to do outside of core as a
> third-party alternative to Django's caching middleware. When you're
> proposing major and somewhat experimental changes, that can be a
> powerful way to demonstrate that the idea is workable, and makes it a
> lot easier to pick up users and advocates; people are generally more
> willing to try out a third-party tool than to run or test with a patched
> Django.
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6hvEkACgkQ8W4rlRKtE2edBACfdsW7IHoDKBrpwzwGGMx+ww5g
> U+AAoLZLn1CA6c1644kzsnZRZ6xaW60B
> =QBjT
> -END PGP SIGNATURE-

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Sane defaults for Startapp and Startproject

[h3]

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

PROJECT_PATH = os.path.dirname(os.path.abspath(__file__))

...

MEDIA_ROOT = os.path.join(PROJECT_PATH, 'media/')

...

TEMPLATE_DIRS = (
os.path.join(PROJECT_PATH, 'templates/'),
)

This would already be a big time saver.

Another things that would be nice is commonly used code like
TEMPLATE_CONTEXT_PROCESSORS,
some middlewares and apps being commented. This wouldn't hurt anybody
I think.

About adding stuff to views or other files generated by starapp or
startproject .. -1. I think the bare minimum is a win for everybody.

That said, it would be nice to let people write their own templates
for thoses files. Startapp and startproject could look for them
in a path like $USER/.django/templates/newapp/ or $USER/.django/
templates/newproject/ and/or let startapp/startproject accept
a --templates argument to make something like this possible:

python manage.py startapp myapp --templates=/some/path/templates/
newapp/

python manage.py startproject myproject --templates=/some/path/
templates/newproject/


my 2¢


On Oct 18, 9:20 pm, "Joe & Anne Tennies"  wrote:
> On Tue, Oct 18, 2011 at 5:21 PM, Rich Jones  wrote:
> > Hey guys!
>
> > So I've just written a blog post about getting started with Django,
> >http://gun.io/blog/python-for-the-web/, and many of the things here
> > just make me think, 'why doesn't it just do that by default?'
>
> > Here's some of what I propose. I'm not suggesting this be a canonical
> > list of features by any means, I'm just suggesting that django have
> > more convenient default settings. We should look at the most common
> > conventions and best practices and shape the defaults towards them.
>
> > Anyway, I propose that:
>
> > django-admin.py startproject newproj
>
> > should create ./static, ./uploads and ./newproj and ./newproj/
> > templates
>
> I personally +1 on the ./static and ./uploads. I like a starting point for
> putting the static files and the uploaded files. If you don't use static
> files or uploaded files, it'll never get used and deleting a folder is
> pretty easy. For consistency, I'd rename ./uploads to ./media (to match the
> MEDIA_ROOT notation used in settings.py). I'd also fill-in MEDIA_URL
> ('/media'), MEDIA_ROOT, and STATIC_ROOT to work out of the gate. Is there a
> way to statically serve the MEDIA_ROOT folder to '/media/' without
> collectstatic collecting it and/or findstatic finding it by default?
>
>
>
> > in ./newproj/settings.py..
>
> > import os
> > TEMPLATE_DIRS = (
> >    os.path.join(os.path.dirname(__file__), 'templates'),
> > )
>
> +1 for something to accomplish this. I personally don't care how it's done.
>
> > and at the end, the commonly used from local settings import * block.
>
> -1 'from  import *' should always be avoided. You never know what
> can happen down the road that you may override later.
>
>
>
> > I'd also suggest that django-admin.py startproject newapp, if
> > possible, add the new application to the settings.py file if it can be
> > done so safely.
>
> -1 I can see why this seems like a good idea, but I agree that I don't want
> anything touching my settings file. I also think people should learn how to
> start a new app and about manage.py, startapp seems like the obvious answer
> from a teaching perspective.
>
>
>
> > I would also suggest that when making a new application, the most
> > commonly used imports are already there in the py files
> > (render_to_response, HttpResonse, get_object_or_404, etc).
>
> -1 If the exception wasn't so blatently obvious and worded well in the
> error, I might agree.
>
> > Who's with me? :)
>
> > R
>
> > --
> > 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.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> I also want to add another change. Put TEMPLATE_CONTEXT_PROCESSORS in the
> settings.py. I would just it rather be more explicit that you may be using
> these things. If there's any other settings like this that 'slide' a default
> value in w/o your knowledge, I'd like it to add to the settings.py by
> default. Most problems I have helping people is a default value that's not
> explicitly done in the settings.py, so people don't realize it's something
> they can override (or may need to). My criteria would be anything that could
> require modification (within reason) when adding or removing an app to make
> the app work properly.  (See TEMPLATE_CONTEXT_PROCESSORS 

Type casting template filter proposal

[h3]

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 without having to write
custom filters, I use this hack:

{% if request.GET.year == object.date.year|slugify %}
 ...
{% endif %}

While it works, it ain't pretty.

It would be nice if we could simply do this:

{% if request.GET.year == object.date.year|string %}
 ...
{% endif %}

Or this:


{% if request.GET.year|int == object.date.year %}
 ...
{% endif %}

Am I the only one who gets in such situations ? Is there an interest
for such filters ?

If so I might propose a patch..

Regards

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: PHP-inspired user-friendly in-browser DJango install

[h3]

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

Most of them were competent developers, but they didn't see the point
of learning a how to get started with Django because it seemed too
complicated to setup and use for starters. So they preferred to stay
in their comfort zone: PHP.

But when I gave them no other choices than to learn and use Django,
most of them picked it up in less than a week and they "saw the
light".

Just last week my last intern wrote me on facebook to say he continued
to use django back in his country and he think it's really awsome.

The point is not to lower the bar for the "less gifted" as you imply,
it's to lower the bar so more developers can give it a try without
having to learn about every possible approaches and test them to see
which one fits their needs.

If they can get started and play with django with little efforts and
they like it, *then* they will have a good incentive to spend time
learning more about the many ways you can use and deploy it.

I think that's what "lowering the bar" is mostly about. It's not about
making it dumb-friendly by any means.

regards

On Sep 13, 2:07 am, Xavier Ordoquy  wrote:
> Le 13 sept. 2011 à 05:44, Justine Tunney a écrit :
>
> > I agree with you that reducing the barriers to using Django is very 
> > important.  But what we need is not necessarily a web based installer, but 
> > something to get people off the ground so they can start playing around 
> > with Django very quickly.  Back in the day (like circa 2004) the thing that 
> > really helped me learn PHP was this program called EasyPHP which was a 
> > simple Windows based installer that got me up and running and writing code 
> > on my local machine in five minutes.
>
> PHP and Django installation are very different.
>
> For PHP you need a couple of things:
>  - apache or equivalent
>  - php module
>  - configuration tuning
>  - find the apache root to put your files under
>  - a database
>  - database modules for php
> and I might have missed a couple of things
>
> For Django, you'll need:
>  - Python
>  - Django
>
> At this point you can go ahead with the dev server and sqlite. No need to 
> tune/configure things further. I hardly see how one can lower this further.
>
> 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.
>
> Regards,
> Xavier.

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: PHP-inspired user-friendly in-browser DJango install

[h3]

I think pretty much everything have been said about why this isn't
practical and why it's probably quite hard to implement "drop-in" apps
for django.

But there's one point that catched my attention: lowering entry level
for newcomers.

It's not because Django wasn't build with "drop-in" features in mind
that it's not possible to lower the entry level.

Not long ago, I've started working on doing exactly that.

I've written a Python package which makes django development a
breeze.. at least for me so far. It's basically a thin wrapper for
fabric, pip & virtualenv.

Among other sweet things, with simple commands I can:

 * Configure it for an existing project
 * Enter development mode (activate virtualenv, creates it and install
requirements if non-existents)
 * Update clear/requirements, restart apache, syncdb on any stages
(dev, demo, beta, prod)
 * Deploy to any stages (configured ssh keys makes it's even easier)

To be honest the deploy part works, but it still needs a bit of
polishing. However all the other commands are so damn useful in my
everyday work that it's really worth using.

My motivation was twofold:

 1. Type less. I hate having to type the same thing over and over and
Ctrl+R has its limits. I run a business and it's a waste of time. I
often work on more than 10 projects at the same time, if my package
makes me save more than 100 commands over the their lifetime of a
project, it's already worth it.

 2. Collaboration. Where I live Django isn't quite popular, in fact it
barely exists. Even most web design companies and programmers never
heard of it. And most developers never heard of pip, fabric,
virtualenv or even rsync for that matter. I know it sucks, but I have
to deal with it. So the faster I can set an developer on track, the
faster he can generate the profits necessary to pay his salary.

Now don't worry, the reason I write a reply on this thread is not
because I think such tool should be included in django core.

But as a whole, I think the django community would gain a lot by
promoting or even building such external tool.

A different project, aimed at setting developers on track in no time.


I know many tools exists and there's many ways to setup and use
django, but just like Python itself there is optimal ways to do it.

I think 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/ & rtd):
http://code.google.com/p/python-dad/w/list

I welcome comments, suggestions and pull requests :)


On Sep 12, 2:47 pm, Romain Dorgueil <har...@gmail.com> wrote:
> Hi,
>
> it may be my first message on the list ever, but I wanted to put my 2
> cents here.
>
>  From the PHP world, Symfony2 introduced a "web installer" system in its
> "standard" distribution (which is the core + some fancyness).
>
> To me, it's useless unless you want to attract people from a larger
> audience than what the framework is aimed at at first. I personally
> don't want some useless (or use-once at best) code to be around my
> project, and I don't think it's the role of a developper-oriented piece
> of software to provide such things. Of course, a more "newbie-friendly"
> may be "nice-to-have", but imho the "core" of a framework should not
> provide such thing.
>
> Romain.
>
> On 12/09/2011 18:39, Tom Evans wrote:
>
>
>
>
>
>
>
> > On Fri, Sep 9, 2011 at 4:56 PM, Alec Taylor<alec.tayl...@gmail.com>  wrote:
> >> Looks useable.
>
> >> Anyone interested in working with me to port this to DJango?
> > Alec, as other people have mentioned, Django is not Drupal. Drupal is
> > a web application that can be customized using plugins, where as
> > Django is a python library one can use to create web applications.
> > With that in mind, 'porting this to django' is nonsensical - PyLucid
> > uses Django already, and Django is only the framework, not the
> > project.
>
> > The point here is that two different web apps created using Django
> > could have vastly different requirements and installation steps, where
> > as Drupal has a single set of steps to go from nothing to installed.
>
> > In fact, its quite common to have the same project installed and
> > running in completely different manners. For instance on our
> > production servers, all libraries/code/templates, even in house ones,
> > are installed from our internal package repository (an in house pypi
> > clone), where as in development, each package is checked out from
> > subversion in an editable form.
>
> > PyLucid is a good exampl

Re: Suppressed template errors in admin

[h3]

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 admin error
suppression,
but that would mean another setting.. which is to be avoided.

Maybe a better approach would be to simply mark the fallback string as
safe.

Then it would be possible to suppress them like so:

TEMPLATE_STRING_IF_INVALID = ""

This would have the benefit to be more flexible:

TEMPLATE_STRING_IF_INVALID = "!! Invalid var !!" # settings_dev.py

TEMPLATE_STRING_IF_INVALID = "" # settings_prod.py

But this would have side effects on the non-admin templates too.. so
it's not ideal.

Maybe something like this:

TEMPLATE_STRING_IF_INVALID = {'default: '!! Invalid var !!',
'django.contrib.admin': ''}

I think it would pretty much solve the problem, preserve backward
compatibility/behavior and
even allow to suppress errors for any other apps.



 [1] https://github.com/sehmaschine/django-grappelli
 http://jqmobile-sandbox.motion-m.ca/

--

Maxime Haineault

On Aug 24, 7:39 pm, Russell Keith-Magee 
wrote:
> On Wed, Aug 24, 2011 at 11:44 PM, Ole Laursen  wrote:
> > Hi!
>
> > I have a project where setting TEMPLATE_STRING_IF_INVALID has been
> > invaluable in finding problems (for various reasons). The caveat
> > mentioned in the docs don't kick in here because no templates are
> > inherited from elsewhere. Except the admin which unfortunately breaks
> > down in some places.
>
> > I realize there's been a big discussion before about the merits of
> > error suppression. No need to repeat that.
>
> > But is it really not possible to fix admin in the few places it's a
> > problem? Those I've seen so far have one-line fixes where you add an
> > empty variable to the context. Seems harmless to me. I realize
> > cluttering the template itself with a {% if var %} is ugly. No need to
> > go there.
>
> > I don't mind writing a patch for the cases that bother me, but won't
> > do it unless somebody is willing to apply it?
>
> On principle, I have no objection to the idea of making the admin
> templates more robust in the presence of TEMPLATE_STRING_IF_INVALID;
> adding dummy values in the context sounds like a reasonable approach
> -- *if* doing this doesn't undermine broader error handling in the
> templates.
>
> Also -- dummy values may not be the only option. There's also |default
> and |default_if_none filters.
>
> However, in order to evaluate the details, I'd need to see them --
> which unfortunately means a patch (or, at least, an indicative start
> of a patch).
>
> I fully appreciate your desire not to waste your time, though --
> there's no point making a patch if it will be ignored. I would suggest
> the best approach here is to attack this in stages. Provide a patch
> that fixes a small number of uses in a limited number of key
> templates, and poke around on django-dev or on IRC to ask for a
> review. Once that initial patch is approved and/or applied, expand the
> patch until it covers all problematic uses.
>
> Russ %-)

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

RFC on New filter proposal

[h3]

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 with QuerySets rather than simple lists. This makes the
current random implementation not quite useful..

The shuffle filter is also pretty useful and doesn't add much code to
the code base.

Both proposal persever backward compatibility, I would like some
feedback on this idea.

Thanks

 [1] https://code.djangoproject.com/ticket/16647

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.4 Roadmap

[h3]

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:
> Can we make suggestions for new features to be added to the list?

-- 
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.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Introducing Django Ray

[h3]

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/

Comments and feedback are welcome.

Regards,

--

 Maxime Haineault
 Consultant Web / Associé

∞ Motion Média
  http://motion-m.ca
  m...@motion-m.ca
  (450) 374-4822

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Design Czar

[h3]

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 grappelli,
namely refactoring the dom/layout/design and the JavaScript,
you'll have no other choice than to  break backward compatibility.
That's not just a "new feature", that's a deep refactoring.

For that reason I think it would make sense to use the same strategy
than with forms, using a ephemeral namespace (something
like newadmin?) for the development/transition time.

Just my 2¢

--

 Maxime Haineault
 Consultant Web / Associé

∞ Motion Média
  http://motion-m.ca
  m...@motion-m.ca
  (450) 374-4822
On Feb 8, 1:34 am, "j...@jeffcroft.com"  wrote:
> So, unless anyone disagrees with the idea that Wilson should have
> first dibs on this position, it sounds like we have ourselves a Design
> Czar. Or whatever you want to call it. Woot!
>
> On Feb 7, 10:13 pm, Wilson  wrote:
>
> > I just discovered this thread today while I was on my way out of town
> > so I haven't had a chance to formulate a proper response. I'll try to
> > do that later, but for now I'll just jump in quickly and say that I
> > think it would be great to have somebody coordinating design
> > contributions and advocating for their implementation. While I (still)
> > don't have time to do a lot of the heavy lifting, I'm open to the idea
> > of taking a more active role along those lines, with a long term goal
> > of either distributing the responsibility or setting up a system of
> > succession. If my commit bit and existing relationships can help get
> > things off the ground, I'm happy to give it a shot and do what I can.
>
> > Cheers,
> > Wilson

-- 
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...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Design Czar

[h3]

> 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 process of merging two branches, one in which all
the HTML have been refactored with a grid system and semantically
clean widgets implementation with my branch,
in which I rewrote all the JavaScript style using jQuery UI.

When this will be done, there will not be much of the original admin
front end code left, if at all.

As now we tried to stabilize to existing functionalities. But all this
work will hopefully lead to a way more flexible, accessible
and themable admin interface.

The only difference is that we loose some dead weight by dropping
support of old browsers, which allowed us to work
more efficiently and quickly.

[0] 
http://groups.google.com/group/django-grappelli/browse_thread/thread/cf5a1ebfdf4d0370

regards,

--

 Maxime Haineault
 Consultant Web / Associé

∞ Motion Média
  http://motion-m.ca
  m...@motion-m.ca
  (450) 374-4822

On Feb 7, 12:52 pm, "j...@jeffcroft.com"  wrote:
> Several responses:
>
> > First off, there are designers who have contributed great amounts of
> > stuff to the Django community. Nathan Borror has his Basic Apps (which
> > interestingly is a designer contributing code, because that's what he
> > can contribute easily).
>
> Exactly. Christian Metts comes to mind, as well, for a designer who
> has contributed a lot to the Django community (typogrify, compressor,
> inlines, etc.)
>
> > * Design by committee almost invariably sucks / deadlocks.
>
> Right, but I don't necessarily think that means we have to have a
> singer design leader (whatever you want to call him/her) in the Django
> community. Good design requires a singular vision, but there's no
> reason that vision can't be shared by a handful of people. It's when
> there are several different visions competing with one another that
> things go terribly wrong -- usually you end up with a watered down,
> half ass version of all of them, instead of fully realizing any
> particular vision.
>
> > I *don't* think that the design czar necessarily needs to be a
> > rockstar designer. Their job is not to design everything
> > singlehandedly. Their job is to shepherd the design process within
> > django core.
>
> Absolutely agree.
>
> > considering these zones, I guess I´m following jeffs proposal for a
> > team (with, maybe, a team-leader), because no "design czar" I know is
> > really good with all the mentioned topics.
>
> Well, like Idan said, I wouldn't expect a "design czar" or team of
> design czars to be able to contribute in all those "zones." The point
> of the design czar, as we're discussing it now, is not to make every
> design-related change themselves, but rather to shepherd them.
>
> Also, let's keep in mind that the admin interface isn't the only area
> of Django where interaction design is needed. The other *huge* one I
> see is the Django website itself.
>
> > This certainly wasn't my understanding of the situation. It was my
> > understanding that anyone was welcome to contribute, and designs would
> > be judged on merit. This is certainly the sentiment expressed in the
> > FAQ and contribution guide.
>
> The problem with this is that no active member of the core team is
> *qualified* to judge designed based on merit.
>
> > If it's been contradicted by someone else in the core, I'd be
> > interested in hearing how and where  -- if only so that I can
> > get on the same page (or at least work out which page others are on).
>
> I've seen several instances on the lists where you and other members
> of the core team have responded to design-related suggestions and
> questions with, effectively, "That's Wilson's thing." I've also gotten
> this response in person from people at DjangoCon and from the time
> I've spent in Lawrence, as well as in IM conversations with members of
> the core team. This implies that no one but Wilson  is welcome to make
> changes, and/or that if you want to get anything done, design-wise,
> you're going to have to talk to Wilson. Which, since he's MIA, is
> pretty difficult for most people. I'm lucky enough to be friends with
> Wilson, so I *have* talked to him about this stuff many times, but
> those conversations aren't ever "on the record," so to speak -- no
> other member of the core team is around to hear them.
>
> We've absolutely moved past the point in this discussion where
> designers feel unwelcome. The fact that we're still talking about this
> means you are, in fact, interested in finding a way to make use of
> designers' suggestions in Django core. I thank all of you for that.
>
> > So what about the "Design Czar"? In practical terms, what is being
> > called a "Design Czar" is really just another name for "active member
> > of the core team with 

Re: Django Design Czar

[h3]

> 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 
> procedural perspective.

Design is not unlike code, it gets better with a democratic process
and iterations. But the comparison stops there.
The rest is not procedural at all. The only thing you might call
procedural is the prototyping process. The rest is
only a feedback loop.

That said I'm not fond of the term "Design Czar" in the sense that it
put somebody in a place where he was power
over others on something as personal as taste. And even then, the line
can be blurred because an interface (web or
application) can have a beautiful design and be totally unusable or it
can also be really usable and have an horrible
design.

Achieving both on the web is no small feat with the plethora of
devices, screen sizes, browsers etc.. Your
design must be good looking but not too trendy if you want it to last
more than a year.

For some people design is more important than accessibility and it
might cause some friction since both are related
to a very personal experience. The kind of friction that generates
mile long threads over whether or not pale text over
black a background is considered bad practice. UI design is almost a
science, but in which there is such things as
feelings and emotions.

That said I fear that a "Design Czar" will only do more harm than good
on the Django community. I think what the
Django admin app really needs is some kind of Interface Design and
Accessibility Committee that would consist
of one or more lead designers and a team of accessibility geeks.

Then you put them all in a small room with a plastic spoon and lock
the door.

Seriously, yes design is important, but it's also ephemeral. What
looks good today will look old and clunky tomorrow.

On the flip side, accessibility is something that evolve but big lines
does not changes much. It's also something that is
far more subtle than design. It's not something the average developer/
designer is keen to work on without any issues
being raised by the end user.

So in that regard, I think the Django team should concentrate on
giving a generic and accessible interface rather than a
"tasteful" interface. In order to be generic and accessible it's
necessary start with a clean and semantically meaningful
markup and unobtrusive JavaScript that degrades well.

Once you have that you can change the design every year if you want
to. Not that I would suggest to, but programmers
must realize that designs and trends have a much shorter life cycle
than code and thus can hardly be "threated like code",
but accessibility can.

Or let me put it the other way around: Would you like a framework with
the most awesome design you ever saw, but you just
can't change it much without pain and accessibly is only "OK"  .. or a
framework that is really generic and accessible with an OK
design but that you can customize easily ?

Regards,


--

 Maxime Haineault
 Consultant Web / Associé

∞ Motion Média
  http://motion-m.ca
  m...@motion-m.ca
  (450) 374-4822

On Feb 6, 7:56 pm, Alex Gaynor  wrote:
> On Sat, Feb 6, 2010 at 5:03 PM, Idan Gazit  wrote:
> > Hey folks,
>
> > Splitting off 
> > fromhttp://groups.google.com/group/django-developers/browse_thread/thread...,
> > which has an exhaustive discussion about  how django needs to treat
> > design work.
>
> > In the spirit of taking action, I put together this list with Bryan
> > Veloso. My goal is to spark a discussion that will lead to appointing
> > somebody with a few clear goals.
>
> > "Django Design Czar"
>
> > Rationale
> >  * Good design, like good code, is hard to produce.
> >  * Reviewing design is outside the purview and abilities of the core
> > devs.
> >  * The admin is dated, and in need of cleanup/refactoring. A good job
> > would involve major breaking changes, and therefore fits more in the
> > 2.0 timeframe -- but there's a lot of baby steps we can take to clean
> > up the existing admin in the meantime.
> >  * Imposing django's sensibilities on the design process requires a
> > "design czar" in much the same way as we have specific core devs
> > "responsible" for large django subsystems.
> >  * Both the baby-steps and the 2.0 "ground-up" redesign will, like
> > every other part of django, be much more likely to succeed with a
> > designated parent to shepherd it into existence.
> >  * Django can take the lead in integrating designers, not just coders,
> > into the development model of django.
>
> > Responsibilities
> >  * Wearer of the "design hat." Will serve as the go-to for proposals
> > and tickets that involve front-end code.
> >  * Serves as a "design arbiter" -- needs to be somebody that the core
> > devs trust to make design decisions in the spirit of