Hi Chris,
I have a little feedback if you are interested. [Just so you know, I'm
a "heavy user" of Django but have yet to make a substancial
contribution to the project]
In general I think your proposal is fine but I have a few points:
-Lots of tables there! Can you acheive the same without the e
> How do you deal with those permissions in the generic and admin views?
To be clearer, I meant: How do you deal with those permissions in the
generic and admin *list* views?
-rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
> It would be nice if I could have an answer on this, thus I can avoid
> redundant effort.
Perhaps there would be more confidence in your efforts if it:
a) Wasn't making someone else's work redundant
b) Came from some detailed design
c) Worked on all databases before being checked in
If you pos
> What do you think of auto escaping being on for .html templates and off for
> .txt templates?
Simon,
Sounds clean but consider:
a) The ever-present argument about file extensions & template syntax
(that we seemed to solve with MR)
b) These can't be so easily extended. For example, to switch yo
The Javascript way is the only way if both combo boxes are on the same
page (i.e. the selection must be initiated on the client side.) You can
add extra javascript easily in admin by using the "js" option in admin,
so you won't need to actually override any templates.
-rob
--~--~-~--~-
> That's what I'm after. But I see no reason why we could accomodate more
> options! =)
For the admin interface, probably your best option is to override the
delete view. This is very simple, actually, because all actions are
directed by the url and can be overridden by urls.py.
So, in your url
Create your own admin/submit_line.html template.
-rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscri
> In the Admin UI it could look like this:
[Select State]
--[Select County]
[Select Zip]
I think situations like this are handled better on the server side
anyway. A list containing ~100 items or less is appropriate in most
cases, but there is a pretty good chance you would exceed this even
> I'm working on something similar at the moment, which indeed be available in
> "contrib." It's going to be really awesome.
Fantastic! I've been using the admin list views because of these
features, but it "gets a bit hacky" after a while! Wouldn't have
thought it necessary in contrib (instead
Hi all,
In the newforms-admin wiki there is mention of a "cleaner way to
specify admin options". Has this been discussed yet?
If so, my apologies. I've kind of been out of the loop for a while.
If not, can we start?
-rob
--~--~-~--~~~---~--~~
You received this m
From a puritanical point of view, I would like to see the admin options
separated from the fields. It could also allow for more flexibility. I
think a ModelAdmin class in the same file but separate from the Model
class would be easiest to manage, if that were possible. Assuming the
default use
> Something like this is what I had in mind: ...
I generally like the simplicity and explicitness of your suggestion,
but having to manually add & remove models is too fragile, I think.
> Maybe there can be a helper function that looks for all Admin classes, as
> long as you save them in a file
Isn't is easier just to override admin/index.html? That way you can
even add some styling/javascript that will organize it to better suit
your needs.
If you don't know what I mean:
1) copy the file django/contrib/admin/templates/admin/index.html to
yourtemplatedir/admin/index.html.
2) Add yourtem
Its the new google groups, I think. I saw the same thing the other day
with the (then beta) new google groups, but had no issues with the old
one.
-rob
On Jan 25, 10:59 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 1/26/07, medhat <[EMAIL PROTECTED]> wrote:
>
> > So many times I send mess
On Feb 2, 12:01 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> The Jan. 31 deadline for merging the newforms-admin has passed, so I
> thought I'd give a status update:
Kudos on these changes (& newforms, of course). I really like that
admin is now as "legit" as regular forms for public views
> I find it useful to have the {% for %} tag syntax extended so that one can
> write:
> {% for a,b in L %} meaning the obvious thing
You can do this. a,b return type is implicitly (a,b) in Python. In
other words:
{% for x in L %}
{{ x.0 }}
{{ x.1 }}
{% endfor %}
> Also (maybe more contentiou
> You can do this of course but it does not help to make sense of the
> template. E.g.
>
> {% for key,value in L %}
> {{ key }}->{{ value }}
> {% endfor %}
Yes, however you're looking at the case of only two variables. Think
of how unmanageable it will start to look like this:
{% for name,descr
> I'm glad you like it! I really hope it does help many other people who
> have a need for something like this. I'm very eager to hear what other
> thoughts and questions you (and anyone else!) have about it. I'm glad
> to clarify.
>
> -Gul
Good timing! I was planning to look to something like th
This is a question for django-users, but I'll do the usual "chastise
then help" post :)
The problem is because XML uses settings.DEFAULT_CHARSET of 'utf-8',
which is the standard XML character set. You will need to change this
to 'utf-16', I think.
So, in your settings file, add the line:
DEFAULT
Hi all,
I'm wondering if this is seems like a feasible additional feature to
the newforms-admin branch.
Currently I have a lot of very similar models, representing people
roles. They all have addresses, phone numbers, etc, which was easy
enough with subclassing models back in the day. However, ev
there you go! Perhaps someone will come up with a really compelling
case to add it, but it probably won't be me.
-rob
On Apr 19, 12:58 am, oggie rob <[EMAIL PROTECTED]> wrote:
> Hi all,
> I'm wondering if this is seems like a feasible additional feature to
> the newforms
In 0.92 you could do this:
@defaulttags.register.simple_tag
def my_tag():
pass
Without looking (and probably regretting my laziness...) I'm guessing
the same is still available.
-rob
On Apr 24, 8:38 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> As someone who works with the Django t
Hi,
I've been modifying admin interfaces lately and I've found a few
restrictions that we might be able to avoid. I think this could make
the admin interfaces much more flexible.
Why admin, you might ask, instead of just creating custom views? Well,
if you look at how much you get for free, there
An event system is a great idea! If we could tie it into AJAX there are
some pretty amazing things that we could do.
-rob
Yes, it is a little ugly. I would suggest that you put the Q arguments
outside of your query for readability (also for those 'subqueries' you
were talking about):
hello = Q(headline__startswith='Hello')
bye = Q(headline__startswith='Goodbye')
articles.get_list(complex=(hello | goodbye))
As usual,
I think the biggest criticism to an idea like this is that it
introduces a lot of complexity without solving all the problems you
need to solve. For example, what if you need to form a join with
another table that goes beyond polls_choices.
An alternative is to generate some other function that di
Hi all,
I'm a little embarrased to ask...
I am working off Win2K, and any time I open a file with notepad (which
doesn't convert line endings) I'm looking at a *nix file. Also any
change I make to my local copy results in full-file diffs. Is it
possible that some (read: all, or almost all) files
Thanks John.
So even with a good editor (I'm a SlickEdit guy myself) it can cause
problems when you diff saved files if you don't happen to change the
default editor save behaviour.
Should I open a ticket?
-rob
FYI here are the 'text' file endings that are used throughout (if you
used autoprops in your config file you would set these to
eol-style:native):
.css
.html
.js
.po (?)
.py
.txt
And here are the binary ones (which you wouldn't include in the
autoprops):
.gif
.mo
.png
That only works for adding/i
Since we're looking, is there some way to more clearly separate table
vs row than using pluralization? e.g. I think it would be much cleaner
if we could say something like
rec = Poll()
table = Poll.table()
fewer imports required, less misspellings, etc.
Don't know if it would be possible, though
Ignore my earlier post. I prefer Robert and Hugo's thoughts on this -
even as a newcomer :)
-rob
P.S. AFAICS, removing the magic class behaviour is much more important
than the changes that were originally proposed
Can somebody with checkin privs do this? I think the info I posted
earlier will work (followed by a commit, of course):
at top level of a clean checkout:
svn propset snv:eol-style native -R .
cd contrib/admin/media/img/admin
svn propdel svn:eol-style -R .
cd -
cd conf/locale
svn propdel svn:eol-s
How will 'or' queries work in the new get_list syntax?
-rob
I would still avoid pluralization, if that was implied. Also you would
need to add "count", "values", "bulk" etc but that seems natural enough
from your suggestion (e.g. reporter.articles.count)
So by implication you could filter on the reporter object also? e.g.
reporter.filter(first_name__start
> This makes about as much sense as "The police shouldn't fine me for
speeding when they could be out catching murderers." That we have other
features required doesn't mean we are not allowed to think about this
one.
My point is (as well as trying to improve the query capabilities) that
if we are
The "len" idea is not great anyway - it is much more costly to get and
len 10,000 rows than to use SQL count, as get_article_count does.
-rob
Right, but what good is overriding len(..) if you have the list
already? You've already fetched the records, right?
As Jacob said before, when you say "get_article_count", you know that
you are actually executing an SQL query. What is the case when you say
reporter.articles? Is this a list already
Okay. Sorry that wasn't intuitive to me.
-rob
Would it be possible to override the url location within the
modules/classes? My only concern is that sometimes the project, module
and/or class name are not an appropriate part of a URL, and would be
nice to easily override. (This of course assumes that URLs are part of
the UI, which I feel is tr
Sure. There may not be a need for a "project" dir when you have only
one project running. It is cleaner to simply have /admin/blog/entry/add
or even /admin/entry/add. Also, you may want your model to technically
describe the object accurately, but present it to the user in a more
readable way, or
Can the admin options be specified in the meta.Manager field?
e.g.
class Whatever(Model):
name = CharField(maxlength=100)
objects = Manager(list_display=)
-rob
Robert Wittams wrote:
>That would be even wierder in my opinion, as the Manager:
>a) is not required
>b) is orthogonal to the admin
Fair enough. I guess what I was looking for was an ADMIN class that is
closer to a manipulator (and if so I think it is inflexible to assume
there should only ever b
> Questions? Comments? Concerns?
One comment: something that has been bugging me for a while is the
location where you specify the inline behaviour.
For example (using the Poll/Choice models):
class Choice(meta.Model):
poll = meta.ForeignKey(Poll, edit_inline=meta.STACKED,
num_in_admin=3)
S
Jacob says:
> I kinda think it should be::
>
> class Poll(Model):
> ...
>
> class Choice(Model):
>poll = ForeignKey(Poll)
>
>class ADMIN:
>edit_inline_on_relation = 'poll'
But in (almost?) all other ways the admin section represents the view
for the current
Jacob says:
> Yeah, I don't think I explained myself well enough; let me give a concrete
> example of why I'd like this:
Thanks, Jacob, it helps to see things from other perspectives and
especially in that case I agree the gains are well worthwhile.
I was thinking also about how this might work
> Another option would be to have the callable return a (url, message)
tuple, and let the view handle HttpResponseRedirect and
request.user.add_message.
I think you should use a dictionary. For example, you could pass in the
following dictionary:
{None:'../report1/%s'}
and then in the default met
> Also, I don't believe post_url would allow you to use something like
the new object id in your url.
I needed this capability (I have wizard-like interfaces derived from
the admin pages), and ended up modifying change_stage so it read
something like this:
redir = redir_dict.get(None, '../../')
> I suppose the greater problem is the ability to easily construct (and
use) a filter on queries (e.g. construct a 'tall_people_only' filter,
make it a member of Person, so you can write
Person.get_list(tall_people_only, name__exact='Fred'). You should be
able to do this using arg-level query obje
Maybe it's just me...
Why in the world would we want development documentation in the admin
interface? I noticed that the "Documentation" link was added to the
user links section, but none of the users of any real world application
I can imagine would benefit from that documentation.
Even having
> It's not just the referential integrety - even though that's
complicated enough, with ISPs not allways installing newest versions of
databases - but the .delete() overloading, too. If your class overloads
.delete() to do specific stuff, that code will not be called when you
do bulk deletes.
Doe
I said:
> Doesn't the delete function also check permissions on all the referenced rows?
I tested this and found a bug (#1250), but I confirmed that you cannot
delete items through the admin interface if you don't have delete
permissions to ALL related objects.
-rob
> You are talking about the admin interface - we are talking about the database
> API. The database API doesn't check any permissions, as it's a Python call
> done by the programmer, and we still trust the programmer
;-)
Yep, I realize that, and wasn't trying to ignore the db changes to
support
> of course django is still much much better than any java framework :)
I know this thread has gone off topic, but I couldn't resist :)
I've been looking a lot at enterprise offerings lately and have been
thinking about these issues. After several failed J2EE attempts, Django
has always looked ve
Although I normally encourage plenty of formalization, I don't think
this is a good idea right now. Here's why:
1) The deadlines referred to in documentation are for a small team with
money coming in. Django is a larger "team" (meaning lots of input from
various interests) with no money as a direc
> Opinions? I'll go ahead an implement this if no-one screams.
I'm a little concerned that you found this - I deployed a similar app
several months ago and have not heard of a single case of this. (I'm
using rev 1764.)
Are you sure that changing Django will fix this? If you only found it
when y
> I'm not sure if I can really spend any more of my company's time
diagnosing this problem! Certainly the change has worked, and could be
useful for anyone in a similar situation.
No worries. This helps! I'm going to look out for something like this
as well now, and will probably need to patch w
> So we want to think about if the app_pefix can be easily changed or remapped.
Can't you just use "include"?
urlpatterns = patterns('',
('^%s/' % app_prefix, include('app.urls')),
)
Pretty flexible, pretty simple, and already there!
-rob
--~--~-~--~~~---~--~-
> I'm open to being convinced otherwise, but I don't see it as within the scope
> of the admin CSS to accomodate being embedded in other interfaces.
Not to throw fuel on the fire, but for some applications in particular
we're stuck between a rock and a hard place, and the admin interface is
the
> My point is not that you should or shouldn't have to write your own form
> code. My point is that (in my mind anyway) needing to write your own styles
> is not a barrier to reusing the admin form code.
Yes, I agree. Like I mentioned, the only limitation I've faced with the
styles that come wi
> Take zyons.com for example, a open source forum app I'm developing. I grabbed
> the admin template modified it slightly and pushed it out.
zyons.com is about the level of admin L&F customization that I was
thinking about - tweaking CSS & templates just a little. Even just
colors.
-rob
--~-
I would rather see some ability to add variables when
render_to_response is hit. In other words, rather than using the
proposed mechanisms above to create a unique template, I think it would
be more usable if you were to say:
def my_admin_override(request, ...):
context, template_list = do_mos
> What is the best way to dispatch to a method based on both HTTP method *and*
> a URL?
Basically you've found it, and it is a clean way to code. However you
have to consider calling get_myresource() from post_myresource(), as
you would probably do if the POST has errors. Typically manipulators
> Would this be useful enough to include in django itself?
This could be posted somewhere on djangoproject.com or
djangosnippets.org. I wouldn't recommend using the management commands
- this is a one-off operation and there's no need to change django
itself (besides, people will probably want to
On Sep 14, 3:28 am, HenrikV <[EMAIL PROTECTED]> wrote:
> Where should I look to catch exceptions in application models ?
Don't use manage.py, instead set DJANGO_SETTINGS_MODULE and PYTHONPATH
and start a regular python shell, then import some apps (i.e. comments
app) separately.
As far as how th
On Sep 22, 1:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm w
On Sep 23, 3:26 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 23, 9:00 am, oggie rob <[EMAIL PROTECTED]> wrote:
>> Is it worth a gut check to make sure this is worthwhile?
>
> Here's a useful case in point: the admin. Django's admin should ship
>
> in fact, it takes us back to the
> original proposal of a SafeForm that just takes the request object as
> an argument to its constructor.
Well this seems much simpler, although there is still the requirement
to add the csrf_fields whenever you write out the form in the template
(which isn't mu
Hi all,
unique_for_date (and for_month, for_year as well) are not functional
in 1.0, but before I try to get them working, I'm wondering if there
is any thought about those fields.
Currently they are included in the model field definition, but of
course the documentation mentions that it is used
On Sep 28, 5:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Short version: model-aware validation is being worked on. We didn't get
> it finished for 1.0, but it's still ongoing work.
Great! Judging by the activity this is tracked in #6845 so I included
a note and a reference in the ticke
Did you try subclassing list (& overriding __iter__) for the ADMINS
object?
-rob
On Oct 15, 1:58 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
> The built-in behavior for
> django.core.handlers.base.handle_uncaught_exception calls mail_admins
> for each internal server error.
>
> So if a very high
On Oct 15, 10:18 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
> Is your suggestion that, since mail_admins happens to be the only
> place in Django that uses settings.ADMINS, I could do something like:
>
> class AdminsObject(list):
> def __iter__(self):
> // do some custom notification
>
> I agree, and this explanation looks good. +1
Its a bit deeper than that... but I'm waiting for my friend to respond
(he worked on sqlite issues at my last company). Hopefully I'll hear
from him today and be able to add some more details.
-rob
--~--~-~--~~~---~--~-
On Oct 27, 11:21 am, oggie rob <[EMAIL PROTECTED]> wrote:
> Its a bit deeper than that... but I'm waiting for my friend to respond
> (he worked on sqlite issues at my last company). Hopefully I'll hear
> from him today and be able to add some more details.
Okay, so I go
> {% for item in grocery_list %}
> {{ item }}
> {% default %}
> Nothing to buy.
> {% endfor %}
Please, though - use {% else %}. Its totally clear what its referring
to and else doesn't mean squat unless you see what the if (and in this
case, for) test is anyway, so I don't think this would be
> I'd prefer backwards compatibility. The way I'm envisioning it would
> complicate the code a bit, but I think preserving compatibility is
> worth it:
It would be nice to keep backwards compat, for the sole reason that
the quickest way to test your code against a django upgrade is to run
tests -
Hiya,
I thought I would shout out ticket #1848 (30 minute increments in the
admin time widget) for inclusion in 1.1, if anyone wants it. I'm still
using it and others might find it useful.
http://code.djangoproject.com/ticket/1848
-rob
--~--~-~--~~~---~--~~
You re
> Since so far only you and I have made real input here, I'd like to hear
> what any of the other maintainers (or anybody else who uses this stuff)
> thinks. Realistically, any of the options are survivable, so barring any
> great arguments one way or the other, we should just pick one and commit
On Dec 10, 6:25 am, AcidTonic <[EMAIL PROTECTED]> wrote:
> I'm building an application to track IP addresses on many corporate
> networks with a single subnet having around 65535 rows for IP
> addresses. Now this app has thousands of those subnets which means
> I have millions of rows for IP a
Yeah! This is much cleaner. I need to add ordering to some model
relations (i.e. represent all related values as an ordered list, where
relations can be shifted up & down) to the M2M field, it looks like it
would fit much easier using a manager & concrete Model subclass than
being restricted to a
Hi all,
Playing around with the test client I found it frustrating that
"context" can either be a single context or a list, depending on how
the template is rendered. My feeling is they should always return
lists. Likewise for the "template" field. I can see that no matter
what there is a chance o
If you have the time, Mario, you can always create a "django 1.0
release theories" website :)
Then all you have to do is come up with some interesting plot twists,
some celebrity blogs, and a "find the missing feature" game, and
before you know it, 1.0 will be here!
-rob
On Jul 19, 3:49 pm, "Ja
Perhaps simply by preventing absolute paths? That would be very easy
to change if it doesn't prevent a legitimate setup.
Of course, html coders need to accept a certain responsibility because
sometimes they can access a *lot* of information quite easily. I would
think if you have a non programmer
> Sort of, but not really. Personally, I don't think there's any secure
> way to allow arbitrary users to upload templates, because there are
> just too many ways to expose something you wouldn't want to expose; if
> you were going to develop a sandboxed version of the template system,
> you'd hav
> > This was my feeling also, however I think it is prudent to prevent
> > legitimate users from making mistakes. I don't know about designers,
> > but I have worked with some programmers that just don't think things
> > through like they should...
>
> This tells me they have a much deeper problem
> > does this also affect psycopg1?
>
> Looking at psycopg1 code, the answer would appear to be that it is not
> affected. Changes to support Decimal appear to be psycopg2 specific.
>
> Graham
The problems I was seeing the other day were repeatable both using
strictly psycopg1 (in fact, that was
> The recommendation I would make for now is that applications using new
> Django builds should use psycopg2 and applications using older builds
> should use psycopg1. This way there are two executables that don't
> clash in any way. I have done this myself and it eliminated all the
> problems I h
> are you sure this is the same issue?
>
> from what i saw in the tickethttp://www.initd.org/tracker/psycopg/ticket/192,
>
> it seems that it can fail even when both sub-interpreters run the same
> version of python/django...
>
> gabor
Sorry, gabor I didn't see this earlier.
Yes, I'm pretty certa
> I was wondering what everyone's stance is on inclusion of something like this.
It is not really needed, you can override the field. Take a look at
the __init__ call in http://www.djangosnippets.org/snippets/26/ and
you can do that with a model field as well as a form field. Yes it is
a bit of a
> Hmmm, I'm not sure how psycopg1 in isolation could be a cause of
> problems as it doesn't anywhere in its source code support the new
> 'decimal.Decimal' type. Thus, the exact same problem as identified so
> far with pyscopg2 couldn't be what was being encountered with
> psycopg1.
I'm sorry, I
> "Curriculum" use psycopg1 or 2?
>
> seems like that was part of your point.
>
> Carl K
Yeah I didn't mention this post that *now* Curriculum is using
psycopg2 and Santa Cruz is using psycopg1, with no apparent problems
(sorry, I did mention it earlier but forgot to clarify). But as Graham
says,
> Are Django committers willing to accept patches that reformat lines within
> 80 characters?
>
> --
> Nicola Larosa -http://www.tekNico.net/
I was curious - being a 80+ line writer myself - how many lines in
trunk were currently longer than 80 chars, so I wrote a short script.
Here's what I got
I'm not sure of the intent, but something to keep in mind is that if
you have previously-valid information and wish to save it again, it
may become invalid.
For example, I have a list of "active" employees for selection in the
filtered choice field. If I open up some object and hit "Save" after
th
> Hmm, I see what you're saying but (using your example) if the employee
> is no longer active, wouldn't that mean the field *should* raise a
> validation error? If the choices are meant to be limited to only
> employees which are active shouldn't the validation prevent the user
> from choosing an
> That could work. The main point of this thread was to see if there are
> use cases for using the default manager for validation instead of the
> query set because I couldn't really think of any - but I'm sure there
> could well be some.
Like the one I explained? :)
I think the strongest argume
> Sorry, perhaps I don't quite understand how this is different...
> unless you are rendering the field widget manually and somehow adding
> extra choices that aren't in the query set passed to the
> Model*ChoiceField?
There would be one extra choice - the previously selected, and no
longer valid
> Ramiro Morales reported a similar thing in #5204. My fault; I'll have a
> look at it.
It's my fault, too! I'll remember to look through comments next time I
write the "too simple" patch.
-rob
--~--~-~--~~~---~--~~
You received this message because you are sub
On Nov 29, 10:33 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INS
Hi all,
This might seem like beating a dead horse...
In the template docs, this phrase is in the notes for escaping:
"Generally, template authors don't need to worry about auto-escaping
very much."
which to me, sounds about right. But clearly template authors DO have
to worry about auto-escaping,
> I dunno about you, but I get data from places other than forms.
Well then, who makes decisions about trust for that data?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
> * Escaping is solely and entirely a function of presenting data in HTML.
> * As such, escaping belongs in the component of Django which handles
> presentation of data in HTML.
> * As such, the template layer is the correct place for this.
All good arguments :)
I'm frustrated that the template
1 - 100 of 102 matches
Mail list logo
