Re: Class based generic views in 1.3?
On Fri, Jun 4, 2010 at 1:53 PM, Roald <downa...@gmail.com> wrote: > class my_view(HttpResponse): > __metaclass__ = ABCMeta > > def __init__(self, *args, **kwargs): > print 'init my_view' > > def __new__(cls, *args, **kwargs): > if some_condition(): > return some_view(*args, **kwargs) > elif other_condition(): > return some_standard_response(*args, **kwargs) > else: > ... > return object.__new__(cls) > > > my_view.register(some_view) > my_view.register(some_standard_response) > > > This (or something like it) seems to be able to take the best of the > __new__ and __init__ options. Uhm... guys, Maybe something simpler? 8< from threading import local, Thread class View(object): _child = local() def __new__(cls, *args, **kwargs): existing = hasattr(cls._child, 'instance') if not existing: print 'first time in this thread' cls._child.instance = super(View, cls).__new__(cls, *args, **kwargs) return cls._child.instance def __call__(self, foo): print 'call', id(self), foo return 'bar' test = View() test(1) test = View() test(2) test = View() test(3) class TestThread(Thread): def run(self): test = View() test(4) t = TestThread() t.setDaemon(True) t.start() t.join() test = View() test(5) 8< Try it now, tests itself. -- Patryk Zawadzki -- 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: returning large files from django
On Fri, Aug 15, 2008 at 8:58 AM, Gábor Farkas <[EMAIL PROTECTED]> wrote: > if that's the case, isn't it possible to end the "processing" path > with a redirect? > > i mean, when you finish the "processing", is it really necessary to > serve the file? > couldn't you just send back a http-redirect? > > that way even for the first request, you could serve the image > directly by the webserver I'm in a similar situation where authorized users can generate a lot of different reports in PDF format. The files are clearly not static and while I probably can just save them with random names so random URI attacks are hard to perform, I would then need to setup a cron job to remove old files (and an individual could easily DoS the service by performing a lot of requests until the machine runs out of disk space). -- Patryk Zawadzki --~--~-~--~~~---~--~~ 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: Exposing DeclarativeFieldsMetaclass
On Mon, Aug 18, 2008 at 2:45 PM, <[EMAIL PROTECTED]> wrote: > > Hi, > > I've written a library on top of django.form that adds support for > highly dynamic forms, including removing and adding inline forms after > page load-time. To do so, I subclassed forms.BaseForm and added the > needed functionality to it. My problem is ,that I'd like to support > the same declarative syntax as forms via Form and > DeclarativeFieldsMetaclass. However, only BaseForm and Form are > exposed from the forms module and I can't use > DeclarativeFieldsMetaclass in my application. Would it be possible to > change this? The same applies to BoundField. It's also hidden inside > the module. Huh? $ ipython In [1]: from django.newforms.forms import DeclarativeFieldsMetaclass In [2]: DeclarativeFieldsMetaclass? Type: type Base Class: String Form: Namespace: Interactive File: /home/users/patrys/Desktop/web/django/newforms/forms.py Docstring: Metaclass that converts Field attributes to a dictionary called 'base_fields', taking into account parent class 'base_fields' as well. In [3]: from django.newforms.forms import BoundField In [4]: BoundField? Type: type Base Class: String Form: Namespace: Interactive File: /home/users/patrys/Desktop/web/django/newforms/forms.py Docstring: A Field plus data Constructor information: Definition: BoundField(self, form, field, name) -- Patryk Zawadzki --~--~-~--~~~---~--~~ 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: The block tag has multiple meanings
On Fri, Jun 27, 2008 at 4:33 PM, Antonis Christofides <[EMAIL PROTECTED]> wrote: > > Hi, > > There are essentially two things that you can do with a block: > (1) define it (or redefine it); and (2) insert it somewhere in a > template. The block tag thus performs different functions depending > on circumstances: > * If a block tag with the same name exists in an inherited > template, then the block tag merely (re)defines the block. > * If no block tag with the same name is inherited, then the block tag > at the same time defines the block AND inserts it in the template. > > In my opinion, having two substantially different operations under one > label is a cause for confusion. Explicit is better than implicit. I > wonder whether it would be better the distinguish the functionality in > "insblock" and "defblock": No, please, don't. The master template has no place to "predefine" the blocks as it's structure is outputted verbatim. Child templates on the other hand have no need to define blocks outside of other blocks so it's pretty much useless and prone to infinite loops (insert a parent block in a sub-sub-sub-child block for example). -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Kwippy - micro-blogging using django
On Fri, Jun 27, 2008 at 1:58 PM, Dipankar Sarkar <[EMAIL PROTECTED]> wrote: > > Hey guys > > I and a coupla more django developers recently released a micro- > blogging platform called kwippy (http://kwippy.com) ... currently it > is in beta and invite only (obv mail me to get an instant invite) Wrong list. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Ordered ManyToMany
On Thu, Jun 26, 2008 at 7:36 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > The various Javascript toolkits vary wildly in their implementations; > any API attempting to unify them would necessarily become a > toolkit-onto-itself, which is *way* out of Django's scope. Totally agreed. > Many of us > probably wish that our favorite toolkit would simply be blessed for > the admin and whatnot (yay jQuery!), but that would likely become the > largest flamewar in Django history. :p I don't think so. As long as I'm not the author of django admin, I don't really care what JS is uses as long as it works and the JS not intrusive (like date and time pickers attach themselves upon page load and are not part of the widget). -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Ordered ManyToMany
On Thu, Jun 26, 2008 at 3:41 PM, OliverMarchand <[EMAIL PROTECTED]> wrote: > === Form Field/Widget === > > The normal ChoiceField has no ordering. I am no Javascript expert, but > I think it is very simple to write a widget where the selected choices > can also be ordered. Assuming that the chosen parameters appear in the > specified order in the GET or POST prtocol, the order can be retrieved > from the server. This requires JS and is pretty tied to *your* toolkit of choice. As most sites already rely on one of the toolkits, Django can't depend on any of them (at least outside of default admin templates) and providing lengthy DOM-based widgets is a waste of time (as the site will likely have to replace them with themed and toolkit-powered ones). This falls outside of Django's scope. If you need ordered lists, create models that include a sorting field. > === ManyToMany Fields === > > The above would be very useful for values stored in the database as > well. It would be nice to have an OrderedManyToMany Field. That would > assume that the intermediate table for a a many-to-many relationship > would also have a column for storing the order. One could use the id > column of the intermediate table. Do you agree that it could be very > simple to write an OrderedManyToMany Field, but simply adding the up/ > down feature to the widget? See above, use an explicit connecting model for many-to-many relations and add tour sorting fields there. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: pluralize filter bug(?!)
On Wed, Jun 11, 2008 at 2:13 AM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > You could be right. Examples are a bit hard to think of, but to my > understanding: > > * It was 1.1 meters tall > * It weighs 1.1 kilograms It starts to get ugly if you consider languages such as pl_PL. For example "computer" in Polish: * 1 komputer * 2 komputery [...] * 4 komputery * 5 komputerów [...] * 21 komputerów * 22 komputery [...] * 24 komputery * 25 komputerów but: * 1.1 komputera [...] * 1.9 komputera -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Rethinking silent failures in templates
On Wed, May 21, 2008 at 5:27 AM, Curtis <[EMAIL PROTECTED]> wrote: > > > Has anyone considered using Python's 'warnings' module? It seems like > it might be the perfect fit for this problem. > > For example, if the appropriate warn() calls were added to the > templating system, by default, problems would be sent to sys.stderr. With the little exception that writing to stdout or stderr from a fcgi/wsgi application will kill your application server with a nice "broken pipe" when deployed on production :) -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: API question for model saving
On Wed, Apr 30, 2008 at 5:22 PM, mrts <[EMAIL PROTECTED]> wrote: > Looks like enums would be the most natural solution. > As Python doesn't have enums, class attributes should be used > (module level globals would clutter the namespace). > > Adding to Malcolm's initial proposal: > > # django/db/models.py > class CreateStrategy: >MUST_CREATE = True >MUST_NOT_CREATE = False >DEFAULT = None > > # myproject/myapp/foo.py > > from django.db.models import CreateStrategy > ... >foo = Foo(params) >foo.save(create_strategy=CreateStrategy.MUST_CREATE) > ... That's all great and everything but I fail to see why we need such functionality in django core? Each of the above easily solvable with one abstract model class and as a bonus you get to pick any of the proposed notations. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: {{ something or something_else }}
On Fri, Apr 25, 2008 at 4:15 PM, Wolfram Kriesing
<[EMAIL PROTECTED]> wrote:
>
> I guess it might had been discussed, just didnt find anything.
> This extended syntax would really make some writing shorter
>
>user has {{ num_files or "no" }} files
user has {{ num_files|default:"no" }} files
--
Patryk Zawadzki
PLD Linux Distribution
--~--~-~--~~~---~--~~
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: _QuerySet.first()
On Fri, Apr 25, 2008 at 2:17 PM, Patrick J. Anderson <[EMAIL PROTECTED]> wrote: > Well, then you could also use: > > foo = MyModel.objects.all()[-1] > > Wouldn't '_Queryset.latest()' be faster than slicing a big queryset list? It's slicing on the RDBMS side unless you already evaluated the query. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Template.render() should accept a dictionary, not just a Context object
On Fri, Apr 11, 2008 at 5:49 PM, Rajeev J Sebastian <[EMAIL PROTECTED]> wrote: > On Fri, Apr 11, 2008 at 8:56 PM, Simon Willison <[EMAIL PROTECTED]> wrote: > > > > def render(self, context): > > "Display stage -- can be called many times" > > if not isinstance(context, Context): > > context = Context(context) > > return self.nodelist.render(context) > > > > This is backwards compatible and would make the template system that > > tiny bit nicer to use. > The problem with this is that we have to pass an instance of a > subclass of Context, rather than something that has the interface of a > Context. Is it a good idea ? Why not use the opposite test and check for instances of dict? -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 to django / web development altogether
2008/4/11 joyanta <[EMAIL PROTECTED]>: > > Hi, > > I am pretty much a server side and thick client software developer > trying to get into web programming, and would like to know more on > Django. I am slowly going through the tutorials etc. I am trying to > figure out which technology to use; what criteria one needs to look > into before picking a technology to create a web application (say .. > facebook or ebay, web 2.0 apps). What advantages does Django has over > Java Servlets? What to use when. And say you want to use Amazon web > services, then? I just have very little experience in web programming, > as majority of my day is spent doing C# / ADO.NET > > I would love some pointers or have a discussion. The first technology you should use is called "join django-users and not django-developers" ;) -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Re: Porting Django to Python 3.0 as a GSoC project
On Fri, Mar 28, 2008 at 8:07 PM, Daryl Spitzer <[EMAIL PROTECTED]> wrote: > On Fri, Mar 28, 2008 at 8:57 AM, Jacob Kaplan-Moss > > Ahh -- this was the part I was missing; my apologies for being dense. > > I've been thinking of 2to3 as a one-time tool -- run it to move to > > 3.0, and never look back -- not as part of a distribution process. > Unless I'm missing something, wouldn't Django likely have to include > code that would only work on 2.6 for this to work? As far as 2to3 is involved, you are supposed to modify the python 2.5 code until 2to3 gives perfect conversion, not play with the results. The goal is to prepare the code so the future move involves running one tool, not to convert now and drop 2.5 support. So the only way this could work is to alter possibly ambiguous 2.5 code and watch the diffs generated by 2to3 without actually switching to python 2.6/3.0. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Opportunity
On Wed, Mar 5, 2008 at 4:58 PM, Steve Brumwell <[EMAIL PROTECTED]> wrote: > Sorry I am new to this - what do you mean? This list is dedicated to improving django. django-users is the place you can find _users_ of django (and employ them). Your signature is one and a half screen high and contains warnings with no legal meaning (at least not where I live). Please also reply below relevant parts of a post when quoting. Should you have further questions please refer to netiquette in order to keep this list clean. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: settings imported twice Was: logging & MODPYTHON
On Wed, Mar 5, 2008 at 4:45 PM, Thomas Guettler <[EMAIL PROTECTED]> wrote: > to Patryk: Look at your code again, it will never raise: > > ''' > imported = False > if imported: > raise Exception, "already imported!" > ... > > ''' Well, obviously I need more coffee. Something like that should work though: try: reimported = imported raise Exception, "already imported!" catch NameError: imported = True -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Opportunity
On Wed, Mar 5, 2008 at 4:37 PM, Steve Brumwell <[EMAIL PROTECTED]> wrote: > Hello all, > > I am currently working on behalf of a strong and well funded start up in the > online media (2.0) space, they are growing fast and very innovative. They > need a senior level Python/Django developer to work in London. Please > contact me for further details. The role is full time and comes with an > attractive salary. 1) move to django-users 2) fix your signature skyscraper 3) remove legal threats -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: ***SPAM*** Re: logging & MODPYTHON
On Wed, Mar 5, 2008 at 3:40 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Wed, 2008-03-05 at 15:32 +0100, Thomas Guettler wrote: > [...] > > > No, it gets imported more then once: (Answer of Malcolm): > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg39061.html > > Read that carefully and you'll see the answer I have was "maybe, I'm not > sure" and it's only in some circumstances. I haven't done the analysis > to work out if we do reimport as part of the modpython path, although I > can't think why it would be reimporting. > > Somebody who cares to know about this should feel free to roll up their > sleeves and investigate. Should be as easy as adding: imported = False if imported: raise Exception, "already imported!" imported = True at the top and reading the traceback? -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Pick a value from list variable in templates
On Tue, Mar 4, 2008 at 6:54 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> Second, there's the question of weather this is a first-class
> language-level feature or a filter. If it's the former, there's a
> syntactic decision to be made; some have proposed something like ``{{
> foo.$bar }}``, but anything that looks like Perl is gonna get a
> reflexive -1 from most Pythonistas. ``{{ foo.{{ bar }} }}`` has been
> suggested too; that's extremely ugly.
What about {{ foo:bar }} (the same way you pass params to filters) or
{{ foo>bar }} (to make it possible to write {{ foo|bar:baz>lorem }} )?
--
Patryk Zawadzki
PLD Linux Distribution
--~--~-~--~~~---~--~~
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: ModelForms paranoia simplification?
On Thu, Feb 14, 2008 at 8:14 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Any strong objections to not behaving like Python here? The less magic the better. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Bug saving NUL character?
On Feb 7, 2008 4:15 AM, Alexandre Martani <[EMAIL PROTECTED]> wrote: > Hi, > When I try to save a string containing NUL character (\x00), only the > part before the character is saved. I have created a simple model: > > class Test(models.Model): >content = models.TextField() Text fields are not meant to store binary data. This might as well be the underlying RDBMS limitation. > Since python supports NUL character in strings, Django should support > them too, or at least raise an error, or just drop it, but not losing > all the end of the string. Have you confirmed that the SQL generated by Django does not contain the null character? > Also, it is possible to send a NUL > character through GET or POST, so I think this bug could lead to a SQL > Injection. What kind of injection? It did not terminate the SQL query, just the contents of one field. SQL termination in the middle of a quoted string would result in a failed transaction. Also, AFAIR Django uses prepared statements so there's no possibility to execute code from a bound variable. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Simple Generic Views, Login_Required
2007/12/26, kevinski <[EMAIL PROTECTED]>: > > Not sure how useful this would be to the majority, but I discovered a > need for user authentication when using the Simple Generic Views, so I > had to add the Login_Required argument to views.generic.simple. I > would like to recommend this tweak be added. Generic views are just regular methods so it would be easier to create a one line wrapper calling the original and decorate it with @login_required -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Odd MySQL bug
2007/12/21, Malcolm Tredinnick <[EMAIL PROTECTED]>: > Okay, everybody (or, at least, some people) are putting way to much > thought into this. Stop now. > > I've already worked around it in queryset-refactor so that we never > generate this type of query. It was used in a test and as a way to avoid > incorrect results in one other place that I've now changed. It's a > complete non-issue now that I know what the bug is. Malcolm, wouldn't it be reasonable to just call "SET SQL_AUTO_IS_NULL = 0" whenever a connection is established? It would prevent people from hitting this bug even when using custom queries (like QuerySet.extra) and would eliminate any need of workarounds as django itself does not depend on such quirks and oddities in SQL behaviour. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Generic Relation: Alter Table
2007/12/20, madhav <[EMAIL PROTECTED]>: > > as a part of using generic relations, i got struck up at one point, > where i need to run the sql to have a field: > summary = generic.GenericRelation(Summary) > > where Summary is a class defined as: > class Summary(models.Model): > id = models.AutoField(primary_key=True) > content_type = models.ForeignKey(ContentType) > content_object = generic.GenericForeignKey() > created_on = models.DateTimeField(auto_now_add= True) > modified_on = models.DateTimeField(auto_now= True) > > And I am using a class called Book which will be having the summary > field mentioned above. So to alter the Book model at the database > level, i need to run the alter table for Book. I dont know the > equivalent sql to create a generic relation column in the table. Just run ./manage.py sql and see the output. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Odd MySQL bug
2007/12/19, Malcolm Tredinnick <[EMAIL PROTECTED]>: > Clearly something is amiss here, since the "id" attribute is a primary > key column (not NULL and unique, by definition), so nothing should match > against the query. The generated SQL can be seen by looking at > Choices.objects.filter(id__exact=None).query.as_sql() and gives > > 'SELECT `null_queries_choice`.`id`, `null_queries_choice`.`poll_id`, > `null_queries_choice`.`choice` FROM `null_queries_choice` WHERE > `null_queries_choice`.`id` IS NULL' > > which looks correct. > > Now things get really weird: If you cut and paste the line that is > failing so you that you run it twice in a row, it fails the first time > (returning a row) and passes the second time (returning nothing)! Are you sure these are not artifacts from a previous query? Maybe the cursor was not properly freed or something? -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 weekly updates?
2007/12/11, Rob Hudson <[EMAIL PROTECTED]>: > On 12/11/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > > Why not use > > http://code.djangoproject.com/timeline?ticket=on=50=90=rss > > ? > > I am actually. But I did just realize the description fields has the > full details of the comment. The description field would require a > bit of processing since it contains escaped HTML, however. If you parse it with a true XML parser then the content gets unescaped on delivery. Then feed it to Python's BeautifulSoup to do anything else. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Is 'LIMIT 0' a valid query?
2007/12/11, Ian Kelly <[EMAIL PROTECTED]>: > On Dec 11, 2007 4:16 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > > Semantics of COUNT require counting all non-NULL values and some more > > naive databases might actually try to fetch all the columns while 1 > > comes from DUAL and requires no actual data fetching. > This surprises me if it's true. count(*) just counts all result rows > without checking anything for null, whereas count(1) must count all > rows for which the expression 1 is not null. count(*) is therefore > simpler and intuitively easier to optimize. Actually what you describe is COUNT(1), COUNT(*) has been subject to such abuse that most database engines actually substitute it with either COUNT(0) or COUNT(1) in early parsing phases. (This is true for Postrgres, MySQL, MS SQL and Oracle at least.) A true COUNT(*) would select each row's data for all columns and then compare the set with NULL. I believe COUNT(1) was the correct way to do it even before I was born ;) -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 weekly updates?
2007/12/11, Rob Hudson <[EMAIL PROTECTED]>: > > On 12/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > Looks like a good start. If you can sort out the details of how to > > manage this as a group effort and get a regular publication rhythm > > going, I'll poke Jacob and Adrian and see what we can do. > > Great. Thanks. I did ask Jacob if it were possible to tell Trac to > not truncate the Changeset descriptions so short. As it is, I have to > go into each changeset detail page to view the full details to > include. This *could* be automated but it would be much simpler if > truncation wasn't so short. I don't know Trac so I'm not sure if this > is a setting or not. Why not use http://code.djangoproject.com/timeline?ticket=on=50=90=rss ? -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Is 'LIMIT 0' a valid query?
2007/12/11, Ben Walton <[EMAIL PROTECTED]>: > > I was just inspecting a couple of queries my application was > outputting. I noticed that a COUNT(*) query was made, followed by a > SELECT later on, as expected, which used the result from COUNT(*) to > LIMIT the queryset to the same results. > > The COUNT(*) in this case returned 0, and the SELECT which followed it > ran the full query but with LIMIT 0 on the end. Speaking of which, since we want a number of all matching rows, wouldn't COUNT(1) be more optimal? -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: autoescape wrong approach
2007/12/10, oggie rob <[EMAIL PROTECTED]>: > > > * Escaping is solely and entirely a function of presenting data in HTML. > > * As such, escaping belongs in the component of Django which handles > > presentation of data in HTML. > > * As such, the template layer is the correct place for this. > All good arguments :) > > I'm frustrated that the template author doesn't have any detail on > whether a variable should be trusted or not, but yeah, what you say is > valid. So forms are not a reasonable place for this, and I think the > escaping decision would be better closer to the view, but you get into > issues there on an easy way to describe which fields are okay and > which aren't. The template author should only care about it if he's also the one who works on views. Other that that the programming person is always able to mark some data as safe for output (for example some HTML coming from RSS already parsed by BeautifulSoup) by encapsulating it in the correct classes. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Changing label style in some widgets RE: 4860
2007/12/5, Sandro <[EMAIL PROTECTED]>: > I'd like to start a discussion that branches off of ticket 4860. There > are a few django widgets (RadioSelect, CheckboxSelectMultiple, > others?) which produce html that has an input nested inside a label. > As Ivan pointed out, this is valid html but it just doesn't sit right > with me as I always code labels to be separate elements with only a > text node inside. > > Right now, django produces: > value="P" name="language" /> Python Which is correct and desired. If not Internet Explorer, even for="..." and id="..." wouldn't be needed (and it's not there with current Django). IE is the only browser that can't match a label with the contained input field and also the only one that needs for="..." in this case. > All of my css research and experience uses this arrangement: > > Python Which is also correct but slightly less desired. So please count me as -1. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: newforms-admin change history
2007/12/4, Karen Tracey <[EMAIL PROTECTED]>: > Anyone want to register an opinion on how deep in the hierarchy this should > go? Seems to me it could be generally useful for BaseForm to be able to > report what fields' cleaned values are different from what was specified as > initial data. +1 from me, BaseForm sounds useful. On the other hand all the magic is tied to Form (including the metaclass) and most forms already extend the Form itself (and form_for_* can be told to do so by passing Form as their base class parameter). -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: DB API - the limiting syntax, is it magic?
2007/12/4, Adrian Holovaty <[EMAIL PROTECTED]>: > No -- I guess I didn't explain myself well enough. In this case, I > wouldn't use limit(). I have two goals: > > * Retrieve all objects in the table. > * Do something special with the first one (once the whole list has > been retrieved). > > The ideal API would look like this, and it would only run a single query: > > objects = MyModel.objects.filter(site=1) > first_one = objects[0] Maybe introduce a resolve() or results() call that just returns list(self)? -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Changes to request_response have broken django-rest-interface
2007/12/3, Malcolm Tredinnick <[EMAIL PROTECTED]>: > On Mon, 2007-12-03 at 13:09 -0800, David Cramer wrote: > > For the most part I'm just doing if request.POST to validate. > > This isn't completely sufficient because it's possible to submit a form > via POST with no data (e.g. a form with checkboxes and maybe some fields > that aren't filled in). That's why we introduced request.method. What about sending a POST to a GET-encoded URI? You get both GET and POST then with possibly overlapping values. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Shameless plug - django-google
2007/12/3, Jacob Kaplan-Moss <[EMAIL PROTECTED]>: > Hey Patryk -- > > Looks cool! > > However, in the future please direct posts of this nature to > django-users. Django-dev is for discussion of developing *on* Django, > not *with* it. I know django-users might be a more suitable place for such announcements but I was hoping of getting some feedback from the devs on the quality part. It also is one of the projects that could benefit greatly from having model subclassing ability in the framework. Is there any work I can contribute to that part? I've been following the discussion for a long time and it seems there is no conclusion on the approach. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Shameless plug - django-google
Hi guys, Maybe this will be of some interest: http://code.google.com/p/django-google/ What I've done was basically wrap the Google Calendar API into Django models and some utility functions for convenience. Would love to hear from you about the quality of code as well as missing functionality. (Please note that we are using the trunk of Django and the code was not tested to work against the stable release, it would also benefit from being able to subclass models if that feature goes into trunk before 1.0) -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 1.0 features -- the definitive list
2007/11/30, Malcolm Tredinnick <[EMAIL PROTECTED]>:
> On Fri, 2007-11-30 at 16:46 +0100, Patryk Zawadzki wrote:
> > For my needs:
> >
> > * Extendable results of form_for_{instance,model} (sometimes you just
> > need to override one field in a large form)
> > * Sortable fields on forms extending other forms
>
> This is the sort of thing where it wouldn't be a complete loss if it
> didn't make it into 1.0, since form construction helpers are just that:
> helpers. They don't depend on core changes and don't require core
> changes to support them. Hence, somebody can just write something
> outside of core that meets their purposes.
>
> We're currently leaning more towards Joseph Kocherhans' replacement for
> form_for_* (not sure how backwards compatible it will end up) and whilst
> "nice to have", I don't see this as show stopper stuff for 1.0.
You seem to overlook the part about defining field order for forms
extending other forms. That's in no way related to form construction
helpers (other than being useful for them as well).
--
Patryk Zawadzki
PLD Linux Distribution
--~--~-~--~~~---~--~~
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 1.0 features -- the definitive list
2007/11/30, Adrian Holovaty <[EMAIL PROTECTED]>:
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?
For my needs:
* Extendable results of form_for_{instance,model} (sometimes you just
need to override one field in a large form)
* Sortable fields on forms extending other forms
Both are taken care of in http://code.djangoproject.com/ticket/5986
--
Patryk Zawadzki
PLD Linux Distribution
--~--~-~--~~~---~--~~
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 1.0 features -- the definitive list
2007/11/30, Forest Bond <[EMAIL PROTECTED]>: > On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote: > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too? It'd > be > nice if django 1.0-based apps could be moved to different relative mount > points > without changing .py files at all. Or was this resolved when I wasn't > looking? Start using lighttpd + fcgi instead of Apache ;) -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: hey all
2007/11/29, Shirish <[EMAIL PROTECTED]>: > > Hello everyone. > We are a group of people doing a research on middlewares. > Middlewares are really very interesting thing if you read more about > it. We all use middlewares in our daily lives n that too very > frequently. [...] > Kindly visit www.swtech.njit.edu and help us to cater you better. > I hope to see a positive response from you all. Doesn't work for me. No such DNS record. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Session Hijacking in Django
2007/11/26, David Ross @ Wolfeon <[EMAIL PROTECTED]>: > > I can be unclear at times, especially while I'm very tired. I'll have > to make an example of what I'm talking about included with an example > or so. People tend to be a bit more understanding if there is > something there to play with instead of an idea. > > I try not to use by IP due to the problem you specified. > > The way I think of the second cookie, is more like a 2nd password. > Sure, there is a possibility of a brute force with it to, but it is > less likely they'll brute force a 2nd session id key along with the > first. I see this security method implemented with login mechanisms as > well. Of course, login mechanisms are a bit easier to secure, after > the 5th try, banned. ;) I'm not sure what makes you believe that two cookies are more secure than one. Two n-bit strings are just as secure as one 2n-bit so a simple answer would be: make the session ID twice as long. Also, if you are securing an administration panel, write a custom middleware or even better a view decorator that stores the IP in the session and clears the session if the IP changes. A trivial thing to do and you are free to only apply it to views where it actually makes sense (so regular users can switch IPs as much as they want while admins get logged out if their IP changes). If you need strong security, use SSL combined with signed client certificates to authenticate (again, even SSL certificates can be bruteforced if you throw enough computing power at them). -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Fixtures without a pk
2007/11/23, Rudolph <[EMAIL PROTECTED]>: > > Structured markup can only represent tree like organised objects > (without tricks). Maybe we can keep the primary keys inside the > fixtures, but add an optional attribute that indicates that the > primary key for this object is only used to link the objects together > when importing the data? So just add and implement pk_key="discard" as parameter inside a fixture? Then the ids are only relevant in the context of matching them inside that particular fixture. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: ticket #5986, reviews welcome
On 20 Lis, 16:15, "Michal Salaban" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> We have created a patch which allows customizing the order of Fields in
> Forms.http://code.djangoproject.com/ticket/5986
>
> The initial idea (with weights) has been abandoned in favour of Meta
> data to provide flexibility (e.g. changing order in classes inheriting
> after form_for_model/form_for_instance).
>
> The last patch contains working code and unit tests.
Sorry for a shameless bump but please look into that patch. It not
only allows you to sort fields which is more than handy in cases where
the original form is beyond your control (comes from another
application) but also allows people to create Form subclasses that
extend results of form_for_{instance,model}.
Also, regression tests are included so all is guaranteed to work.
Thanks,
--
Patryk Zawadzki
PLD Linux Distribution
--~--~-~--~~~---~--~~
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: Fixtures without a pk
2007/11/23, Russell Keith-Magee <[EMAIL PROTECTED]>:
>
> On 11/23/07, Rudolph <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > My suggestion:
> > It would be nice to use the django-admin.py with an extra option to
> > dump certain data without primary keys. If you like the idea, I'll
> > file a ticket (and maybe implement it at the upcoming Django sprint).
> You're not the first to suggest the idea, and there is at least some
> merit to the idea in principle. Feel free to adopt this as your pet
> sprint issue.
>
> However, there is one big issue that requires resolution - how do
> foreign key and m2m references get serialized if the primary keys for
> the referred objects are not known? Any 'pk-less serializer' solution
> will need to come up with a good way to address this problem before it
> is seriously considered for inclusion into trunk.
How about structured markup? Both js, python and xml markup allow for
objects to include other objects. It could be for example:
({name: 'bar', foo_set: ({field: 'baz'}, {field: 'ipsum'})}, {name: 'lorem'})
--
Patryk Zawadzki
PLD Linux Distribution
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
