Re: #11834: colorized debug page. Assigned to buriy
On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com wrote: > I had few useful thoughts about changing the way Django development > contributions gets accepted and committed -- but all I get from this > mailing list that all attempts to improve any process is just a waste > of time. That's not entirely fair. We're acutely aware of the fact that there is a backlog of tickets that need attention. We're also aware that many people upload patches, but then don't get any feedback on them. We want to improve this in any way we can. If you have suggestions on how we can improve Django's development process and address these issues, we're happy to hear them. However, that doesn't mean we're going to immediately implement a suggestion just because it's been made. I don't know which suggestion in particular you're referring to, but if you've made a suggestion and we haven't acted on it, then I would suggest to you that this is because we (the core team) didn't agree that your idea was as useful or practical as you think it was. If you have a suggestion, please make it. We're listening. > Core devs have no time even to accept working & looking good > patches -- and rarely have time to review patches not looking good or > working wrong! > So why should I bother to write patches fast? I would point out that the core team aren't the only people that can give feedback. Trac is an open resource for exactly that reason. >>> I can do all development changes for all suite (and finish this patch >>> of course), if we discuss how it should be done. >>> >>> My issue needs few improvements: >>> - docs & tests >> >> AFAIK the current debug page has no docs and tests, too. > At least we need tests for color choosing based on packages paths -- > this can be customized by yourself. As I commented the last time this ticket was discussed -- no tests or docs are required for this proposal. It's a difficult feature to test, and there's no user-facing configuration items, so I'm happy to accept this ticket without tests or docs. However, it does need to have it's UX issues sorted out. The most recent substantive comment on the ticket [1] indicates that the patch isn't ready for checkin. It also suggests that there are broader improvements that may need consideration. To the best of my knowledge, nobody has tried to start a django-dev discussion to address those improvements. [1] http://code.djangoproject.com/ticket/11834#comment:5 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.
Checking if my patch would be a useful contribution
Hi all, brand new django contributor here, been using it so much I reckon it's about time I started giving back :) Anyhow, I'm using Django primarily to develop RESTful API's for web services. This of course means a lot of JSON is getting passed around in GET/POST requests so I wrote a simple form field JSONField that handles json validation and deserialisation because it was getting annoying having to do it by hand all the time. My question is: Is this something that would be useful to upstream? Oh and I also wrote a decorator for validating forms, makes for cleaner code than how current examples in the documentation handle that. Should I contribute that too? Thanks, ~Swizec -- 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: abstract file upload/download handling
On Thu, Jul 22, 2010 at 4:30 AM, Russell Keith-Magee
wrote:
> I accept the need for this, but this seems like a bit of a wart. This
> method wouldn't be required at all if the Form took a request
> argument. This isn't an unusual requirement, either -- perhaps we
> should introduce a RequestForm/RequestModelForm that formalizes the
> availability of the request object during form processing.
OK, I've now added a Request(Model)Form. The tag is based on
., so you don't have to manually specify
it. FileField takes an optional parameter to override this. Forms
currently only allow to set the tag by subclassing. Not sure if this
is sufficient.
http://code.djangoproject.com/attachment/ticket/13960/filetransfers.3.diff
I could need some feedback. Does this go in the right direction? Is
anything important missing?
class UploadForm(RequestModelForm):
class Meta:
model = bla
form = UploadForm(request)
render_to_response(... {... 'form': form} ...)
{{ form }}
Apart from that you can call file.serve() and file.download_url() as
discussed in the previous posts. You can see another example in the
unit tests of my patch. It also contains a delegation backend which
allows to easily specify which backend should be used for which
app/form/model/field via the settings:
DEFAULT_FILE_TRANSFER_BACKENDS = {
'myapp.*': 'some.backend',
'myapp.models.MyModel.s3_file': 'S3Backend',
'otherapp.models.SomeModel.*': 'OtherBackend',
}
If you need more control you can use FILE_TRANSFER_BACKENDS which
works more like the routers API.
Bye,
Waldemar Kornewald
--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django
--
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: Google Organic Search Results for Documentation
I guess it may just be helpful to at least fix the 'for current documentation' links on these pages: http://www.djangoproject.com/documentation/0.96/model-api/ just to go to http://docs.djangoproject.com in general, even if it's not the correct place, it's better than a message going to the wrong place. On Fri, Aug 13, 2010 at 4:42 AM, Reinout van Rees wrote: > On 08/11/2010 09:51 PM, Paul McMillan wrote: > >> I think this is somewhat ameliorated by being able to link to the >> current trunk documents these days. Many incoming links will be going >> there. Additionally, for old documents, there is the "these docs are >> old" message at the top. >> > > When I google, I always end up at the /dev docs with a big warning on top > "This document is for Django's development version, which can be > significantly different from previous releases. Get old docs here:..." > > The 1.2 docs have the least scary warning. > > Does the website tell google (via the xml sitemap, for instance) to prefer > the /dev docs over the /1.2 docs? I'd say the /1.2 links would be more user > friendly to get for default google incoming traffic. > > > Reinout > > -- > Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org > Programmer at http://www.nelen-schuurmans.nl > "Military engineers build missiles. Civil engineers build targets" > > -- > 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: #11834: colorized debug page. Assigned to buriy
Hi Russell, > However, it does need to have it's UX issues sorted out. The most > recent substantive comment on the ticket [1] indicates that the patch > isn't ready for checkin. It also suggests that there are broader > improvements that may need consideration. To the best of my knowledge, > nobody has tried to start a django-dev discussion to address those > improvements. > > [1] http://code.djangoproject.com/ticket/11834#comment:5 Regarding ticket improvements, do you remember that guy who sent a beautiful screenshot of his templates errors rework in the django dev about half a year or a year ago? Can't find it, but I wanted desperately to include it! -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
