Re: Class based generic views in 1.3?
On Jun 15, 5:10 pm, Patryk Zawadzki wrote: > If you don't mind, I'll talk a bit more to myself. While talking to self usually helps, IMHO, we have to speak to each other to get this in 1.3. Ben has taken the lead of this and published some code. I suggest we focus on testing and improving Ben's code rather than keep going back and examine the basic assumptions: - the url dispatcher will not be changed - the user will have an thread-safe instance to work with Actually, the current code is not that sure on the second point, here's a line from base.py: view.request = request # FIXME: Maybe remove? Should this be encouraged? As I see it, if we're cloning the view, it should be encouraged. I forked Ben's code and refactored it so that instead of having the methods pass 'request' around, use self.request. I believe it made the generic views more readable and it will help users' make their views cleaner. My fork is at http://github.com/daonb/django-class-based-views Benny -- 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 Jun 16, 4:45 pm, Ben Firshman wrote: > > The request is passed round so methods look like views to decorators. > Magically dropping it for decorators seems a bit scary. :/ > The way I see it a good framework need to establish a clear contract with its user. In our case, Django publishes a contract ensuring the user that when he inherits from View and overrides any of: GET, POST, UPDATE, DELETE,get_response, get_content, get_resource, render_html, get_template, get_context and a few others, the request attribute of self is current. I agree stripping the request looks a bit scary, but at least it's only 5 lines of simple code:-). They way I see it, decorators are global so they need the request and Django adds it for them. When the global decorators are done, Django can strip the request and get the user to trust our contract. Benny. -- 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.
Improving Class based views names
Hi, I'm in the middle of re-factoring a pretty active open parliament project into 1.3. I've been an early adaptor of class based views, using it of Jacob's fork. Migration to the beta was quite smooth except for two names that broke my code: `pk` & `get_context_data`. The first comes from `models` and is now used instead of `object_id` in urls and views. It also broke compatibility with django-backlinks and I was forced to support both `pk` and `object_id` in the view wrapper, ugly. The second name can be rinsed and lose it's last 5 chars. Thanks, Benny -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Improving Class based views names
> The names used by the generic views are (as far as I am aware) > internally consistent within the views, and with the old generic > views. The choice to use pk instead of object_id was quite deliberate, > because every object responds to pk, but not necessarily to id. > I don't believe it's backward compatible with the current generic views - http://docs.djangoproject.com/en/1.2/ref/generic-views/#django-views-generic-list-detail-object-detail. IMHO, it's the other way around: every viewable object got to have some kind of an id, but not necessarily a pk. In the case an object comes from the db the object_id is the primary key, in case I choose to override the get_object method I can use the object_id to retrieve an object from a dataset that has no primary keys. > Compatibility with third party libraries isn't really a consideration > unless the general community has converged on a convention which a new > Django feature has blindly ignored. In this case, I would argue that > pk is the convention, and Django-backlinks is in need of an update. hmm, I was under the impression `object_id` is the convention for urls and views while pk is used for models. Maybe, I'm wrong, but searching the docs, I found it was referenced by admin, contenttypes, comments and of course generic views. Benny -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Improving Class based views names
On Mar 20, 4:49 am, Carl Meyer wrote: > > Those last five characters in "get_context_data" actually serve quite a > useful purpose, IMO. They clarify that the return value is just the data > that will go into building a context (a dictionary), as opposed to being > the Context or RequestContext object itself, which is what I'd expect > from a method named "get_context". > Good point. I might be splitting hairs, but _data isn't clear enough - both a dict and a Context objects satisfy `data`. Looking at RequestContext code, I found __init__ gets a `dict` parameter, so how about making it get_context_dict? Benny -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: class based views: object instead of dictionary as context?
Hi Reinout,
IMHO, Django's philosophy is that template designers are highly
skilled designers and not coders. To make it possible for designers
to edit the templates themselves, Django requires the developer to
create a simple context dictionary for designers to understand.
In all of my projects so far I didn't have the luxury of a designer
who'se fluent in Django templates and can write them by himself, but
still, I like Django for showing a clear way for designers and coders
to work together.
Benny
On Sep 1, 11:46 pm, Reinout van Rees wrote:
> Hi,
>
> I've got one big what's-the-design-decision/reason question regarding
> django 1.3's new class based views: why does django encourage a
> hand-crafted context dictionary instead of "just" passing the view
> object along?
>
> In zope/plone, I was used to having the view object available in the
> template as 'view'. The django equivalent would be to pass a context of
> {'view': self} to the template.
>
> All the attributes on the view class (well, object) would be available.
> Django prefers the template to stay simple and stupid: what could be
> better than encouraging to just add extra methods to the class if you
> want something special? Now you have to add the method *and* pass it
> along in the dictionary. Double work?
>
> Passing the view object to the template by default seems to me to be an
> absolute no-brainer. Class based views ought to mean you get the view
> object in your template, right? But Django doesn't do it. So... is there
> a specific reason for it?
>
> Reinout
>
> --
> Reinout van Rees http://reinout.vanrees.org/
> rein...@vanrees.org http://www.nelen-schuurmans.nl/
> "If you're not sure what to do, make something. -- Paul Graham"
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Is it time for a django-evangelists group?
Hi all, I've organized the testing sprint in Israel this Sunday and it was a great experience. The idea was to beta test 1.0 - getting new users through the tutorial and some 0.96 users to port their apps to 1.0. Overall we didn't find any serious bugs although porting is going to be painful... Many of the participants were non-django users with different views as to what Django really is. We had a couple of users who didn't know Python and came to learn it just for the power of Django. As I'm sure you've noticed, Django is definitely getting noticed. I could start a whole discussion as to what I learned about users out there and share some ideas on how to improve the tutorial so it will be easier for newcomers. But I know that django-developers is not the place for this. This group is very busy as it is, working on far more important things than minor improvements to the tutorial. I suggest an evangelist group so I'll have a place to share my experience and ideas, help other projects, get help for my projects and ensure work is not been duplicated. What's your vote? Benny. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Help needed: Django 1.0 release notes and porting guide
I'll take the porting guide - ticket #8438. Although I'm not going to be in Portland, I'll do my best to have a draft ready by the weekend. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: A (last-minute) compromise on {% url %}
+1 for a sweet feature. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New milestones for ticket triagers
I'm with the grasshoper. We've been patient for quite a while, but we need a release framework so us mortals (==non-core developers) can safely post ticketsm. We've been quite, not wanting to interfere with the crucial work of releasing 1.0, but we have alot of good ideas that need documentation Jacob, please release a roadmap ASAP or let us know what version we should use for new tickets. It's important to have a roadmap (and I'm +1 for grasshoper's suggestion), even if you'll change it within a week: " 1. Jacob is always by definition right about how Django should behave. This means he has final veto power on the core functionality. 2. Jacob is allowed to change his mind about any matter at a later date, regardless of whether he previously invoked Rule 1. Got that? Jacob is always right, even when he was wrong. " (adapted from Larry & Perl - http://en.wikipedia.org/wiki/Larry_Wall) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New milestones for ticket triagers
> Er, Django 1.0 was only released _3 days_ ago. You know people are > literally sitting down to the start of Djangocon right now, right? Sorry, but I don't. I know it's been a tremendous effort and a great achievement to get 1.0 out on time and I'm thankful for all those who contributed. I'm not in authors.txt, all I could do to help was to download the trunk every couple of days, run the tests and in the end help a bit with the docs. I hope to be more active in future releases. I see myself as a part of a community (and I believe grasshoper is to) that loves Django and wants to contribute, although we are too busy or not experienced enough. I think there are many like me among the 4000 members of this group. We are mostly silence and but for a lucky few, we won't be in DjangoCon. So we want a roadmap, to better help with ticket triage. You can reply with -1 or 0 if you don't like the idea, but please don't tell us you're too busy doing grownup things. We are grownups too and deserve to be treated as such. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ANNOUNCE: Django 1.0 released
Mazal Tov to all the perfectionists for a great version of a great framework. We're having a street party tonight in TLV celebrating the release of 1.0. We'll have a lot of beer and Humus. Here's the link (in Hebrew) http://tinyurl.com/645tmv. Lechaim! Benny -- http://friendfeed.com/daonb --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: implementing app specific default settings
IMHO installing a new app should require user intervention. I don't want to see new apps magically popping out and I don't want to dynamically load anyone else's settings.py. I love the code I get from pluggable apps but I prefer to keep settings.py for myself... Why not have a manage.py *installapp* command that takes an app folder and adds its code and documentation to the current project. Among other things it can do is to create a symbolic link to the new code and append settings.py with the app-specifics settings. installapp will not rewrite settings.py but only add code to its bottom, adding app-specific blocks with the apps variables and defaults. installapp can also scan the included documentation to create some project-wide files like AUTHORS.txt and LICENSE.txt. It can also get me what I need most - project docs with reference guides for templatetags and url names. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Feeds refactoring
Hi all, I'm a part of the Django user group in Israel and we want to have our own project, taking a part of the Django project and improving it. I've discussed it with Jacob, Adrian and Alex yesterday and they all agreed that the feeds module needs refactoring. So, if you're working on it now or if you have some design thoughts please share. Thanks, Benny --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feeds refactoring
> * Builtin support for the full Atom publishing protocol. This is > already logged as ticket (#3569) and was originally accepted for v1.1, > but got delayed in the interest of the schedule. Makes sense to support RFC 4287. I think it will help if we drop RSS support and support only Atom. I'm +1 for dropping RSS support. > * Named URLs for feeds Sure. > * Deploying at arbitrary URLs, rather than /feed/// Yep. > * Member per-feed permissions Maybe we can associate each feed with a list of groups, so that only group members get access. > > Of course, its going to be difficult to get a full design discussion > going until Django v1.1 is out, but hopefully this will whet your > appetite. I'd like to use the next PyWeb-IL meeting for writing testing code for the feeds framework. If people can reply with snippets of unit testing it can help get the design going. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
