Computer Based Online Jobs
Here is an Easy way to Earn Money. Earn by doing Freelancing Assignments like Home Typing, Data Entry, Form Entry, Transcription etc. Most of these jobs can be done from Home with your Personal Computer. At first you can also work from Browsing Centre. Details at *http://www.imperialbiz.com/info.asp?id=3764 * --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
proposal and patch: original_filename with FileField and ImageField
Hello django developers. Currently, FIleField and ImageField store file-system-safe file name. Imagine, if user upload a file named é.txt. Yes, File-system-safe file name is .txt or _.txt. It's not special case in Japan. I know Django says non dynamic contents should be served via apache-ish server. But the other hand. Some client says file must have original name. So, I make FileField and ImageField to have their original file name like ImageField's width_field, height_field. And if original_filename_field is specified, Field encodes and stores file name as punycode. eg. input développement image.jpg: Field stores it dveloppement-image-kwa33c.jpg original_filename_field stores it développement image.jpg And I make file download generic view that uses original file name if Field has original file name attribute. attention: patch encoding is utf8. usage: class TestModel(models.Model): afile = models.FileField(upload_to='afile',original_filename_field='orgname') orgname = models.CharField(blank=True, maxlength=100) class Admin: pass (r'^file/(?P.*)/$','django.views.generic.simple.file_download', \ dict(queryset=TestModel.objects.all(),file_field='afile')), --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- filefield_and_dlgv.diff Description: Binary data
Re: Re: Default representation of a Form
as_dl() gets a +1 from me. I've used definition lists for forms and prefer it over tables. :) Lakin On 12/1/06, James Bennett <[EMAIL PROTECTED]> wrote: > > > On 12/1/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > I agree that laying out a form with CSS is not a very clean thing. But > > it does give you a way to change the layout with just CSS (like moving > > labels to the left or to the top of a field). And with tables you can't > > do it in practice. > > It can be a pain, but it doesn't have to be. For a while now, I've > been using definition lists to lay out forms (which is arguably an > acceptable use of them, depending on how you want to read the HTML > spec), and I've found that to be about the easiest thing -- the LABEL > element and associated text go into a DT, and the actual form element > goes into a DD. > > This has the accidental benefit of degrading gracefully in non-CSS > browsers, since the common representation of a definition list in > those browsers works well for a form. > > So maybe an as_dl() method needs to go in? > > ;) > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin > > > > --~--~-~--~~~---~--~~ 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: Suggestion: Aggregate/Grouping/Calculated methods in Django ORM
On 12/4/06 5:57 AM, John Lenton wrote:
> The "max", "min" and other such functions might be a little more
> problematic, unless groupby returned, rather than a generic iterator,
> a special "queryset group" and give _it_ the max/min/etc methods. This
> way it would be clear that max() returns a tuple (value, queryset) (to
> me, at least...). Also, ...groupby('foo').max() would return the same
> result as max(...groupby('foo')), but less efficiently.
>
> Talking through my hat?
No, I think not -- I think that syntax (``queryset.groupby(field).max()``)
actually looks like the best proposal for aggregates I've seen thus far...
I'm taking this to django-dev for more discussion; it'll get seen by more the
right people there.
Thoughts, anyone?
Jacob
--~--~-~--~~~---~--~~
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: Suggestion: Aggregate/Grouping/Calculated methods in Django ORM
Jacob Kaplan-Moss wrote: > No, I think not -- I think that syntax (``queryset.groupby(field).max()``) > actually looks like the best proposal for aggregates I've seen thus far... > > Thoughts, anyone? > > Jacob I think it quickly gets more complicated than that syntax would support. For example, how would you ask for more than one aggregate value in that syntax? My common use case is grouping a bunch of financial positions, where the SQL would look something like: select account, count(*), sum(quantity), sum(total_pnl) from position group by account Would I have to call queryset.groupby(account) three times: once for count(), once for sum(quantity) and once for sum(total_pnl)? And what exactly does queryset.groupby() return? In my case, if account is a ForeignKey from a Position model to an Account model, can I dereference fields from the result? account_summary = Position.objects.filter(date=today).groupby(account) for summary on account_summary: print summary.name### would this work? Is this the name property of an Account? And how would I dereference the aggregate fields in the groupby results? By index? (is account_summary[0][2] the quantity sum of the first account summary row?) I've run into all of these issues (multiple aggregate columns, dereferencing model relations, aggregate alias names) in playing around with this and I think they are all problems you run into quickly that make a solution rather complicated. My idea was a queryset.groupby() could return some sort of dynamic Django model class where the attributes where the aggregated fields plus the fields you were grouping by and if you were grouping by a relation field, it would magically work like any other model relation. But I don't know how complicated that would be and I haven't thought of a syntax that works nicely for the more complex cases. -Dave --~--~-~--~~~---~--~~ 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: Suggestion: Aggregate/Grouping/Calculated methods in Django ORM
On 12/4/06 3:30 PM, DavidA wrote:
> I think it quickly gets more complicated than that syntax would
> support.
Oh, of *course* it does -- that's why I want to discuss it more!
I think, though, that we should be able to find a 80/20 point for aggregates
and support most of the common use cases. That's pretty consistent with the
rest of Django's ORM: we don't try to model *everything* you can do with SQL,
just most of the common stuff.
I'm totally OK with making complex queries be written in SQL; it actually
turns out that SQL's a really good language for handing lots of data :)
As long as the syntax is nice, it seems that any aggregate support would be
better than none.
> For example, how would you ask for more than one aggregate
> value in that syntax? My common use case is grouping a bunch of
> financial positions, where the SQL would look something like:
>
>select account, count(*), sum(quantity), sum(total_pnl) from
> position
>group by account
>
> Would I have to call queryset.groupby(account) three times: once for
> count(), once for sum(quantity) and once for sum(total_pnl)?
My gut would be that that particular case wouldn't be supported, but::
quantity, total_pnl =
Position.objects.groupby("account").sum("quantity",
"total_pnl")
would work. So maybe you can only do one aggregate operation at once? That
seems to mesh OK with the majority of aggregate usage *I* do...
> And what exactly does queryset.groupby() return?
I was thinking it would return some proxy object that supports .sum(), .avg(),
etc. methods. By itself I don't think it would be very useful.
> My idea was a queryset.groupby() could return some sort of dynamic
> Django model class where the attributes where the aggregated fields
> plus the fields you were grouping by and if you were grouping by a
> relation field, it would magically work like any other model relation.
I don't think I follow here - can you give me an idea of what you're talking
about?
> But I don't know how complicated that would be and I haven't thought of
> a syntax that works nicely for the more complex cases.
Again, I'm OK with just supporting the simple-ish cases if that's all we can
work out.
Jacob
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Feature request for newforms: HTML 4
So I've been poking around in the newforms code, and it appears that the pre-defined widgets will be producing XHTML-style output. Now, I'm pretty picky about my markup, and I'm certainly willing to go to unusual lengths to get it just the way I want it, but it'd be awfully nice if there were some way to get HTML-style output from newforms without having to manually subclass all the widgets and override their rendering to remove trailing slashes. Unfortunately, I don't really have a good proposal for how to handle this, except maybe to further break down the Widget API to include 'as_html' and 'as_xhtml'. Any ideas? -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
A little change to wsgi.py for PUT method .
I found that in django development server , the data posted with PUT method
can't be accessed using request.POST . While it's ok with apache !
So I made a little change to django/core/handlers/wsgi.py , I've changed
line 110 to :
if self.method in ['POST', 'PUT']:
Maybe we should change the whole _load_post_and_files method in wsgi.py to
be like the one in modpython.py:
def _load_post_and_files(self):
"Populates self._post and self._files"
if self._req.headers_in.has_key('content-type') and
self._req.headers_in['content-type'].startswith('multipart'):
self._post, self._files =
http.parse_file_upload(self._req.headers_in,
self.raw_post_data)
else:
self._post, self._files = http.QueryDict(self.raw_post_data),
datastructures.MultiValueDict()
What do you think ?
By the way, I've written a simple django
collection, just
like
wsgicollection , provide a
generic RESTful interface for django models, .
--
http://codeplayer.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-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
-~--~~~~--~~--~--~---
