Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On "strip keyword arg for CharField"
>From http://code.djangoproject.com/ticket/4960
09/14/07 11:28:49 changed by adrian
{{{
Marking as wontfix -- it's too specialized for inclusion in the main library. A
bunch of us in #django-sprint agreed.
}}}
We should think about this decision again. The cc list of #6362 is quite long.
A lot of people (and me)
want something like this. Ten characters (strip=True), I don't want to type
more for this, since I would
use it for 98% of all my CharFields.
Thomas
Steven Davidson wrote:
> Loving v1.2, my first experience with Django: thanks for all the hard work!
>
> However this issue has bitten me twice now. I know it is entirely my
> responsibility to validate and clean user input as required but I really
> can't think of a valid use case where trailing white space would occur.
> Also it can snag a 'feature' in MySQL with unique indexes ignoring
> trailing spaces for comparison purposes.
>
> Any chance of a decision on whether this should appear in 1.3 and in
> what form?
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
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: Class based generic views in 1.3?
On 2 jun, 23:22, Luke Plant wrote:
> On Wednesday 02 June 2010 16:08:24 Roald wrote:
> > class View(HttpRequest):
> > def __init__(self, request, *args, **kwargs):
> > ...
> > super(View, self).__init__(self.content())
> > ...
>
> You mean:
>
> class View(HttpResponse):
> ...
That's what I meant, yes.
> One reason against this is it makes it harder to re-use other views
> from within the View.
I don't really understand what you mean. Do you mean re-using 'good'
old function-views?
> You are forced to mutate the 'self' instance of
> HttpResponse (or else use some nasty hack),
No nasty hacks, just mutate 'self' from inside its class instead of
from outside.
> rather than being able to
> simply return the HttpResponse that might be returned from a utility
> function or a sub-view.
The other options presented in this topic (using __call__, __new__ or
View.as_view) all have their drawbacks, and personally I think I like
__init__ best:
- the __call__-option requires a different interpretation of url
patterns
- the __new__-option is actually a hack, does unexpected things and
thus is less readable, and is I think more complex that the __init__-
option
- the static/class method option is not really an improvement over
global functions, and leads to url patterns with more 'boiler plate
code'
- the __init__-option is only as complex as any Django programmer
should understand.
But even if you think that using __init__ is more complex than writing
a utility function: no worries. Normally you will use it something
like this:
class myview(View):
template_file = 'myapp/template.html'
@property
def context_dict(self):
return {'authenticated':
self.request.user.is_authenticated()}
... which you can hardly call complicated.
--
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: Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"
I haven't had a reply to this, which could have been bad timing posting it around when the conference was happening, or it could be as I gave the background first rather than summarising what I was after first so people skipped over reading it :). The ticket's languished for a couple of years now - I've submitted what I think is a better patch on the ticket and included some tests in the patch, but I've not previously done any work on Django before and it could do with someone more versed in the postgresql back-end for Django to take a look at it and advise me on how to get the ticket moved along (and whether my tests are sufficient and in a good enough place in the test suite). Regards, Matt On May 25, 12:00 pm, Matt Hoskins wrote: > I think (from squinting at the code) that in Django 1.2 m2m field > updates now use the object save code to add relationships even where > there aren't specifically defined intermediate classes, whereas > previously the code did its own insert in such cases. So as a > consequence last_insert_id gets called as part of those m2m field > updates in cases where it previously didn't. > > Because the table names for the m2m fields are generated from the > class name and the field name together there is scope for them to be > quite long and to hit the identifier limits and thus under postgresql > the sequence name auto-generated for the id will not confirm to what > the code currently guesses it to be (as per #8901) and so there'll be > an error on updating m2m fields with 1.2 and postgresql in cases where > there is a long enough field and class name and where it worked fine > in 1.1. I've hit this myself on updating to 1.2. > > As #8901 hasn't been touched in a year (and has been sitting around > since 2008) I thought I'd have a look at it myself. I've not submitted > patches or tests for Django before, but I've had a stab at both for > #8901. > > I'm not sure how to get this issue moved along closer to having a fix > incorporated - it could certainly do with someone more expert than me > in django and with postgresql knowledge reviewing my patch and tests > (I've not flagged the issue has "has tests" as I skipped adding a test > for one change for reasons I've noted on the issue, although maybe I > should flag it thus). > > Regards, > Matt > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
missing in SVN branches/releases/1.2.X
Hi, will there be a SVN branch releases/1.2.X? For 1.0 and 1.1 it exists: http://code.djangoproject.com/browser/django/branches/releases Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: missing in SVN branches/releases/1.2.X
On Thu, Jun 3, 2010 at 5:33 PM, Thomas Guettler wrote: > Hi, > > will there be a SVN branch releases/1.2.X? > > For 1.0 and 1.1 it exists: > > http://code.djangoproject.com/browser/django/branches/releases Yes - a 1.0.X and 1.1.X branch exists - but they weren't created until some time after the release of 1.0 and 1.1 respectively. A branch is only required when trunk development differs from bugfix development -- that is, when we start adding features to trunk. Until we start adding features, having two branches (trunk and stable) just makes more work for the core team. I would expect to see a branch at some point in the next couple of weeks. Yours, Russ Magee %-) -- 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: Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"
On Thu, Jun 3, 2010 at 4:23 PM, Matt Hoskins wrote: > I haven't had a reply to this, which could have been bad timing > posting it around when the conference was happening, or it could be as > I gave the background first rather than summarising what I was after > first so people skipped over reading it :). It's probably more the former than the latter; I'm still working through the disaster that is my Post-DjangoCon inbox :-) If it makes you feel any better, your original mail was on my list of things to look at. There's also a small dose of "exhausted after the 1.2 final push" - those in the core team that weren't at DjangoCon are taking a short break from proceedings to recuperate. > The ticket's languished for a couple of years now - I've submitted > what I think is a better patch on the ticket and included some tests > in the patch, but I've not previously done any work on Django before > and it could do with someone more versed in the postgresql back-end > for Django to take a look at it and advise me on how to get the ticket > moved along (and whether my tests are sufficient and in a good enough > place in the test suite). I've just given your patch on #8901 a quick inspection, and it looks good enough to me to progress to RFC (which I've done). I'm hoping to have some time tonight to commit some patches; I'll try to put this on the list. Yours, Russ Magee %-) -- 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: Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"
Hi Russ, > I've just given your patch on #8901 a quick inspection, and it looks > good enough to me to progress to RFC (which I've done). I'm hoping to > have some time tonight to commit some patches; I'll try to put this on > the list. Thanks for taking a look at it - I was just wanting to make sure my updated patch was on someone's radar to get looked at eventually so it's great to hear you've picked it up (it's not urgent at all for me - just thought I'd check before it slipped my mind :). Hope you're having some luck getting your inbox mopped up! Regards, Matt -- 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.
Proposal: Improvements for django.forms
Hello, I would like to propose some improvements for django.forms. But it is seven quite independent proposals - one mail would be to long, seven emails would too many emails. So I have created wiki page - is it a good procedure? The wiki page: http://code.djangoproject.com/wiki/ImprovementsForDjangoForms Petr Marhoun -- 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: Static media handling - ticket 12323
Am 28.05.2010 um 01:27 schrieb burc...@gmail.com: > Hi all, > >> - a media files path resolver -- following a similar directory structure as >> the app templates loader (/media/ vs. /templates/) >> - build_static -- a mangement command that'll collect media files from apps >> from various locations using the media files path resolver and uses a file >> storage backend to copy (or link to) the found files (file storage backend >> by default), used during deployment >> - an extended media file serving view that uses the media files path >> resolver (in debug mode), backwards compatible replacement for >> django.core.servers.basehttp.AdminMediaHandler > > Couldn't agree more. But three more points: > 1) Media files are linked from applications forms, so what will happen > if user rename an app? > Do we need some config piece for this kind of reverse? > Something like app_media(app_name=None) function and APP_MEDIA? > > 2) More generally, we need per-application settings to handle this > sort of configuration problems. > One that will be autodiscovered like templates and admin. And it can > contain additive variables for MEDIA, like suggested in my > configuration proposal: > http://groups.google.com/group/django-developers/browse_thread/thread/b7339d8577567d95 That seems overly complicated for the use case of app media. For the app level configuration though, I'd say we should wait a little for the summer of code to progress. > 3) I've seen a solution recently that generates apache and lighttpd > install scripts, found it much better than symlinks for media in > production. > But this one definitely needs additive variables and per-application > configuration! In case you mean the django-staticmedia [1] app -- I think it's doing fine outside of Django -- given the fact that generating deployment config files isn't a core goal of Django. Jannis 1: http://pypi.python.org/pypi/django-staticmedia -- 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: Static media handling - ticket 12323
Am 30.05.2010 um 05:54 schrieb BrettH:
> +1 on Option 2.
>
> I have written a basic deployment app (not quite ready for release
> yet) that deploys a virtualenv for each version of your project,
> roughly equivalent to Google App Engine. I specifically need to split
> out the USER_MEDIA so that it isn't versioned. Internally if the
> developer does not use the setting I will default to the MEDIA_ROOT
> anyway.
Note, my propsal isn't about creating a deployment tool but to make sure Django
is prepared for the increasing number of apps that ship with media files.
django-staticfiles is in use today due to Pinax and doesn't make assumptions
about your custom deployments. (e.g. override the storage backend to build the
media on S3)
> I like the limited focus of this proposal. USER_MEDIA nicely describes
> something that is not specifically meant or available to be deployed
> by default as part of the app, and is a reasonable convention to
> encourage developers to split their directories from the start.
Agreed, the ambiguity of the MEDIA_ROOT setting is unfortunate but not that
easy to fix in a backwards incompatible way if we also want to solve the app
media problem.
> A more complicated discussion is that around assumed app media
> directories. I'm inclined to think that admin gives the precedent to
> declare a default media directory per app, a convention that can be
> backed up by management command to link/consolidate by app name for
> production which other apps already do, but this in turn opens the can
> of worms that is settings when overriding defaults. I think ponies
> will cry if this proposal gets extended to try and include too much.
Honestly, I strongly believe this is a topic in which Django needs to provide
optional helpers to make it easier to ship non-Python files. Since a vast
amount of apps out there already ship with media files, nicely wrapped in
Python packages, ready to be installed with pip, Django only needs to be made
aware of those conventions.
Speaking of which, the admin is actually a bad example since it uses an own
legacy WSGI handler ("AdminMediaHandler") from long ago to serve its media
files. staticfiles abstracts that feature, is backwards compatible and follows
the simple idea of namespaces -- similar to how app template directories are
prefixed with the app name, /media//*. So say you want to
ship media files with your app 'my_blog', it'd look like this:
my_blog
├── __init__.py
├── admin.py
├── media
│ └── my_blog
│ ├── css
│ │ ├── base.css
│ │ └── forms.css
│ ├── img
│ │ └── logo.png
│ └── js
│ └── ads.js
├── models.py
└── views.py
And you'd be able to use //img/logo.png in your
templates to point to the right location of your app media files. Either use
staticfiles' file serving view (for debugging), which knows how to resolve the
relative path to the file included in the app, or use the build_static
management command, that can be called from a fabric script during deployment.
FWIW, I've started with an experimental branch at
http://github.com/jezdez/django/tree/staticfiles if you want to follow along.
Jannis
> On May 28, 1:23 am, Luke Plant wrote:
>> A Django 1.3 proposal. It is a pretty small feature/change in some
>> ways, but needs some discussion.
>>
>> = Motivation =
>>
>> This is intended to make it easier to cope with the distinction
>> between user provided media and developer provided media. This is a
>> significant pain point when it comes to source
>> control/deployment/backup.
>>
>> For example, it would be much better when uploading my source if I
>> could do 'rsync --delete', so that the files on the server are exactly
>> what I expect - extra files can cause all kinds of bugs. But I can't
>> do that, as it would delete all the user uploaded media (or at least
>> the symlinks to it). Nor can I simply upload to a fresh directory - I
>> would still need to mess around with symlinks or moving files to get
>> user uploaded media where it is expected to be.
>>
>> Also, for security it would be good to have the whole source code
>> directory (including templates, javascript etc) to be write protected
>> from the point of the webserver. But user uploaded files mess that
>> up.
>>
>> = Options =
>>
>> We could:
>> 1) add 'STATIC_URL' and use it for widgets and all other media.
>> 2) add 'USER_MEDIA_URL' and 'USER_MEDIA_ROOT' and use them for file
>> storage.
>>
>> (using backwards compatible defaults either way).
>>
>> If 1), then, additionally, do we need 'STATIC_ROOT' as well? What
>> for? It wouldn't be used anywhere in Django.
>>
>> I was going to go for 1), like the ticket suggests, but I now think
>> that 2) is a much better idea.
>>
>> I strongly suspect that static media are far more common than user
>> uploaded files, so doing 2) will require far fewer changes to existing
>> apps. Also, I suspect that almost all direct use of MEDIA_URL in apps
Re: Proposal: Nice(r) error messages when a user-provided module fails to load
On Thu, Jun 3, 2010 at 4:38 AM, Russell Keith-Magee wrote: > [...] > Regarding #13480 specifically -- I haven't dug into the problem in > detail, but the approach of telling exceptions apart by inspecting the > number of arguments doesn't fill me with joy. One of the changes in > 1.2 was to improve the ability to distinguish between import errors > caused by missing modules, and import errors caused by problems with > the module being imported; I'd like to think that we are now in a > better position to report the underlying cause of ImportErrors rather > than trying to wrap them. Actually, the check against len(e.args) isn't intended to tell errors apart, just to avoid IndexError when we do check. The real test is the one just after (isinstance(e.args[1], ImportError)). Strictly speaking, len(e.args) could test for < 2, but using < 3 adds a little sanity checking for free. On the other hand, I freely admit that it's not the most elegant solution, hence my continuous grumblings to the effect of "It's a proof-of-concept; feel free to change it!" I put the patch together for two reasons: 1. To solve the immediate problem I had. 2. Because IRC wasn't certain that it was fixable without a major rewrite of Django. Elegance and the Right Way to do things don't factor in to either of those, so I hacked together a quick-and-dirty patch that sufficed. > Also - the patch appears to be against 1.0.2; does the patch still > apply to trunk? 1.2 saw a number of changes to the view handling and > the module loading code, so it wouldn't surprise me if the patch no > longer applies. Per the bug, "Code inspection suggests that the problem still exists in SVN, and the attached patch applies to SVN successfully, albeit with some grumbling about the line numbers being wrong." I also gather that axiak, who bumped the bug version to SVN, tested the patch to see how it worked, presumably against trunk. I have not personally tested it in action against trunk, but all signs point to it working. > [1] http://code.djangoproject.com/wiki/BetterErrorMessages The issues listed there all appear to be cases where error messages are given, but are insufficient or misleading. This issue is, to my mind, somewhat more severe, because no error message is shown to the developer at all. Django itself crashes, the webserver spits out an error, and the real error gets hidden in the server logs. > I'm not convinced there will be a strong overlap here. I'm sure > Arthur's code will probably overlap - after all, he is dealing with > model loading - but I don't see that what he is doing directly relates > to the errors that are raised during loading. I wouldn't be at all > surprised if his new importer just inherits whatever error handling > already exists. Makes sense. Still, it's a good idea for the two to be aware of each other, to avoid stepping on each other's toes more than necessary. -FM -- 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
I tend to agree that #6362 should be reconsidered. Realistically
speaking, almost all form fields aren't going to want leading or
trailing spaces. The default case, therefore, should strip them,
while allowing the app writer to override that behaviour in the small
minority of cases where the whitespace is actually important.
Standard design principle: "Make the common case easy, and the
uncommon case possible." I have yet to write a field where keeping
the whitespace would be useful, and have written many where it could
cause problems.
-FM
On Thu, Jun 3, 2010 at 7:12 AM, Thomas Guettler wrote:
> On "strip keyword arg for CharField"
>
> From http://code.djangoproject.com/ticket/4960
> 09/14/07 11:28:49 changed by adrian
> {{{
> Marking as wontfix -- it's too specialized for inclusion in the main library.
> A bunch of us in #django-sprint agreed.
> }}}
>
> We should think about this decision again. The cc list of #6362 is quite
> long. A lot of people (and me)
> want something like this. Ten characters (strip=True), I don't want to type
> more for this, since I would
> use it for 98% of all my CharFields.
>
> Thomas
>
> Steven Davidson wrote:
>> Loving v1.2, my first experience with Django: thanks for all the hard work!
>>
>> However this issue has bitten me twice now. I know it is entirely my
>> responsibility to validate and clean user input as required but I really
>> can't think of a valid use case where trailing white space would occur.
>> Also it can snag a 'feature' in MySQL with unique indexes ignoring
>> trailing spaces for comparison purposes.
>>
>> Any chance of a decision on whether this should appear in 1.3 and in
>> what form?
>
>
> --
> Thomas Guettler, http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>
> --
> 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.
>
>
--
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: Proposal: Improvements for django.forms
I think grouping issues and features requests is always a good thing :) Now about the "Model fields with not-default values". With 1.2 something like that landed to override the widget for fields on ModelForms, but I agree that sometimes you need to change a label or help text for a specific form instance. So that's a +1. About the others; I'm not sure, On Jun 3, 1:41 pm, "petr.marhoun" wrote: > Hello, > > I would like to propose some improvements for django.forms. But it is > seven quite independent proposals - one mail would be to long, seven > emails would too many emails. So I have created wiki page - is it a > good procedure? > > The wiki page:http://code.djangoproject.com/wiki/ImprovementsForDjangoForms > > Petr Marhoun -- 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: Proposal: Improvements for django.forms
On Thu, Jun 3, 2010 at 7:41 PM, petr.marhoun wrote:
> Hello,
>
> I would like to propose some improvements for django.forms. But it is
> seven quite independent proposals - one mail would be to long, seven
> emails would too many emails. So I have created wiki page - is it a
> good procedure?
It's not really ideal, because it makes the initial phases of much
harder. Starting a wiki page is a good idea when you have a single,
very complex idea, and you want to track the evolution of planning.
However, if you have lots of little ideas, you would be better served
with a single email so that we have something to hang the discussion
on.
That said, here's some initial feedback:
1. Fieldsets
This is effectively just exposing an Admin capability into general
forms; I'm +1 to this general idea.
One complication I can see is how to handle iteration. "for field in
form" currently assumes that all the fields are ungrouped. How does
this change when fieldsets are introduced? Does iterating over the
form give you fieldsets, which are themselves iterable? Do you need to
iterate over "for fieldset in form.fieldsets", with "for field in
form" iterating over the raw fields independently of the fieldsets?
I'm also not entirely clear how we can/should implement this with BaseForm.
So - more detail required, but generally +1 from me.
I would also point out that one of the acceptance criteria for this
proposal should be backporting the changes into Admin. Admin should be
the best example of us eating our own dogfood; however, the tools in
admin have a habit of evolving on their own a little bit too much. If
this give us an opportunity to do some of this housekeeping, I'd call
that a big win.
2. Inlines
I'm not sure I see the benefit of this. Why does inline processing
need to be crammed into the base form?
3. Better API for formsets
Formsets are complex beasts, to be sure. However, I'm extremely wary
of proposals that advocate widespread changes to existing API.
Backwards compatibility will be a *huge* issue here - however broken
the current implementation may be, we can't change the conditions
under which forms validate at present.
That said, I'm sure there are validation edge cases that can be
legitmately called bugs, and that aren't tested at the moment. If
cleaning up the formset API allows us to fix those edge cases, all the
better.
So - a tentative +0 to this idea, but most of the effort will be in
proving that you're fixing bugs, not breaking features.
4. Model fields with not-default values
Isn't this mostly what the new widget Meta argument does?
5. Parameters "template" and "attrs" for forms, formsets, fieldsets,
forms, (bound) fields and widgets
6. Support for (X)HTML5 and legacy HTML
I strongly suspect that these two may be covered by something I
discussed with Jacob at DjangoCon. Broadly, the proposal is to
deprecate the {{ field }} and {{ form }} approach to template
rendering in favor of a template tag {% render field %} and {% render
form %}; these template tags would allow you to customize the way that
individual fields, fieldsets and forms are rendered, including
controlling doctype compliance.
If you want to override the way fields or forms are rendered, you will
be able to subclass the base render template tag, override the
rendering behavior, and re-register the tag (or register it under a
different name).
I've been tinkering with this since DjangoCon.eu; I hope to be able to
present something once I surface from jetlag and the backlog of mail
and other tasks in my inbox.
7. Requests in forms
I suspect the answer on this one will be no for the simple reason of
backwards compatibility. A request attribute is only really useful if
it is ubiquitous, and there's no way to make it ubiquitous without
breaking backwards compatibility. Truth be told, having the request
around would have made CSRF a lot easier, but it wasn't so we had to
fall back on {% csrf_token %}.
This is also something that can be implemented in user-space by
subclassing a form and enforcing the request argument. So, call this a
-0 from me.
There's some brief feedback. My one additional request is to try not
to be too ambitious. You've proposed a lot of work here; frankly, if
you only got (1) finished for 1.3 I would consider it to be a major
win.
Yours,
Russ Magee %-)
--
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: Re: Proposal: Improvements for django.forms
Hi, what about adding one more layer on top of forms: a page object why? 1) because it would be nice to have other widgets besides forms, too (e.g. a (ajax-)table (like in the admin views) 2) having a page object could ease the mess with media files from forms and the rest of a page (e.g. avoid double include of jquery in a html page) 3) a very old idea is to have a html page with no html in it - just code (so a template is only needed for special cases) and than having different renderer engines (as_table functions like) to produce html or something else like XUL for the same page / form regards Henrik -- 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: Static media handling - ticket 12323
Ok yes seems like a slam dunk.. hell how about an --install-media for
python setup.py install ;)
On Jun 3, 10:18 pm, Jannis Leidel wrote:
> Am 30.05.2010 um 05:54 schrieb BrettH:
>
> > +1 on Option 2.
>
> > I have written a basic deployment app (not quite ready for release
> > yet) that deploys a virtualenv for each version of your project,
> > roughly equivalent to Google App Engine. I specifically need to split
> > out the USER_MEDIA so that it isn't versioned. Internally if the
> > developer does not use the setting I will default to the MEDIA_ROOT
> > anyway.
>
> Note, my propsal isn't about creating a deployment tool but to make sure
> Django is prepared for the increasing number of apps that ship with media
> files. django-staticfiles is in use today due to Pinax and doesn't make
> assumptions about your custom deployments. (e.g. override the storage backend
> to build the media on S3)
>
> > I like the limited focus of this proposal. USER_MEDIA nicely describes
> > something that is not specifically meant or available to be deployed
> > by default as part of the app, and is a reasonable convention to
> > encourage developers to split their directories from the start.
>
> Agreed, the ambiguity of the MEDIA_ROOT setting is unfortunate but not that
> easy to fix in a backwards incompatible way if we also want to solve the app
> media problem.
>
> > A more complicated discussion is that around assumed app media
> > directories. I'm inclined to think that admin gives the precedent to
> > declare a default media directory per app, a convention that can be
> > backed up by management command to link/consolidate by app name for
> > production which other apps already do, but this in turn opens the can
> > of worms that is settings when overriding defaults. I think ponies
> > will cry if this proposal gets extended to try and include too much.
>
> Honestly, I strongly believe this is a topic in which Django needs to provide
> optional helpers to make it easier to ship non-Python files. Since a vast
> amount of apps out there already ship with media files, nicely wrapped in
> Python packages, ready to be installed with pip, Django only needs to be made
> aware of those conventions.
>
> Speaking of which, the admin is actually a bad example since it uses an own
> legacy WSGI handler ("AdminMediaHandler") from long ago to serve its media
> files. staticfiles abstracts that feature, is backwards compatible and
> follows the simple idea of namespaces -- similar to how app template
> directories are prefixed with the app name, /media//*.
> So say you want to ship media files with your app 'my_blog', it'd look like
> this:
>
> my_blog
> ├── __init__.py
> ├── admin.py
> ├── media
> │ └── my_blog
> │ ├── css
> │ │ ├── base.css
> │ │ └── forms.css
> │ ├── img
> │ │ └── logo.png
> │ └── js
> │ └── ads.js
> ├── models.py
> └── views.py
>
> And you'd be able to use //img/logo.png in your
> templates to point to the right location of your app media files. Either use
> staticfiles' file serving view (for debugging), which knows how to resolve
> the relative path to the file included in the app, or use the build_static
> management command, that can be called from a fabric script during deployment.
>
> FWIW, I've started with an experimental branch
> athttp://github.com/jezdez/django/tree/staticfilesif you want to follow along.
>
> Jannis
>
>
>
> > On May 28, 1:23 am, Luke Plant wrote:
> >> A Django 1.3 proposal. It is a pretty small feature/change in some
> >> ways, but needs some discussion.
>
> >> = Motivation =
>
> >> This is intended to make it easier to cope with the distinction
> >> between user provided media and developer provided media. This is a
> >> significant pain point when it comes to source
> >> control/deployment/backup.
>
> >> For example, it would be much better when uploading my source if I
> >> could do 'rsync --delete', so that the files on the server are exactly
> >> what I expect - extra files can cause all kinds of bugs. But I can't
> >> do that, as it would delete all the user uploaded media (or at least
> >> the symlinks to it). Nor can I simply upload to a fresh directory - I
> >> would still need to mess around with symlinks or moving files to get
> >> user uploaded media where it is expected to be.
>
> >> Also, for security it would be good to have the whole source code
> >> directory (including templates, javascript etc) to be write protected
> >> from the point of the webserver. But user uploaded files mess that
> >> up.
>
> >> = Options =
>
> >> We could:
> >> 1) add 'STATIC_URL' and use it for widgets and all other media.
> >> 2) add 'USER_MEDIA_URL' and 'USER_MEDIA_ROOT' and use them for file
> >> storage.
>
> >> (using backwards compatible defaults either way).
>
> >> If 1), then, additionally, do we need 'STATIC_ROOT' as well? What
> >> for? It wouldn't be used anywhere in Django.
>
> >> I was going
Re: Proposal: modular django configuration
Hi all,
I've written a prototype, and put it on
http://github.com/buriy/django-configurator.
It has few good design decisions, and few maybe not that good.
Anyway, I consider it as a good addition to app loading GSoC Proposal,
which is currently being worked on.
The key highlights of the implementation are the following:
The first concept is the options object. Options can be global or
belong to applications:
>>> from configurator import options
>>> options.KEY = 1
>>> options.apps['myapp'].KEY = 2
>>> type(options)
>>> type(options.apps)
>>> type(options.apps['myapp'])
If the key is missing, DictList is provided:
from configurator import options
>>> KEY = options.SOME_KEY
>>> type(KEY)
>>> id(KEY) == id(options.SOME_KEY)
True
Next concept is DictList. DictList is options holder and it allows one
to set a global option in advance, providing data from one module to
another, not having to deal with applications order in INSTALLED_APPS.
Can be used as an ordered set:
>>> KEY += 'xxx'
>>> KEY
['xxx']
>>> KEY -= 'yyy'
>>> KEY += 'yyy'
>>> KEY
['xxx', 'yyy']
>>> KEY -= 'xxx'
['yyy']
In Django, this can be used for AUTHENTICATION_BACKENDS,
TEMPLATE_CONTEXT_PROCESSORS, MIDDLEWARE_CLASSES, ADMINS, LANGUAGES and
other settings.
Or as an ordered dict:
>>> D = DictList()
>>> D['abc'] = 'def'
>>> D['key'] = 'value'
>>> D.default = '(default)'
>>> D
{default=(default), 'abc': 'def', 'key': 'value'}
In Django, this can be used for DATABASES setup, and, i hope, in 1.3,
for LOGGING setup and APP_MEDIA setup.
Currently I'm not using SortedDict for DictList implementation to not
depend on Django.
The next concept is autodiscover. It allows you to have different
configuration bits for every application or for different servers.
For basic use in django applications, you can put this call in the end
of the settings.py:
autodiscover(locals())
It does the following:
1) puts all written in caps settings from settings.py into options,
wrapping lists, tuples and dicts into DictList
2) iterates over options.DISCOVERY_ORDER, defined by default as the following:
options.DISCOVERY_ORDER = [
ListFiles(options.lazy.CONF, 'global'),# conf/global.py
ListFiles(options.lazy.CONF, options.lazy.SITE), # conf/.py
ListFiles(options.lazy.INSTALLED_APPS, 'conf'), # app1/conf.py
ListFiles(options.lazy.APP_CONF, options.lazy.INSTALLED_APPS), #
conf/app1.py
ListFiles(options.lazy.CONF, 'global', '_overrides'), #
conf/global_overrides.py
ListFiles(options.lazy.CONF, options.lazy.SITE, '_overrides'), #
conf/_overrides.py
]
Every application can update any option in such files.
Please note, that this DISCOVERY_ORDER is lazy, and you can set
options.CONF to your own folder in settings.py, or do the similar
thing with other options before DISCOVERY_ORDER will be evaluated.
3) writes updated settings back to settings.py
If you don't want to change anything in settings.py, you can do
autodiscover(), update_options() and update_back_settings() manually
in any moment of time.
Exceptions, raised in configuration modules, are isolated. If one of
your conf files failed to load, console message will appear, or, in
addition to the message, application will fail with traceback if
console is not a tty.
Known issues: since global django settings are read and set
independently from settings.py, they don't know anything about each
other. So if you do AUTHENTICATION_BACKENDS += 'logins.MyBackend', no
django.contrib.auth.backends.ModelBackend will be added.
On Fri, May 28, 2010 at 6:19 AM, burc...@gmail.com wrote:
> Hi everybody,
>
> Everyone loves the way templates are discovered in django.
> No one loves settings.py that much.
>
> This is proposal on how to improve situation significantly.
>
> Configuration facility is suggested in addition to django.conf.settings.
> Configuration is going to be put into conf/ directory of the project
> (or settings/ -- just set config.global.CONFIG).
>
> :: settings.py ::
> from django.conf import config
> from os.path import dirname, abspath, join
> ROOT = dirname(abspath(__name__)) # type 'str'
> INSTALLED_APPS = ...
>
> config.global.ROOT = ROOT
> config.global.CONFIG = join(ROOT, 'conf')
> config.autodiscover()
> # config.global is in fact a synonym for settings
>
> :: conf/global.py ::
> # runs before the app settings
> from django.conf import config
> from os.path import dirname, abspath
> ROOT = config.global.ROOT # type 'str', empty if not set.
> config.global.JQUERY.default = JQUERY = ROOT +
> 'static/js/jquery-1.3.2-min.js' # type 'dict', setting default value
> for missing items
> config.global.JQUERY['1.3.2'] = JQUERY # type 'unordered dict with
> default value', now setting arbitrary key
> config.global.MEDIA += [ROOT + 'static/js/'] # type 'ordered set with
> default value'
> config.global.DATABASES['default'] = {...} # backward-compatibility,
> so using 'default' not .default!
> # Note: after type is set for constant, the type can't be changed.
> # Note: please set to
Re: Proposal: Improvements for django.forms
On Jun 3, 2:57 pm, Russell Keith-Magee wrote: > On Thu, Jun 3, 2010 at 7:41 PM, petr.marhoun wrote: > > Hello, > > > I would like to propose some improvements for django.forms. But it is > > seven quite independent proposals - one mail would be to long, seven > > emails would too many emails. So I have created wiki page - is it a > > good procedure? > > It's not really ideal, because it makes the initial phases of much > harder. Starting a wiki page is a good idea when you have a single, > very complex idea, and you want to track the evolution of planning. > However, if you have lots of little ideas, you would be better served > with a single email so that we have something to hang the discussion > on. > > That said, here's some initial feedback: > > 1. Fieldsets > > This is effectively just exposing an Admin capability into general > forms; I'm +1 to this general idea. > > One complication I can see is how to handle iteration. "for field in > form" currently assumes that all the fields are ungrouped. How does > this change when fieldsets are introduced? Does iterating over the > form give you fieldsets, which are themselves iterable? Do you need to > iterate over "for fieldset in form.fieldsets", with "for field in > form" iterating over the raw fields independently of the fieldsets? > > I'm also not entirely clear how we can/should implement this with BaseForm. > > So - more detail required, but generally +1 from me. OK, more details: If fieldsets would be defined, fields would be concatenation of fields from individual fieldsets. So methods as_table, as_ul and as_li and "for field in form" would work as now. But if you want to really use fieldsets, you have to iterate fieldsets in your templates. I think I am able to implement it - but the first step is to decide what to implement. > I would also point out that one of the acceptance criteria for this > proposal should be backporting the changes into Admin. Admin should be > the best example of us eating our own dogfood; however, the tools in > admin have a habit of evolving on their own a little bit too much. If > this give us an opportunity to do some of this housekeeping, I'd call > that a big win. Yes, it is difficult. I think that admin has one kind of functionality (not only forms, but also for example pagination, ordering or filtering) in too many places (model admin, helper methods and classes, templates, template tags ), it could be encapsulated in one class. But I do not think that it is possible to change without breaking backward-compatibility. So for forms and fieldsets I would propose only extract meta attributes of forms as class attributes of model admin. > 2. Inlines > > I'm not sure I see the benefit of this. Why does inline processing > need to be crammed into the base form? Because I want to edit object including related objects. So the object's form is valid if all inlines are valid. And saving the objects means to save all inlines. Yes, it is possible to iterate all inlines and decide if they are valid and then save them once by once - but I thing it is very common activity and it should be in core forms. And what if I want to edit my objects with general views (for example class model views which could be in 1.3)? How should I tell the general view I want to edit also related objects? > 3. Better API for formsets > > Formsets are complex beasts, to be sure. However, I'm extremely wary > of proposals that advocate widespread changes to existing API. > Backwards compatibility will be a *huge* issue here - however broken > the current implementation may be, we can't change the conditions > under which forms validate at present. > > That said, I'm sure there are validation edge cases that can be > legitmately called bugs, and that aren't tested at the moment. If > cleaning up the formset API allows us to fix those edge cases, all the > better. > > So - a tentative +0 to this idea, but most of the effort will be in > proving that you're fixing bugs, not breaking features. Current API for using of validated formsets is: - cleaned_data - I think that this property is broken by design because valid formsets can have invalid forms without cleaned_data (if they should be deleted). - deleted_forms - it is useful as it is. - ordered_forms - it is useful as it is but it would be redundant if there would be more general property working also with unordered formsets. And there is no API for the my main requirement: give me all filled and valid forms and nothing more, possible ordered (if can_order is True). I propose new property which give me these forms. So my proposal in other words: 1. Simplify formset validation with full backward-compatibility (minus bugs). 2. Add new property "cleaned_forms" which do the right thing. 3. Possible deprecate "ordered_forms" (because it is redundant). 4. Possible deprecate "cleaned_data" (because it is broken by design - there is note in code: "# Maybe this should just go away?"). > 4. Model fiel
Re: Class based generic views in 1.3?
On Jun 2, 6:20 pm, Ben Firshman wrote: > Yeah, this idea came up at the sprints, but it's a little too magic for my > tastes. I dunno... is __new__ really more magic than having a __call__ method that magically copies the instance you call it on? That certainly breaks my expectations. Django doesn't shy away from "magic" in other areas where it makes for a usable API. The things that happen to model and form fields certainly violate the initial expectations of a Python programmer; but it turns out that most people are happy to write readable models and don't care what's happening under the hood, and those who do care can learn a little something about metaclasses. Seems to me that __new__ is a relatively beautiful solution to a thorny problem: it lets people use class views in all the same ways they use function views while maintaining thread-safety, it maintains the "callable that returns HttpResponse" contract, and most people won't ever see or care about the "magic" that makes it work. +1 for __new__. Carl -- 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: Class based generic views in 1.3?
On 3 Jun 2010, at 17:45, Carl Meyer wrote: > On Jun 2, 6:20 pm, Ben Firshman wrote: >> Yeah, this idea came up at the sprints, but it's a little too magic for my >> tastes. > > I dunno... is __new__ really more magic than having a __call__ method > that magically copies the instance you call it on? That certainly > breaks my expectations. > > Django doesn't shy away from "magic" in other areas where it makes for > a usable API. The things that happen to model and form fields > certainly violate the initial expectations of a Python programmer; but > it turns out that most people are happy to write readable models and > don't care what's happening under the hood, and those who do care can > learn a little something about metaclasses. Seems to me that __new__ > is a relatively beautiful solution to a thorny problem: it lets people > use class views in all the same ways they use function views while > maintaining thread-safety, it maintains the "callable that returns > HttpResponse" contract, and most people won't ever see or care about > the "magic" that makes it work. > > +1 for __new__. One advantage of using __call__ over __new__ is passing arguments to __init__. That's handy for lazily configuring views: (r'', DetailView(queryset=Thing.objects.all()) Ben -- 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: Class based generic views in 1.3?
On Thu, Jun 3, 2010 at 12:10 PM, Ben Firshman wrote: > > On 3 Jun 2010, at 17:45, Carl Meyer wrote: > >> On Jun 2, 6:20 pm, Ben Firshman wrote: >>> Yeah, this idea came up at the sprints, but it's a little too magic for my >>> tastes. >> >> I dunno... is __new__ really more magic than having a __call__ method >> that magically copies the instance you call it on? That certainly >> breaks my expectations. >> >> Django doesn't shy away from "magic" in other areas where it makes for >> a usable API. The things that happen to model and form fields >> certainly violate the initial expectations of a Python programmer; but >> it turns out that most people are happy to write readable models and >> don't care what's happening under the hood, and those who do care can >> learn a little something about metaclasses. Seems to me that __new__ >> is a relatively beautiful solution to a thorny problem: it lets people >> use class views in all the same ways they use function views while >> maintaining thread-safety, it maintains the "callable that returns >> HttpResponse" contract, and most people won't ever see or care about >> the "magic" that makes it work. >> >> +1 for __new__. > > One advantage of using __call__ over __new__ is passing arguments to > __init__. That's handy for lazily configuring views: > > (r'', DetailView(queryset=Thing.objects.all()) > > Ben > > -- > 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. > > I thought we said we really wanted to encourage using subclassing to solve these problems (providing many types of args in urls.py can cause problems). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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: Class based generic views in 1.3?
On Thu, Jun 3, 2010 at 7:10 PM, Ben Firshman wrote:
> One advantage of using __call__ over __new__ is passing arguments to
> __init__. That's handy for lazily configuring views:
>
> (r'', DetailView(queryset=Thing.objects.all())
Why can't you use this instead:
(r'', 'views.DetailView', {'queryset': Thing.object.all()})
Bye,
Waldemar Kornewald
--
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: Class based generic views in 1.3?
On Thursday 03 June 2010 08:59:31 Roald wrote: > > One reason against this is it makes it harder to re-use other > > views from within the View. > > I don't really understand what you mean. Do you mean re-using > 'good' old function-views? Yes, or new ones, or any callable that returns an HttpResponse that I want to return. It is quite a common pattern to have one view wrap another or *several* others, and also to use standard response objects in some utility function or 'sub view'. e.g. def my_view(request, *args): if some_condition(): return some_view(request, *args) elif other_condition(): return some_standard_response(request.user) else: ... return render_to_response(...) def some_standard_response(user) return HttpResponseRedirect(...) This would be massively uglified, at best, if we make View a subclass of HttpResponse. Regards, Luke -- "Oh, look. I appear to be lying at the bottom of a very deep, dark hole. That seems a familiar concept. What does it remind me of? Ah, I remember. Life." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- 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: Proposal: Improvements for django.forms
Hey Petr,
On Jun 3, 11:32 am, "petr.marhoun" wrote:
> OK, more details: If fieldsets would be defined, fields would be
> concatenation of fields from individual fieldsets. So methods
> as_table, as_ul and as_li and "for field in form" would work as now.
> But if you want to really use fieldsets, you have to iterate fieldsets
> in your templates.
Great! I was also planning to propose form fieldsets but hadn't gotten
around to it yet. I have an external app, django-form-utils[1], that
already implements form fieldsets in very much the way you propose
(although with a few differences). The app has seen some use and
people seem happy with it; I would be happy to port this
implementation to a core patch, with a few changes.
One thing form-utils does differently from your proposal is that it
defines each fieldset as a two-tuple (like admin fieldsets), with a
name as the first element and the dictionary of additional info as the
second element. One advantage of having a fieldset "name" is that it
also allows accessing fieldsets individually in the template, for more
fine-grained layout control (thanks Rob Hudson for adding this to form-
utils).
Just to give a full summary of the fieldsets API I would propose
(which is not exactly the same as what's currently in form-utils; I'd
like to correct some mistakes :> ):
class PersonForm(forms.Form):
name = forms.CharField()
age = forms.IntegerField()
nickname = forms.CharField()
class Meta:
fieldsets = [('main', {'fields': ['name', 'age']}),
('extra', {'fields': ['nickname'],
'legend': 'Extra info',
'classes': ['aside']})]
(If "fieldsets" is provided for a ModelForm, it takes priority over
any "fields" or "exclude" definitions: the fields included in the
fieldsets are the ones included in the form, whether you iterate over
fieldsets or just fields.)
Iterating over the form directly yields BoundFields just as it does
now:
{% for field in form %}
Iterating over form.fieldsets yields Fieldset objects. Fieldset
objects can be iterated over to yield BoundFields:
{% for fieldset in form.fieldsets %}
{% for field in fieldset %}
Fieldsets can also be accessed individually by name on form.fieldsets:
{% for field in form.fieldsets.main %}
And fields can be accessed directly by name on the "fields" attribute
of a Fieldset (to avoid clashes between form field names and other
Fieldset attribute names):
{% form.fieldsets.main.fields.age %}
Fieldset objects also have the attributes "name", "legend", and
"classes" (which is still an iterable, not collapsed to a string, so
template authors can check {% if "blah" in fieldset.classes %} if
needed.
I am proposing the "classes" option, again parallel to current admin
fieldsets, in lieu of any additional options like "attrs" or
"template". There's a slippery slope where almost any info _could_
theoretically be provided for the template author by the Python form
author; I think it makes sense to keep it to a simple list of class
names, as the most basic, generic way to distinguish "types" of
fieldsets. I think pretty much any use case can be handled via this
mechanism, since you can write custom template tags if needed to
provide reusable display logic. (I'd be open to the "attrs" option,
but am quite opposed to "template": form definitions seem like
entirely the wrong place to embed template names.)
I would of course assume that a patch for fieldsets in forms would
also involve porting the admin's fieldsets to use this feature.
FWIW, I think it would be much preferable to separate discussion of
orthogonal features into separate threads, even if they are all form-
related. Makes it much easier to follow the discussion.
Thanks!
Carl
[1] http://bitbucket.org/carljm/django-form-utils
--
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: Proposal: Improvements for django.forms
On Jun 3, 8:57 am, Russell Keith-Magee
wrote:
> 5. Parameters "template" and "attrs" for forms, formsets, fieldsets,
> forms, (bound) fields and widgets
> 6. Support for (X)HTML5 and legacy HTML
>
> I strongly suspect that these two may be covered by something I
> discussed with Jacob at DjangoCon. Broadly, the proposal is to
> deprecate the {{ field }} and {{ form }} approach to template
> rendering in favor of a template tag {% render field %} and {% render
> form %}; these template tags would allow you to customize the way that
> individual fields, fieldsets and forms are rendered, including
> controlling doctype compliance.
>
> If you want to override the way fields or forms are rendered, you will
> be able to subclass the base render template tag, override the
> rendering behavior, and re-register the tag (or register it under a
> different name).
Great! This one is a high priority for me (my designer keeps harping
on me about that markup he can't control), and I am happy to help make
it happen. Looking forward to seeing the results of your tinkering. If
those tags could optionally take a template name as argument, I think
that would cover the vast majority of customization use-cases without
any need for subclassing or re-registering the template tag.
Personally I'd love to also see the default widgets rendered by
templates, so a normal template override of a predictably-named
builtin template is all that's needed to customize the rendering of a
given widget. But there might be performance issues there if the
caching template loader isn't used, and that isn't enabled by default.
Carl
--
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: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]
I agree the jquery ui widget is the rift way to go IMO! On Jun 2, 1:57 pm, Thomas Schreiber wrote: > +1 for JqueryUI, it has come a long way in the last year, and it now has a > nice system for subclassing widgets with the widget > factory.http://bililite.com/blog/extending-jquery-ui-widgets/ > > -Thomas > > > > On Wed, Jun 2, 2010 at 18:45, Jannis Leidel wrote: > > > To me that would be a nice feature addition. It does, however, bring > > > into question the fact that a widget, intending to be used on the > > > public side, would depend on jQuery for its UI. Is Django ready to go > > > there? Or would an admin-only autocomplete widget be preferred? > > > The jQuery based ForeignKey widget was part of the adminui refactor and > > only for this use case discussed. It did have a bunch of side effects that > > prevented a timely merge before the 1.2 feature freeze, but we should now > > restart the efforts in my opinion. > > > > Also, at the time, many of the jQuery autocomplete widgets were in a > > > state of flux or had some warts. Our (Jannis and my) idea at the time > > > was to write our own from scratch, custom and optimized for Django. > > > That looks to be about a year ago so the state of things is probably > > > much different today. (Or not?) > > > At the time we hadn't a good (or 'stable') autocompletion plugin that would > > fit our needs. Now that the autocomplete feature is part of jQuery UI, maby > > we should review it again and see if it'd help us. In any case, there is of > > course the issue of an admin ManyToMany widget that should be dealt with at > > the same time. > > > Jannis > > > > On Wed, Jun 2, 2010 at 7:13 AM, Sergej dergatsjev eecho > > > wrote: > > >> Current Admin Extensions > > > >> ForeignKeyAutocompleteAdmin - ForeignKeyAutocompleteAdmin will enable > > >> the admin app to show ForeignKey fields with an search input field. > > >> The search field is rendered by the ForeignKeySearchInput form widget > > >> and uses jQuery to do configureable autocompletion. > > > >>http://code.google.com/p/django-command-extensions/ > > > >> 2010/6/2 bydesign : > > >>> I second the vote to add the GSoC '09 Admin UI foreign key > > >>> autocomplete! It's actually somewhat embarrassing that this > > >>> functionality hasn't made it in yet. Foreign keys in the admin > > >>> interface become unusable if you have more than 50 or so rows in the > > >>> table. I hope that since this code has already been written and > > >>> tested, it can be included very soon! > > > >>> On Jun 1, 9:30 am, Russell Keith-Magee > > >>> wrote: > > On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler > > wrote: > > > hello, > > > > i'm looking for exactely the same solution for an "Ajax foreign key > > > filter in the Django admin interface" and hoped it would be > > integrated > > > into the admin interface. I think it should be standard behaviour and > > > could be configurable in the admin.py Is the development of the admin > > > interface going in that direction or is it not planned at all? > > > We're at the start of a development cycle, so the plans for the next > > release haven't been finalised yet (beyond the broad guideline that it > > will be a feature-light, bugfix heavy release). If this is an area > > where you would like to see improvements, feel free to make a specific > > proposal (preferably one accompanied by sample code :-) > > > Yours, > > Russ Magee %-) > > > >>> -- > > >>> 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 > i...@googlegroups.com> > > . > > >>> For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. > > > >> -- > > >> 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 > i...@googlegroups.com> > > . > > >> For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. > > > > -- > > > -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-develop...@googlegroups.com. > > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > i...@googlegroups.com> > > . > > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this gro
Re: Proposal: Improvements for django.forms
Hello,
> One thing form-utils does differently from your proposal is that it
> defines each fieldset as a two-tuple (like admin fieldsets), with a
> name as the first element and the dictionary of additional info as the
> second element. One advantage of having a fieldset "name" is that it
> also allows accessing fieldsets individually in the template, for more
> fine-grained layout control (thanks Rob Hudson for adding this to form-
> utils).
>
> Just to give a full summary of the fieldsets API I would propose
> (which is not exactly the same as what's currently in form-utils; I'd
> like to correct some mistakes :> ):
>
> class PersonForm(forms.Form):
> name = forms.CharField()
> age = forms.IntegerField()
> nickname = forms.CharField()
>
> class Meta:
> fieldsets = [('main', {'fields': ['name', 'age']}),
> ('extra', {'fields': ['nickname'],
> 'legend': 'Extra info',
> 'classes': ['aside']})]
I tried to be minimalistic and to give template authors only iterator
- but I like this proposal more.
I have some notes to forms-utils:
- The code says: "if legend is None: legend = name". I dislike it - I
want to have possibility not to set legend. I think that if legend is
not set it should be "None" in fieldset.
- It seems that it is not possible to say if form has fieldsets
(fieldsets method even construct fieldsets if meta attribute is not
set) - I think it is useful to know it in templates.
> (If "fieldsets" is provided for a ModelForm, it takes priority over
> any "fields" or "exclude" definitions: the fields included in the
> fieldsets are the ones included in the form, whether you iterate over
> fieldsets or just fields.)
It is the same as I tried to describe - so I agree.
> Iterating over the form directly yields BoundFields just as it does
> now:
>
> {% for field in form %}
>
> Iterating over form.fieldsets yields Fieldset objects. Fieldset
> objects can be iterated over to yield BoundFields:
>
> {% for fieldset in form.fieldsets %}
> {% for field in fieldset %}
>
> Fieldsets can also be accessed individually by name on form.fieldsets:
>
> {% for field in form.fieldsets.main %}
>
> And fields can be accessed directly by name on the "fields" attribute
> of a Fieldset (to avoid clashes between form field names and other
> Fieldset attribute names):
>
> {% form.fieldsets.main.fields.age %}
>
> Fieldset objects also have the attributes "name", "legend", and
> "classes" (which is still an iterable, not collapsed to a string, so
> template authors can check {% if "blah" in fieldset.classes %} if
> needed.
>
> I am proposing the "classes" option, again parallel to current admin
> fieldsets, in lieu of any additional options like "attrs" or
> "template". There's a slippery slope where almost any info _could_
> theoretically be provided for the template author by the Python form
> author; I think it makes sense to keep it to a simple list of class
> names, as the most basic, generic way to distinguish "types" of
> fieldsets. I think pretty much any use case can be handled via this
> mechanism, since you can write custom template tags if needed to
> provide reusable display logic. (I'd be open to the "attrs" option,
> but am quite opposed to "template": form definitions seem like
> entirely the wrong place to embed template names.)
Here I would prefer to be minimalistic. For example, widgets have
"attrs", not "classes", so it is more consistent to use "attrs". And I
have proposed "attrs" in another proposal because I think that there
is general problem - how to customize parts of form rendering without
writing of whole templates? So I would start with items "fields" and
"legend", other items could be added later.
> I would of course assume that a patch for fieldsets in forms would
> also involve porting the admin's fieldsets to use this feature.
It is not so simple. Our proposals are that "fields" are list of field
names. But in admin "fields" are list of items - and each item can be
field name or list of field names. So I think that generally it is not
possible to port admin's fieldsets to these proposals' fieldsets -
proposals' fieldsets are subset of admin's fieldsets. (And syntax from
admin seems to be too complex for Django core.)
I will try to implement the opposite approach I have proposed in
previous mail - extract fieldsets meta attribute of form to fieldset
attribute of model admin.
> FWIW, I think it would be much preferable to separate discussion of
> orthogonal features into separate threads, even if they are all form-
> related. Makes it much easier to follow the discussion.
>
> Thanks!
>
> Carl
>
> [1]http://bitbucket.org/carljm/django-form-utils
--
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...@goo
Re: Proposal: Improvements for django.forms
Hi Petr,
On Jun 3, 5:48 pm, "petr.marhoun" wrote:
> I have some notes to forms-utils:
> - The code says: "if legend is None: legend = name". I dislike it - I
> want to have possibility not to set legend. I think that if legend is
> not set it should be "None" in fieldset.
Yes, this is one of the form-utils mistakes that I would want to
correct in the Django-core version :-) Note I didn't mention anything
about auto-setting legend in the proposal here.
> - It seems that it is not possible to say if form has fieldsets
> (fieldsets method even construct fieldsets if meta attribute is not
> set) - I think it is useful to know it in templates.
Yes, form.fieldsets should behave appropriately with __nonzero__ so
you can say {{ if form.fieldsets }}.
> Here I would prefer to be minimalistic. For example, widgets have
> "attrs", not "classes", so it is more consistent to use "attrs". And I
> have proposed "attrs" in another proposal because I think that there
> is general problem - how to customize parts of form rendering without
> writing of whole templates? So I would start with items "fields" and
> "legend", other items could be added later.
That's fine with me. I don't personally have a strong opinion about
"classes" vs "attrs."
> It is not so simple. Our proposals are that "fields" are list of field
> names. But in admin "fields" are list of items - and each item can be
> field name or list of field names. So I think that generally it is not
> possible to port admin's fieldsets to these proposals' fieldsets -
> proposals' fieldsets are subset of admin's fieldsets. (And syntax from
> admin seems to be too complex for Django core.)
I don't think it's simple, but I do think it's doable to build the
admin functionality on top of the core functionality as outlined
above, without duplicating code or bringing extra admin complexity
into core. It probably will require the admin code to have pretty
intimate knowledge of the core code, but that's nothing new :-)
Carl
--
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: Proposal: Improvements for django.forms
On Jun 3, 5:48 pm, "petr.marhoun" wrote: > - It seems that it is not possible to say if form has fieldsets > (fieldsets method even construct fieldsets if meta attribute is not > set) - I think it is useful to know it in templates. I spoke too quickly here: this is a relevant API question. In form- utils, if you define no fieldsets it builds a default one for you automatically with all the fields in it, so len(form.fieldsets) is always at least 1. The advantage is that this allows templates that expect fieldsets to always work, but I'm not sure it's actually a good idea. Open to thoughts. Carl -- 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: exception handling memory leak...
Thanks for your hard work Keven. There are those of us that appreciate input. On Jun 2, 4:25 pm, Kevin Howerton wrote: > This was not a "hey you guys are lazy", actually came across it ... > after I had fixed the same issue. > > I just posted a patch for you generated off trunk... and left a > hopefully somewhat entertaining explanation of the details surrounding > the issues. > > -k -- 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.
Proposal: Build complex-navigation helper
Building a site with more than 50 views tends to require some sort of
sub-sub-page type of system in order to make for easy navigation. For
instance:
/eggs-view/
/eggs-view/sub-view/
/eggs-view/sub-view/sub-sub-view/
/spam-view/
/spam-view/spam-sub-view/
/spam-view/spam-sub-view/spam-sub-sub-view/
/foo-view/
/foo-view/foo-sub-view/
/foo-view/foo-sub-view/foo-sub-sub-view/
Currently, in order to maintain software with this sort of
architecture one can build a tabbed based navigation. The complexity
comes in when you want "sub-view" level tabs to show up only when
you're on "eggs-view", and "sub-sub-view" level tabs to show up when
you're on "sub-view", and so on. This can be done by creating a master
template, inheriting it at each level, and overriding a {% BLOCK MENU
%}. This is OK for small sites, but when you've got 50+ views to
maintain, it means you have sub-sub folders of templates all for the
sake of overriding a single block.
It would be such a relief if a DRY way of configuring a navigation
object existed that allowed for you to build, say, a dictionary of
view-confs with sub-view-confs, etc.
The closest thing I've come across as a solution so far is
http://code.google.com/p/django-nav/
I wonder if anyone in the official D-crew has come up with any ideas
that maybe just need implementing, or perhaps there are others with
this difficulty that would like to see something like this in the
trunk.
--
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: Proposal: modular django configuration
On Thu, Jun 3, 2010 at 11:19 PM, burc...@gmail.com wrote: > Hi all, > > I've written a prototype, and put it on > http://github.com/buriy/django-configurator. > It has few good design decisions, and few maybe not that good. > Anyway, I consider it as a good addition to app loading GSoC Proposal, > which is currently being worked on. Hi Yuri, I might be missing something really obvious, but I can't make any sense out of your proposals. After two quite lengthy emails, I haven't even been able to work out what what problem you are actually trying to solve. Your initial proposal consisted of pages of snippets of configuration, but no explanation of how those pieces fit together (or at least, I couldn't follow it). It might be helpful if you step back from the details and try to give a big picture view of what you're trying to do. Yours, Russ Magee %-) -- 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: Proposal: Build complex-navigation helper
On Thu, Jun 3, 2010 at 7:41 PM, M Rotch wrote: > The closest thing I've come across as a solution so far is > http://code.google.com/p/django-nav/ As the developer of django-nav it is nice to hear it is closest to a solution you have found, but often closest isnt enough, and I am not sure I understand what you are describing you need to do to get sub-sub-tabs working. Here is how I do it in the sites I maintain that go 3 levels deep for tabs base.html -> has main tabs /app/app_base.html -> extends base.html and has sub-tabs /app/view1.html -> extends app_base.html /app/view2.html -> extends app_base.html ... /app/sub_app_base.html -> extends app_base.html and has sub-sub-tabs /app/sub_view1.html -> extends sub_app_base.html /app/sub_view2.html -> extends sub_app_base.html ... -- 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.
