Re: #11675:Pyblic+Memcache changes, Draft #1
On Thu, Dec 2, 2010 at 4:50 PM, Jacob Burch wrote: > What I"m doing now (returning None) is already fairly magical. Isn't that broken? set(KEY, "a", timeout=100) set(KEY, "b", timeout=0) get(KEY) won't returning None from the set(..., 0) instead of sending the instant-expire through to memcache mean that a subsequent get() will return "a"? 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #11675:Pyblic+Memcache changes, Draft #1
Hi Jacob, On Thu, Dec 2, 2010 at 8:05 AM, Jacob Burch wrote: > > The problem is I can't think of a good way to force instant-expiring > sets in pylibmc. The only way to fake the response is to alter the > actual return value. 0 and all negative numbers, in pylibmc, set for > never expire. And even a timeout of 1 second currently causes the > cache template tag tests to fail. > Can't you just no-op a timeout=0 in the django backend, regardless of the actual memcache lib in use? ie. never send the 'set' command to pylibmc/python-memcache... Hmm. On further thinking, make it into a 'delete' call so any existing entry will be expired instantly. Maybe that's getting too magical? 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. 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, Jun 24, 2010 at 4:24 AM, Waldemar Kornewald wrote: > FileField gets a new method prepare_upload() which takes the following > arguments: > * request > * upload_url: the target URL of the upload view > * private: should this be only privately accessibly or also publicly? > (default: False; whether this actually works depends on the chosen > backend's capabilities and your hosting setup) There are many shades of grey between public & private, I'm not sure a boolean will cut it here for the long term. - anyone on the net - registered users - members of a group - the uploader & admins... Can/should we tie this into object-level permissions? There are also different URLs as well, which could all be valid for the same object: - public, nice urls: http://example.com/alex/photos/mycar.jpg - obscured urls: http://example.com/asdfgh123456/mycar.jpg - URLs valid for some time (I'm thinking S3/etc): http://example.com/alex/photos/mycar.jpg?auth=123456 The backend should be generating #3 and #1, maybe #2 is handled by the views? 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.3: Start deprecating mod_python?
Hi again, > Jacob said: I'm +1e100 or so. > Russ said: +1. Now lives as http://code.djangoproject.com/ticket/13820 > > The only catch I can think of that hasn't been raised is the hotshot > profiling handler; it's currently dependent on the modpython handler. > I don't think there's a whole lot of extra work required to port it > over, but it's worth putting on the todo list so it isn't forgotten. Do we: 1. build a WSGI-based equivalent handler? 2. deprecate it with mod_python, post Graham's code on django-snippets/wiki, then point people there (or to django-debug-toolbar) in the release/deprecation notes? I'd vote for #2, it's trivial code but is (afaik) unused - and there are better places for that code to live. 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.3: Start deprecating mod_python?
Hi Anton, On Wed, Jun 23, 2010 at 10:13 PM, Anton Bessonov wrote: >> >> * mod_wsgi is better in every way. > > And? Jinja2-Template Engine is every way better as Django Template Engine. > Drop DJango Template Engine and support Jinja2? Russell explained it, but mod_wsgi: - is actively developed - implements the python web-app standards - has great documentation - supports both Python 2 & 3 - is trying hard to address different hosting models, including shared hosting. mod_python on the other hand: - is abandoned & has no developers - has a LOT of outstanding bugs, many quite serious - will never work with Python 3 without enormous effort - does everything its own special way >> >> * mod_python hasn't had a release since 2007, or a commit since 2008; >> it's a dead end. The Apache Foundation board voted this month to >> retire it to the "Attic" - effectively beginning to wind it up. >> http://attic.apache.org/projects/quetzalcoatl.html >> > > And? Cobol is old and dead, but see financial and insurance sector. People are actively developing in and with COBOL (eg. the industries you mentioned). The cool kids don't like it - that's different. A new Visual Studio COBOL tool was released just a couple of months ago, as an example. >> >> * if people are still using it in production in 2012, it is easy to >> maintain an external handler. > > External handler is good idea generally for all handlers. And yes, > enterprise are still using it in production in 2199. They'd have to be both: - upgrading Django - upgrading Python (since by Django1.5 you'll need Python2.7 iirc) - not upgrading apache (I'd expect mod_python will break with new apache releases at some point) - not upgrading mod_python > -1. This is'nt arguments to remove support for mod_python. It's produce > sensless work. As Gustavo said in the other thread, removing mod_python will simplify request handling quite a bit, allow Django to be a pure WSGI application (so it can interact better with other Python WSGI apps), and it's less code to maintain - we don't want unused code rotting in the Django codebase. 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Making WSGIHandler the only handler / mod_python support
Nice timing :) On Wed, Jun 23, 2010 at 11:22 AM, Gustavo Narea wrote: > > I'm going to work on some patches to improve WSGI support, and I found > something that, if changed, could make my patches and django.core.handlers > simpler... As well as make it possible to use WSGI middleware with Django > under mod_python. It seems like a tonne of work to *add* compatibility for something we don't want people to use... if someone wants to use wsgi middleware under mod-python, I don't see why Django should help that - go install mod_wsgi! I'd suggest that you add features to the WSGI handler/request and just not support those features for people using the mod_python handler? Then the compatibility work is just not making sure you don't break mod-python. 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.3: Start deprecating mod_python?
On Wed, Jun 23, 2010 at 11:31 AM, Jerome Leclanche wrote: > Agreed. mod_python was already "not recommended" for very long; now > it's dead, I don't see any reason to support it for three full release > cycles. I don't either, but I figured the deprecation policy[1] applies to deployment-related code as much as any other code... [1] http://docs.djangoproject.com/en/1.2/internals/release-process/#internal-release-deprecation-policy Using the 'postgresql' backend is vastly more insane than using mod_python, but it still doesn't die until 1.4... Sooner we start, sooner we finish! 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
1.3: Start deprecating mod_python?
Hey folks, While people are throwing around 1.3 ideas... I think we should start the process of deprecating and removing support for mod_python. Why? * mod_wsgi is better in every way. * mod_python hasn't had a release since 2007, or a commit since 2008; it's a dead end. The Apache Foundation board voted this month to retire it to the "Attic" - effectively beginning to wind it up. http://attic.apache.org/projects/quetzalcoatl.html * if people are still using it in production in 2012, it is easy to maintain an external handler. I'm proposing the following very predictable timeline: Django 1.3 Use of the modpython handler raises a PendingDeprecationWarning. Update the docs to discourage people from using it. Django 1.4 Use of the modpython handler raises a DeprecationWarning. Django 1.5 Remove the modpython handler from Django (and put it on bitbucket/github?) If someone magically steps up and brings it back to life, we can always halt/reverse the process. Objections? 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
On Wed, Apr 21, 2010 at 10:18 AM, SmileyChris wrote: > ... And it seems like i'm reiterating the discussion about > http://code.djangoproject.com/wiki/TicketChangeHelp > > I'm advocating for the friendly text in the ticket page itself, as I'm > not sure that was specifically mentioned in the related part of this > thread (but probably implied) Great idea :) James' stats views are a pre-cursor to my 2nd idea from above - sending "reminder" emails to people so tickets don't languish as much, with suggestions on what to do and how to get help... would need to be targeted carefully so people don't get spammed, but I think it could be helpful. Getting a "hasn't made the freeze, bumping to future release" comment when you could have found a couple of hours to finish docs & tests is a bummer... 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
On Wed, Apr 21, 2010 at 10:00 AM, Jacob Kaplan-Moss wrote: > On Tue, Apr 20, 2010 at 4:49 PM, Robert Coup > wrote: > >> I can write you a trac extension/patch - just didn't want to spend the >> time on it if nobody was keen. May be as simple as customising the >> email template, but we don't want it to send out stuff whenever >> someone is added to the CC list, etc. > > If you wrote such a extension, I'll get it onto our Trac. I'm wary of > a patch, though, so if it's not possible without one we could just > include a link to this page in a bunch of prominent places including > the email itself. I'll have a dig around in Trac over the next couple of days and see what its going to take. 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss wrote: > I like this a lot. Especially the "your next steps" part - it makes it > very obvious what the next thing interested parties should do is. > > Could you start a wiki page with this stuff? Until we figure out how > to get it more visible, it could at least serve as a sort of FAQ about > what different ticket actions mean. Starting it on the wiki means > folks can pitch in and help get the wording good. Tada... http://code.djangoproject.com/wiki/TicketChangeHelp Most of it is empty - please help fill it in! > > In the meantime, I'll look into how to get it into Trac somehow. I can write you a trac extension/patch - just didn't want to spend the time on it if nobody was keen. May be as simple as customising the email template, but we don't want it to send out stuff whenever someone is added to the CC list, etc. 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
Hi all, On Tue, Apr 20, 2010 at 8:34 AM, Gabriel Hurley wrote: > When I finally did submit my first patch, I was terrified of getting > it wrong and having it rejected. I'd seen it happen on other tickets. > As a project, I'm sure we don't want any (even potential) contributors to be terrified. How can we fix that, and encourage people to work with the process rather than deciding that Django is an elitist club and walking away? I've listed a couple of ideas below for enhancements to Trac to help a bit. What do people think? Worth spending time on? Rob :) Idea #1: When a ticket is currently closed Trac sends you an email saying "status:closed resolution:wontfix" and whatever comment is made by the person who closed it. How about a plugin for Trac that expands these ... "concise" emails with some docs and links, so reporters can (a) get a better explanation of why something has been changed, and (b) have a clear direction going forward. Just putting the comments in the email above the "resolution:wontfix" I think would provide a better (less emotional, more rational) experience for a reader. eg. Closed-as-Duplicate: " By closing duplicate tickets, we keep all the discussion about a topic in one place, which helps everyone. Your next steps: 1. Check out the linked ticket that is referred to above. 2. Add any relevant notes/patches/discussion from here to the other ticket. 3. If you don't agree that it's a duplicate, please reopen the ticket and explain why (mistakes do happen!). " likewise for the other resolutions, and also setting of custom fields (eg. needs_better_patch, needs_tests, needs_documentation). Idea #2: Have a tool that goes through open tickets and finds ones where the ticket is waiting on something (eg. docs) and nothing has happened for a while. It could email the owner and remind them that (a) Django does care, and (b) offer them some help: - suggest they add it to a "please i would love some help with (documentation)(tests)" page, along the lines of the "Little, easy improvements" page. - if its DDN, suggest they bring it up on django-developers - if they don't have time to work further on it, set the owner to nobody so it doesn't look like someone is "working" on it We could also run this a few weeks before feature-freeze so people can have a chance to add docs/tests to tickets, upgrade them to be trunk-ready, and not miss the bus for another release. And (has been suggested before?) try and automatically apply the latest patch on a ticket to trunk and add a comment if it stops applying cleanly. 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Design Czar
I think it's important to be clear here - I envisage a design czar to act like a code committer: - encourage, review, and shepherd work to completion - assess different approaches to problems, and decide if necessary - get minor improvements and fixes make into trunk - make sure there's work happening with each release - do some of it But more importantly, they need to have an overall view: - answering the "do we even *want* to do this?" questions for design - advocating for design within the community and core team - overseeing the design and usability of the website, docs, branding, and anything else - making designers feel valued, and figuring out better ways for them to contribute - looking at how we could make Django easier for designers via code - eg. improving the templating system, HTML5 vs XHTML vs HTML4, accessibility, mobile UIs, establishing conventions for CSS. These are often *coding* issues which need a design advocate or need designers views. I think this distinguishes between a "core designer" (aka. they do all the design work) from a "design czar" (or czars, over time), who make sure the design process happens in Django. 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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django needs for normal sequence of handlers for request processing
Hi Serg,
(replying to the list)
On Thu, Nov 26, 2009 at 4:09 AM, serg wrote:
>
> hmm.. yes. it's almost the same i mean.
> but, all middlewares calls for each request... It's bad (imho).
> also in 99.99% cases it wil be work nice...
> thanks!
>
> This method {'filter_ip':True} is unsafe.
>
> Look:
> First developer defined MembersAreaAuthMiddleware
> and create:
> (r'^members/', include('members.urls'), {'auth':True}),
> and second developer defined SmtpMiddleware
> (r'^private/', include('public.private.urls'), {'auth':True}),
> Conflict.
>
> If use params as names of handlers... And call them into one
> middleware... Hmm.. It will be normal handlers :)
>
Sure, I didn't say it was perfect! Just one possible solution. I doubt
the overhead of one extra function call for the middleware is going to
make that big a difference...
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.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django needs for normal sequence of handlers for request processing
On Wed, Nov 25, 2009 at 11:08 PM, serg wrote:
>
> For example:
you can already do something like this (middleware conditional on
urls) via the view middleware mechanism.
in urls:
...
(r'^members/private/', include('members.private.urls'), {'filter_ip':True}),
...
then the middleware:
class FilterIPMiddleware(object):
def process_view(self, request, view_func, view_args, view_kwargs):
if view_kwargs.get('filter_ip'):
del view_kwargs['filter_ip']
... check ip...
if ip_is_bad:
return HttpResponseForbidden("Naughty! Bad!")
http://www.djangosnippets.org/snippets/85/ describes using the same
idea to enforce certain URLs being accessed only via SSL (and
redirecting to HTTPS if they're accessed via HTTP)
HTH,
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.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Exception emails in django.core.handlers.base
On Wed, Dec 17, 2008 at 11:15 AM, Jeremy Dunck wrote: > > Put this another way-- how do other people manage high-performance > exception mailing? Maybe I'm Doing It Wrong. Run postfix on the host server and have Django send errors to localhost. Then postfix queues it and emails it on as appropriate, handling retries/errors/delays/whatever along the way. Maybe having less exceptions is a better solution though? ;) 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 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: Dynamically Altering Settings
On Fri, Dec 5, 2008 at 4:12 AM, Kyle Fox <[EMAIL PROTECTED]> wrote: > > Thanks again. At this point I'm considering removing the Sites & > CurrentSiteManager from all of our apps entirely. Maybe I was overly- > optimistic about how Sites could be used; having to write a static > file just to get Sites/CurrentSiteManager working properly is > basically a deal-breaker. We've done this for dynamic customer domains (lets call them "parties"): - ignore the sites app - have a middleware which looks at the request domain, and sees which party the request is for - it sets request.party with the Party model - then the view looks up/filters for the current party, via custom methods on the model managers - and request.party is made available in templates too. hth, 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 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: Proposal: django.forms.SafeForm - forms with built in CSRF protection
On Wed, Sep 24, 2008 at 5:29 AM, Brian Beck <[EMAIL PROTECTED]> wrote: > > On Sep 23, 12:13 pm, oggy <[EMAIL PROTECTED]> wrote: > > Could we just include something like a signed salt+timestamp > > +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because > > of the possibility of a same-IP-CSRF (affecting people behind > > proxies), but it's dead simple and doesn't require a lot of code > > change: Form -> SafeForm + request as the first parameter to __init__. > > Heck, I'd even trust sed to do it for me ;). > > Timestamp and REMOTE_ADDR wouldn't make a proper token unless we also > included the timestamp and REMOTE_ADDR as hidden fields -- the server > needs to be able to *regenerate* the token when the form is submitted > in order to validate the POSTed token. There are still ways to use these or other identifying values without the server having to store them somewhere. csrf_token = "[timestamp]/[remote_addr]/[hash]" where hash = sha1(timestamp + remote_addr + secret_key) eg. 104129/123.123.123.123/40bd001563085fc35165329ea1ff5c5ecbdbbeef base64 encode the csrf_token if you want to make it slightly more obscure. eg.MTIyMjIwNDEyOS8xMjMuMTIzLjEyMy4xMjMvNDBiZDAwMTU2MzA4NWZjMzUxNjUzMjllYTFmZjVjNWVjYmRiYmVlZg== then when you get a form submission, base64-decode it, split at "/", check the hash matches by recalculating it, then use the proximity-to-timestamp and the remote_addr to check the form validity. 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 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: would is_loggedin be better than is_anonymous?
On Thu, Jul 17, 2008 at 1:51 AM, Nathan Hoover <[EMAIL PROTECTED]> wrote: > I'll second that. I work for a large (unfortunately non-django) commercial > web property and we have the same basic set of states - anonymous, known, > and authenticated. I think it's pretty common. > Its not that hard to handle... 1. Have long-lived sessions: - if there isn't a user associated: "anonymous" - if it has a user: "known" 2. When a user logs in (ie. types their username and password): - add the user reference to the session (this is done by Django's default login view) - create a separate token (time+random+userid+secret, etc) and: - add it to the session - send it in a separate cookie (eg. auth_token) to the browser. Have this cookie being short-lived (browser session or short expiry time) 3. When you want to check for authenticated: - check the session has a user - check the auth_token cookie exists in the request - check the auth_token cookie value matches the corresponding value stored in the session if all match, the user is "authenticated". Otherwise they're "known", but need re-authenticating (ie. please confirm your password to continue), in which case the new auth_token is created as in (2). Doing all the above overrides the login view - which is common to override anyway afaik, and maybe adds a view decorator to check for "authenticated" (eg. @authenticated_login_required) HTH, maybe i should blog it or add to django-snippets. 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 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: Djangochatter [WAS: Django community aggregator and non-English posts]
On Sat, Jun 14, 2008 at 5:55 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > Well, I'd still like to be able to get feeds for keywords, too. For > instance, with all the file stuff I've been doing, I'm curious to know > what kinds of FileField problems people are dealing with. If I could > just set up a feed for FileField, knowing it would give me a daily > digest of *everything* the community is saying about it, I'd be in > heaven. Other people would be interested to hear chatter about > "newforms-admin" (and "nfa"), "1.0", "streaming uploads", etc. fwiw, you could create custom feeds for keywords using yahoo pipes pretty easily. Maybe not the ideal solution, but requires no development time :) 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 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: django templates in javascript
On Sat, May 3, 2008 at 8:40 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Was looking into using javascript templates for client side html > creation but everything was so bloated until I found this: > http://www.devhd.com/item0002.htm. It does all the heavy lifting on > the server and generates javascript functions that take a context > parameter. You can then simply include them in your html document and > call them with data on the client. > Only thing is I don't want our HTML people to have to learn a new > template language. So I was thinking why not extend > django.template.Template, either add a new render_js method or an > extra parameter to render? I could then create a generic view that > takes a template name as a parameter and returns the output of the > render_js method on that template. The Dojo javascript toolkit has support for Django templates. You can specify a context which is rendered into HTML via django templates. Tags/filters all apply, just like server side. And it easily acts as a renderer for datasets delivered via JSON/XML. http://dojotoolkit.org/book/dojo-book-0-9/part-5-dojox/dojox-dtl 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 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: django.contrib.sessions problems
On Mon, Apr 7, 2008 at 11:28 AM, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:
> Realise that I am in agreement with you that logout (and possibly login,
> I haven't worked through the implications there) should be changed to
> clear the session by default. There's no strong reason not to do that,
> since the session is over when logout is called.
(ignoring the new thread thing since i'm sure i'll miss it later)
Clearing at login-time I'm not at all sure about... reason is that data that
is 'anonymous' data can be transferred from a session into a user account
when they login for lots of sensible uses.
Simple example: a ShoppingCart model that can be related to either a user or
a session, allowing an anonymous user to shop and only login when they head
to the checkout, at which point the cart is transferred from the session to
the user.
Other uses could include preferences, personalisation ("looked at"), A-B
testing, ...
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 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: WSGI: IOError, same as mod_python?
On 16/01/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I will attempt to do more research. What makes this incredibly > frustrating is that I can't reproduce it by canceling an upload or > doing a reload in my browser. My first instinct was that as well, but > I couldn't seem to prove it. If you're on windows, try running MS Fiddler and pointing Firefox to use it as a proxy. Then quit Fiddler 1/2 way through your upload (this isn't a cancel). Firefox will suddenly have no network connection. (IE won't work for this because Fiddler automatically updates the proxy settings when it starts/stops). Or for a nice cross-platform solution just rip out your ethernet cable :) Rob. -- One Track Mind Ltd. PO Box 1604, Shortland St, Auckland, New Zealand Phone +64-9-966 0433 Fax +64-9-969 0045 Web http://www.onetrackmind.co.nz --~--~-~--~~~---~--~~ 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: Better Support for static file serving via django
On 13/12/2007, Thomas Güttler <[EMAIL PROTECTED]> wrote: > How can you check that only authorized users can access > some files? > > Files which have a coresponding FileField in the model: How can > you test that only some people are allowed to see it? > > Apache can't do it. Or at least it would be complicated. It's not /that/ complicated... http://www.djangoproject.com/documentation/apache_auth/ 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 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: Better Support for static file serving via django
On 12/12/2007, Mike Scott <[EMAIL PROTECTED]> wrote: > I've been looking at how to better serve my static files for django sites, > and I'm particularly interested in things like Javascript handling. > > For example if we were to look at RoR, they have their include tags which can > automatically compile javascript into one big file, compressing and > obfusicating it. There are a number of good tools to do javascript "compilation" - check out Dojo's compressor[1] and the way it the dojo packaging system uses layers which can be combined for different pages[2]. In our projects we've written tags to help with loading javascript into specific pages. Rob :) [1] http://dojotoolkit.org/docs/shrinksafe [2] http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds --~--~-~--~~~---~--~~ 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: An addendum to the escaping proposals
On 14/11/2007, Chris Green <[EMAIL PROTECTED]> wrote: > > > On Nov 10, 2007 8:58 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > Yeah, I'm not really sure what I mean, design-wise. I feel a little > > uncomfortable about requiring the csrf key all the time in form > > submissions, but I can't pin down why yet. As a consequence of that, the > > middleware doesn't quite do the trick for me, because it's always on > > (you can't say "don't touch this form, I'm handling it manually"). > > I think the use case for when you don't want CSRF protection is when > you are trying to encourage someone to send you POSTS. Think a > "google search engine form" on your own home page where you are > implementing the "google" part or perhaps a piece of software that > posts to home regarding an error condition. Another use case - AJAX behaviours where a page sends the django app multiple post requests without having a "form" in the html page. I process ajax requests via Newforms like any other post, so having it as part of that would be nicer imho, and allow disabling it. 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 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: Choice lookups
> On 10/30/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> > James, I think you've managed to hit (what I'd consider) the perfect
> > stride there. You have to import Entry anyway, so by making your
> > constants class attributes, you avoid the extra import requirement.
>
> It's not quite an enum, but it's close enough for my taste.
It works great for me too.
Though on further reflection, I think Jeremy's asking for something
> that's legitimately useful: it'd be nice to have some way to accept
> the human-readable value (say, in a URL) and use it to do the lookup
> with that.
Are there i18n issues that pop up here? what is the reverse of {0:_("my
value")}?
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 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: FileField question
On 29/10/2007, Justin Driscoll <[EMAIL PROTECTED]> wrote: > > To me having the two mutually-exclusive arguments sounds too much like > trying to fake static typing in a dynamic language. I don't see the > advantage of separate names for basically the same information provided in > different ways. If it walks like a duck... > > if callable(upload_to): > self.upload_to, filename = os.path.split(upload_to()) > else: > self.upload_to = upload_to After considering it again I think this would be the simple and compatible way to go. The only caveat would be to clearly specify in the docs that if you use a callable it must return a full path including filename. 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 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: FileField question
Presumably filename is optional, so only people who actually care will
use it... with that in mind, personally I'd save the back-compat
hassle and support upload_to (as it works now) as well as the
callable. And make it clear in the docs that all it does is
os.path.join() the two. It also might be worth making it clear that if
you do:
os.path.join('/my/path/', '/something/beginning/with/slash/') the
result is '/something/beginning/with/slash/' - which is not
necessarily intuitive for someone new to os.path...
Hmm. If i don't want to use upload_to, and just have a callable to
generate the entire path, then upload_to would need to be made
optional, and some check done that at least one of them is defined. It
doesn't look so nice having FileField(upload_to='',
filename=my_super_path_generator)
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 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: FileField question
On 23/10/2007, Marty Alchin <[EMAIL PROTECTED]> wrote: > > In response to some recent questions regarding FileField usage, I > thought about including a way to format the filename based on details > from the model instance itself. It's looking like it' be best to add > an argument to FileField, called 'filename' perhaps, which takes a > format string, like so (pardon the inevitable line munging): ... > file = models.FileField(upload_to='songs', > filename='%(album)s_%(track)s_%(title)s.mp3') > > However, this raises two concerns, both stemming from the fact that > given people a cookie will make them want a glass of milk: Why not allow passing a callable that can do whatever it likes? Then if they want milk they can write it themselves file = models.FileField(upload_to='songs', filename=mysuperfilenamefunc) def mysuperfilenamefunc(model): return "%(album)s_%(track)s_%(title)s.mp3" % model.__dict__ 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 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: Pluggable filestorage [was Heads-up: doing a bit of triage work]
On 18/09/2007, jedie <[EMAIL PROTECTED]> wrote: > > > On 17 Sep., 18:13, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> > wrote: > > Now, a SSH/SFTP backend... that would rock. > > Yes, SFTP would be better than normal FTP. IMHO it needs some external > Libs to support this. FTP is in the standard python lib. Paramiko is a pure-python solution which is pretty easy to use. The other main one is Twisted Conch, but its much more complex to get something up and running, and is a big dependency. 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 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: Visual recognition of Django website
On 18/09/2007, Justin Lilly <[EMAIL PROTECTED]> wrote:
>
> I personally would also like a favicon for the django sites. I took the
> liberty of creating one using django's colors and fonts (stole the d from
> the logo).
>
> http://www.flickr.com/photos/[EMAIL PROTECTED]/1397125183/
I created something very similar for my own use, which combined with a
greasemonkey script to trim the page titles of the documentation ("Django |
Formfields & Manipulators | Django Documentation" -> "Formfields &
Manipulators") makes it a lot easier for me to navigate django docs in
Firefox. (the script is below if anyone is interested.)
My take: If someone has prepared a reasonable icon, why *not* use it?
Rob :)
// ==UserScript==
// @name Django Documentation TabMaster
// @namespace http://onetrackmind.co.nz/greasemonkey_scripts
// @descriptionSimplify the Django documentation page titles so they can
be seen more easily in Tabs
// @includehttp://www.djangoproject.com/documentation/*
// ==/UserScript==
// Normally page titles are like this: "Django | Formfields & Manipulators |
Django Documentation"
// We change it to be just the Page title and then add an icon to
distinguish it from other tabs
// change the title
var title_parts = document.title.split(' | ');
if (title_parts.length == 3) {
document.title = title_parts[1]
}
// set the favicon
var icon = document.createElement("link");
icon.rel = "shortcut icon";
icon.href = "/path/to/django_favicon.png";
icon.type = "image/png";
document.documentElement.firstChild.appendChild(icon);
--~--~-~--~~~---~--~~
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: mod_python documentation issues
On 15/09/2007, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > As to not being able to post to tickets, I have always just used my > email address and it has worked. Ie., I do not have an account. The > ticket page says to use 'Your email or username' with an option of > creating a username only if you want it. It was only a few weeks back > that use of email address stopped working. If there has been some > policy change that you must have an account now, the page really needs > to be updated to reflect that. If there hasn't been a change, then > Trac must be recording somehow that my email address is a spam > source. :-( I think something changed a while back. Try creating an account at the url below, then log in and enter your email address/name into Trac like normal. Its linked (not particularly clearly from the contributing page). http://www.djangoproject.com/accounts/register/ hth, 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 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: Following OneToOne Relationships
On 06/09/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Can anyone come up a reason that OneToOne fields should not be > optionally automatically followed? Anyone for this support? > If one of the reasons for storing data separately is "update and select patterns", wouldn't it make sense not to automatically follow links? 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 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: Amazon S3 Integration
On 09/08/07, Fabien Schwob <[EMAIL PROTECTED]> wrote: > Yes, but my idea was to use boto in django-amazon. The goal (in my > mind) is to provide a layer around boto to Django : > > * A S3FileField around boto.s3 > * A django_amazon.generics.views.process_payment(request, amount) > around a future boto.fps We're on the same wavelength. Cool :) --~--~-~--~~~---~--~~ 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: Amazon S3 Integration
On 09/08/07, Fabien Schwob <[EMAIL PROTECTED]> wrote: > > I'm trying to integrate S3 support into my Django app using > > http://code.djangoproject.com/wiki/AmazonSimpleStorageService for > > now. > > > > I would like to improve the code so that it might be officially > > integrated into Django at some point. The first obvious question: Is > > this a feature that others would like to see, enough so to warrant > > having this feature 'baked-in'? Or should I just keep my hacks to > > myself? > > I think it's too specific for an inclusion in the official Django > distribution but it would be a great thing to create something like > django-amazon to handle all the Amazon Web Services in Django with : Might be worth looking into boto[1] before going too far into developing yet-another AWS client implementation, but integrating boto into Django via fields, etc would be great! [1] http://code.google.com/p/boto/ 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 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: schema evolution (new and improved)
On 08/08/2007, Derek Anderson <[EMAIL PROTECTED]> wrote: > > > i have had this exact situation happen to me before. (rolling out a > change, then another change reversing it) actually several times. i > have NEVER had a scenario where client Y says "can you please make sure > i lose my data?" > > your schema integrity in assured. the data integrity is also assured > (meaning no invalid data). but whether every value in every field is > exactly the same between two clients? that's a whole other ballgame. > but really, when have two clients EVER had exactly the same data? A number of people have already pointed this out: v1 -> v3 is not the same as v1 -> v2 -> v3 Bringing a simple example: v1: area: 16 (units hectares) v2: width: 400 (m), length: 400 (m) [width=sqrt(area*1), height=sqrt(area*1)] v3: area: 16 (units square meters) Skip the v2 migration and your values are out by a factor of 10,000. That would be a problem. If you do data transforms as part of a migration, surely you must go through each step in sequence... and if its automated, whats the big deal? Data consistency has to be guaranteed for anyone to use this! 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 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: Breaking out Django templates into a standalone library
On 08/08/2007, James Bennett <[EMAIL PROTECTED]> wrote: > > > On 8/8/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > I'd ideally like the Django installer to detect if django.template was > > already on the system, and drop Django into the same spot. As far as > > versioning, Django should check for a minimum version of Django > > templates (i.e., the version at the time of that Django's release), > > assuming it was already installed on the system; if it detected a > > version below the minimum, it would be nice for the installer to offer > > to simply overwrite the entire django namespace. > > In theory, setuptools can do this sort of "namespace" trick, but the > system which handles that has always seemed a little clunky to me. My concern would be when "setup.py install" does too much clever trickery and starts conflicting with distribution packages. You install django-templates via setup.py and it ends up in /usr/local/python2.5/site-packages, then you install django & templates from your distribution and presto, your django install now pulls in templates from a different version. I know its a contrived case and there are many other opportunities for making a mess of a system, but i'd be concerned about setuptools needing to do anything but the basics. 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 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: Shared memory across processes
Marty Alchin wrote: > Regardless though, I think Jacob makes the best point so far: Django's > cache system is robust enough to handle it if you pick a decent > backend. And if there's a need to make the built-in options more > robust, we can deal with that when the need arises. > What about registering to watch for a signal given to the web server process and invalidate the cache when that is received ? That way someone who really wants to clear the dbsettings across multiple processes can force it via a "kill -s" system script. Just an idea, 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 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: lazy-geometries/planning
Justin Bronn wrote: > The lazy geometries patch in 4322 is only a month old, and ten days > ago I incorporated portions of your patch in r5448. Not exactly what > I would consider "way off track" -- at least from my experience with > open source projects. Regardless, I'll concede that GDAL feature > additions have been prioritized over your patch for the reasons > enumerated below. > I'm not at all worried about this particular patch. I can be productive for Django and contribute code that is suitable for the gis branch (I use my own branch - I'm not waiting on checkins), but it just helps if there is some loose plan of who is working on what. Simply so that I and others don't end up writing patches for features that you/Jeremy are already working on, or for things that will be obsoleted or need significant rework due to design decisions that are already known about, but not communicated anywhere. For instance... > Utilities for importing vector and raster data (SHP files first) directly into Django models -- will be done with the forthcoming LayerMapping class. Great! I have code that does vector and raster importing, exporting, conversion from python using both gdal & ogr. How is "LayerMapping" envisaged to work? If I knew that, I could work on patches for supporting functionality. > Distance queries, calculations, and related utilities. As you said, being able to convert geometries to other SRS is a good thing. For projections using degrees we could use Vincenty's formula to calculate a geodesic distance in meters. Unit conversion is always handy as well. What other things do you have in mind, and what have you already started work on? Cheers! 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 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: lazy-geometries/planning
Justin Bronn wrote: > The lazy geometries patch in 4322 is only a month old, and ten days > ago I incorporated portions of your patch in r5448. Not exactly what > I would consider "way off track" -- at least from my experience with > open source projects. Regardless, I'll concede that GDAL feature > additions have been prioritized over your patch for the reasons > enumerated below. > I'm not at all worried about this particular patch. I can be productive for Django and contribute code that is suitable for the gis branch (I use my own branch - I'm not waiting on checkins), but it just helps if there is some loose plan of who is working on what. Simply so that I and others don't end up writing patches for features that you/Jeremy are already working on, or for things that will be obsoleted or need significant rework due to design decisions that are already known about, but not communicated anywhere. For instance... > Utilities for importing vector and raster data (SHP files first) directly into Django models -- will be done with the forthcoming LayerMapping class. Great! I have code that does vector and raster importing, exporting, conversion from python using both gdal & ogr. How is "LayerMapping" envisaged to work? If I knew that, I could work on patches for supporting functionality. > Distance queries, calculations, and related utilities. As you said, being able to convert geometries to other SRS is a good thing. For projections using degrees we could use Vincenty's formula to calculate a geodesic distance in meters. Unit conversion is always handy as well. What other things do you have in mind, and what have you already started work on? Cheers! 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 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 -~--~~~~--~~--~--~---
[gis] lazy-geometries/planning
GIS people, There don't seem to be any plans around how the gis branch is getting to its goals. For instance, the lazy geometries patch in 4322 is way off track now we have support for ogr geometries. I'm happy to write code/docs/tests, but it helps if i can see a little way into the future about what other changes are planned to happen, and who is working on what. I'm happy to have an IRC discussion to nut out details if we can find a time that suits people, or you can get me on IM - skype:robert.coup, msn/yahoo:[EMAIL PROTECTED] Cheers, 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 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: Proposal: post_create signal
Benjamin Slavin wrote: > On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote: > >> So the post_create signal would be triggered *after* the transaction was >> committed? The patch in 2154 certainly doesn't handle that case. >> > > That's not what I was trying to communicate. It was mentioned that > you won't know if "the save is successful or not" if processing is > done in pre_save. > I agree that checking post_save/pre_save doesn't work too well around create. Do you think it's better to have a single post_create signal to go with post_save/pre_save or the two signals (save_update & save_insert) as per #2154? > If it's called as is done in the patch, the save has been successful > (assuming no future rollback), meaning that any problem wasn't with > persistence of the object. > > Anyone needing to perform actions only after a successful commit is on > their own with the version of post_create being discussed. (I think > that's reasonable) > Fair enough :) 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 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: Proposal: post_create signal
Benjamin Slavin wrote: > Forest already mentioned not knowing if the object persistence will be > successful. Fair enough :) > In many cases using transactions will rollback any > changes that happen if a problem pops-up later (assuming those changes > are in the database). > So the post_create signal would be triggered *after* the transaction was committed? The patch in 2154 certainly doesn't handle that case. Cheers, 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 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: Proposal: post_create signal
Ben Schwarze wrote: > Due to this process, I was looking for a way fetch a signal after the > creation of an object. > Currently Django has the pre_save and post_save signals that will be > send before and after saving the object. But there seems to be no way > to determine whether an object has been just created or updated. > Why not connect to pre_save and check whether the primary key is None, similar to the accepted way to check for creation if you override Model.save()? 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 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: Custom field _post_create_sql()
Malcolm Tredinnick wrote:
> GIS guys, any particular reasons for the approach you took? -- laziness?
> economy? "it works, dammit!"? technical reason against the above?
>
In PostGIS, the AddGeometryColumn() function needs to be run separately
after the create table. It adds the geometry field to the table, adds
its definition (projection, geometry type, dimensions) to the
'geometry_columns' table, creates a number of constraints, etc.
Normal process for setting up a geometry table:
CREATE TABLE "mytable" (... every field /except/ geometry ones ...);
SELECT AddGeometryColumn("mytable", "mygeometryfield", 4326, "POLYGON", 2);
CREATE INDEX "mytable_mygeometryfield" ON "mytable" USING GIST
("mygeometryfield" GIST_GEOMETRY_OPS);
Thats why it needed to be post_create. post_create allows you to "fix"
anything you didn't like in a create as well or add special indexes or
constraints.
Not saying adding goodies to CREATE TABLE is bad, just that it doesn't
work everywhere.
Rob :)
--
One Track Mind Ltd.
PO Box 1604, Shortland St, Auckland, New Zealand
Phone +64-9-966 0433 Mobile +64-21-572 632
Web http://www.onetrackmind.co.nz
--~--~-~--~~~---~--~~
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: Field.contribute_to_class and contrib fields
Marty Alchin wrote: > Well yeah, I didn't mean have it be just a file object with no other > details. I was meaning it'd be a custom object that would have those > attributes, but also had standard file methods that lazily called file > system operations as necessary. Something like this: > > my_model.attachment.filename > my_model.attachment.url > my_model.attachment.read() > my_model.attachment.write() > > Such that when .read() or .write() (or whatever else) are called, it > open()s the file if it's not already open. That way, you could even do > things like write out PDFs to disk, using ReportLab. > > p = canvas.Canvas(my_model.attachment) > > I suppose adding .file wouldn't be the end of the world, but it'd be > more impressive without it, anyway. > Nah, yours sounds better, thinking it through. Clean and nice is a good thing :) I think eventually, eliminating all the get_XXX_something() methods for fields (perhaps with the exception of display) would be an ideal case. >> Side effect is now that it's always lazy - if i pass in the text >> "BANANA" it doesn't figure out its invalid before it's used later. >> >> Ideal case: >> - it's lazy when loaded from the DB >> - it's not lazy the rest of the time, so if i set an invalid value i >> find out straight away. >> > > Well, I don't know what all formats can be used to instantiate > GEOSGeometry, but you might be able to at least put together a regex > to validate that it fits the format(s). But again, I don't know all > you're doing, so I can't say whether that would suit your needs well > enough. > To know whether its valid in WKB format I think its probably easier to just try and parse it. Certainly WKT is regex'able to some extent. What about having a _first_set attribute on the proxy object that only allows laziness for the first time the value is set (ie. when it is set from the DB row)? Then any later set()s get live validation and coercion to geos objects. The key goal is to avoid instantiating 300 geos objects when 300 rows are retrieved from the database and the geometry field is never even looked at. If a view is interacting with a geometry field, then its ok to take the performance hit in return for all the benefits you get of using a geos object. 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 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: Field.contribute_to_class and contrib fields
Marty Alchin wrote: > I like that approach to this rather tricky situation. With all my > recent work on DurationField, I took a chance at trying to make your > code into something generic enough to work for both needs, and > possibly others. I'm imagining a FileField that can act as a file-type > object, lazily opening the file the first time something calls > obj.file_field.read() or obj.file_field.write(). Just an example of > what's possible. > Yeah, I just wonder whether for files/images its worth having a python object that provides the methods, since there is other metadata besides the python file object (like its name!) eg: my_model.attachment.file <- python file object my_model.attachment.filename <- filename as stored in db my_model.attachment.url <- url to file > Anyway, I noticed that I'm having some trouble with it. First, it > looks like it's not truly lazy, since the object is instantiated > during __set__, rather than __get__. Since Model.__init__ uses > setattr(self, field.attname, val) to assign values to the instance, > the descriptor's __set__ method gets triggered as soon as the data is > retrieved from the database. At least, that's one it's doing for me. > hmm. yes, i think that was a side-effect of the number of ways I worked on it before finding something clean. But that was fairly dumb by all accounts :P (Fixed now, new patch on the ticket). Side effect is now that it's always lazy - if i pass in the text "BANANA" it doesn't figure out its invalid before it's used later. Ideal case: - it's lazy when loaded from the DB - it's not lazy the rest of the time, so if i set an invalid value i find out straight away. > The other issue I'm having is with that of GEOSGeometrys srid > attribute. I don't have GeoDjango installed, but I can see what you're > trying to do with srid there, and that makes it difficult to make into > a generic descriptor. It's easy to pass in an initialization function, > but the trick is knowing whether an object has already been > initialized within the context of that field. Currently I'm having to > call it every time __get__ is called, which can't be a good thing. > That's not a problem with the patch as is, of course, just a > difficulty I'm having in getting it to work with other Field > subclasses. > I think in a few cases one might need to check whether things are valid, or do some extra magic. I changed it so that if __set__ gets a valid object (eg. just instantiated from __get__) then it does the srid-init. Maybe __get__ could call out when its instantiating to a method on the field, which can do extra initialisation. Rob :) -- One Track Mind Ltd. PO Box 1604, Shortland St, Auckland, New Zealand Phone +64-9-966 0433 Mobile +64-21-572 632 Web http://www.onetrackmind.co.nz --~--~-~--~~~---~--~~ 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: Field.contribute_to_class and contrib fields
Robert Coup wrote: > Jeremy Dunck wrote: > >> In the gis work, we'd like to contribute a fair bit of additional >> functionality to GIS fields and models with GIS fields. >> >> So far, field contributions seem to be largely done by adding >> attributes to the model, such as FileField's get_%s_url. >> >> I think this approach may just be legacy from the old codegen days, >> and I'm not sure this is a good approach when the number of >> contributions or additional attributes is large. >> >> As an example, I'd like to add GEOS attributes to GIS fields, which >> includes things like dimensions, area, intersection, boundary, convex >> hull, etc. >> >> > If we store the geometry /as/ a GEOSGeometry object, then it already has > all those attributes/methods on it :) > > I have done a first stab at lazy-instantiated geometries, which is > nearly working how I expect it to. I want to look at Gulopine's coercion > work first, but I'll attach it to a ticket by the end of the weekend so > you can look at it and see if thats the way we want to head. > Ok, my lazy-instantiated geometries patch is in there now (#4322) It uses a python descriptor to store an internal GEOSGeometry object, and creates a GEOS object when you assign a text/hex string to it. The GEOS object is only created on first access, before that it lives as the string retrieved from the db. Because model.my_geometry_field now returns a GEOS object, doing area, centroid, etc is as simple (and clear) as: model.my_geometry_field.area Not sure if it will inspire other creative solutions, but have a look. Rob :) -- One Track Mind Ltd. PO Box 1604, Shortland St, Auckland, New Zealand Phone +64-9-966 0433 Mobile +64-21-572 632 Web http://www.onetrackmind.co.nz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Trac component for GIS branch?
Hi powerful-ones, Any chance of getting a Trac component created for the django.contrib.gis stuff? Cheers 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 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: Field.contribute_to_class and contrib fields
Jeremy Dunck wrote: > In the gis work, we'd like to contribute a fair bit of additional > functionality to GIS fields and models with GIS fields. > > So far, field contributions seem to be largely done by adding > attributes to the model, such as FileField's get_%s_url. > > I think this approach may just be legacy from the old codegen days, > and I'm not sure this is a good approach when the number of > contributions or additional attributes is large. > > As an example, I'd like to add GEOS attributes to GIS fields, which > includes things like dimensions, area, intersection, boundary, convex > hull, etc. > If we store the geometry /as/ a GEOSGeometry object, then it already has all those attributes/methods on it :) I have done a first stab at lazy-instantiated geometries, which is nearly working how I expect it to. I want to look at Gulopine's coercion work first, but I'll attach it to a ticket by the end of the weekend so you can look at it and see if thats the way we want to head. 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 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: Type coercion in Django
Justin Bronn wrote:
> >From GEOSGeometry it is simple to retrieve WKT and HEX, e.g., 'g.wkt'
> or 'g.hex'. However, KML is implemented by PostGIS and can only be
> retrieved if you do "SELECT AsKML(the_geom)" on the database end.
> Further, GML (ancestor to KML, another OGC standard) and SVG can also
> be retrieved with the AsGML() and AsSVG(), respectively.
>
>
Maybe we need to provide some query helpers around those cases? Another
use case I can think of is simplifying geometries.
I've done it before via extra manager methods:
def with_kml_geometry(self, qs):
return self.get_query_set().extra(select={
'geom_kml': 'AsKML(geom)'
})
>> I haven't done any benchmarking. Justin?
>>
> Nothing scientific here, but I ran through the 150 state house
> legislature districts of Texas (4MB in SHP file) in the following
> manner
>
> geoms = [h.get_poly_geos() for h in House.objects.all()]
>
> That completed in 1.38 seconds. The database query itself took .21,
> making the overhead to be around 1.17s, significantly more than the
> database. But not too bad for processing a set of 'real-world'
> geometries covering a very large area. Definitely fast enough for
> lazy-instantiation.
>
But far too slow for always-on GEOSGeometry instantiation.
For non-GIS people that sounds really slow, but remember that often
districts are based off natural features and have tens of thousands of
points defining their boundaries. Coastlines are very good at upping the
point count!
Rob :)
--
One Track Mind Ltd.
PO Box 1604, Shortland St, Auckland, New Zealand
Phone +64-9-966 0433 Mobile +64-21-572 632
Web http://www.onetrackmind.co.nz
--~--~-~--~~~---~--~~
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: Type coercion in Django
Russell Keith-Magee wrote:
> On 4/19/07, jbronn <[EMAIL PROTECTED]> wrote:
>
>> The GIS branch (GeoDjango) is interested in type coercion.
>> Specifically, PostGIS returns geometries as hex strings to the client
>> -- it would be preferable to have this come into the model as either a
>> different type of string like WKT ("POLYGON ( .. )"), KML
>> ("...") or as a GEOSGeometry() object. For
>> example, say we have a 'ZipCode' model with a PolygonField ('poly'):
>>
>
> Ok. That's the sort of use case I was looking for.
>
> I haven't looked at the GIS branch, and my GIS knowledge from
> university is getting _very_ rusty, so you'll need to help me out a
> little.
>
> How do you handle data input of GIS types? What format is used during
> assignment?
>
It'd be nice to be able to assign a GEOSGeometry object, well known
text, and well known binary formats (and maybe KML/GML). The database
natively takes well-known-binary (WKB) as a hex string and
well-known-text (WKT) formats in assignment to a geometry field.
> To date, the database backend maintains the philosophy that whatever
> you put in (as a python type) is what you get back. If you put a
> boolean in, you get a boolean out; you put a DateTime in, you get a
> DateTime out. Is this still appropriate in the GIS setting?
>
My idea for the internal representation of a model field would be a
lazily-instantiated GEOSGeometry object, which would fill Justin's
requirements. That would also allow conversion to WKT/GML/KML/etc via
the GEOS library. And if you assigned WKT to a field it'd convert that
to a GEOSGeometry object.
However, I don't think we'd want to instantiate a GEOSGeometry object
via to_python for every model instance on the offchance the geometry
field(s) are accessed, but I haven't done any benchmarking. Justin?
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 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: Sorry...
Russell Keith-Magee wrote: > The branches are all independent, and depending on how active the > branch is, a branch may not be up to date with the trunk, let alone > other branches. If one branch were to cleanly merges into another, I > would be extremely surprised - doubly so for the more complex branches > like multi-db. > > That's not to say you can't get multi-db support into a checkout of > the gis branch - just that you will need to manually resolve a lot of > merges. Time for you to break out the Subversion manual :-) > Or look into SVK, which can potentially make this a lot easier since it tracks changes across branches/repositories. It takes some time to get your head around, but there are a number of reasonable tutorials and you can't break *too* much :) http://svk.bestpractical.com/view/HomePage Rob :) -- One Track Mind Ltd. PO Box 1604, Shortland St, Auckland, New Zealand Phone +64-9-966 0433 Mobile +64-21-572 632 Web http://www.onetrackmind.co.nz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
