Django talk: February 2013

Thursday, February 28, 2013

Re: 1.5 custom user model: Add User with default UserCreationForm results in "no such table: auth_user"

On Thu, Feb 28, 2013 at 5:11 AM, Eric Psalmond <epsalmond@gmail.com> wrote:

"UserCreationForm
Depends on the User model. Must be re-written for any custom user model."

I swore I RTM'ed :). Thanks!

I think it really doesn't depend on the User model - my class inherits from AbstractUser. I think with the one modification I made, it works fine. I think just a check in the form to see if AUTH_USER_MODEL is defined, and if so use that class instead of direct references to the User class would make it work 100% for any class that inherits from AbstractUser.

You'd think so, wouldn't you :-)

Internally, it's a little more complicated than that, because of the way that the currently defined User is determined at runtime. Due to the way that Python and Django load modules, there's no guarantee that the models you need will exist at the time the form is loaded, which can lead to some interesting circular dependencies. This is the major reason why UserCreationForm and UserChangeForm are bound to the User model specifically.

The good news is that you can still re-use the form logic in those two forms -- a form is just a class, so you can subclass them. If you User model subclasses AbstractUser, all the core fields have the same name and constraints, so all you need to do is redeclare the Meta portion of the class definition (to bind your subclass to your actual User model). This way you get all the logic for password/username checks, and the custom save() methods, but against your own model and field list.

Yours,

Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

error in filling data in database through admin page

hi,
i have got one error during adding data in database though admin page, actually it was working fine, but i made some attributes optional, now it's generating error..
i m adding m models.py ,
error--

<Course: computer network>" needs to have a value for field "course" before this many-to-many relationship can be used.

plz help me..

thanks in advance

error in filling data in dtabase through admin page..

from django.db import models
from PIL import Image
from lrntkr.managers import CourseManager

class University(models.Model):
name = models.CharField(max_length=70)
address = models.CharField(max_length=120,blank=True,null=True)
country = models.CharField(max_length=30)
website = models.URLField()
def __unicode__(self):
return (self.name)

class Instructor(models.Model):
name = models.CharField(max_length=70)
specilist = models.CharField(max_length=120)
about = models.CharField(max_length=200,blank=True,null=True)
email = models.EmailField()
universities = models.ManyToManyField(University)
def __unicode__(self):
return self.name

class Course(models.Model):
title = models.CharField(max_length=70)
stream = models.CharField(max_length=70)
universities = models.ManyToManyField(University)
instruct = models.ManyToManyField(Instructor)
description = models.CharField(max_length=70,blank=True, null=True)
start_date = models.CharField(max_length=30)
work_load = models.CharField(max_length=30)
logo = models.ImageField(upload_to='logos',blank=True,null=True)
intro = models.URLField(verify_exists = False, max_length = 225,blank=True,null=True)
initiative = models.URLField(verify_exists = False, max_length = 225,blank=True,null=True)
initiator = models.CharField(max_length=50,blank=True,null=True)
courseinfo = models.BooleanField(db_index=True,default=True)

objects = CourseManager()

def save(self, size=(200, 200)):
if not self.id and not self.logo:
return

super(Course, self).save()

pw = self.logo.width
ph = self.logo.height
nw = size[0]
nh = size[1]

# only do this if the image needs resizing
if (pw, ph) != (nw, nh):
filename = str(self.logo.path)
image = Image.open(filename)
pr = float(pw) / float(ph)
nr = float(nw) / float(nh)

if pr > nr:
# photo aspect is wider than destination ratio
tw = int(round(nh * pr))
image = image.resize((tw, nh), Image.ANTIALIAS)
l = int(round(( tw - nw ) / 2.0))
image = image.crop((l, 0, l + nw, nh))
elif pr < nr:
# photo aspect is taller than destination ratio
th = int(round(nw / pr))
image = image.resize((nw, th), Image.ANTIALIAS)
t = int(round(( th - nh ) / 2.0))
print((0, t, nw, t + nh))
image = image.crop((0, t, nw, t + nh))
else:
# photo aspect matches the destination ratio
image = image.resize(size, Image.ANTIALIAS)

image.save(filename)
def __unicode__(self):
return self.title

GENDER_CHOICES = (
('M', 'Male'),
('F', 'Female'),
)

class Student(models.Model):
name = models.CharField(max_length=70)
birth_date = models.DateField(blank=True, null=True)
email_id = models.EmailField()
contact_no = models.IntegerField(blank=True,null=True)
address = models.CharField(max_length=120,blank=True, null=True)
gender = models.CharField(max_length=1, choices=GENDER_CHOICES)
courses = models.ManyToManyField(Course)

def __unicode__(self):
return self.name

hi, i have got one error during adding data in database though admin page, actually it was working fine, but i made some attributes optional, now it's generating error..
i m adding m models.py ,plz help me..
thanks in advance

Re: Best practices for 1.5 configurable user model and profiles

Hi Doug,

Shawn has hit the "whys" fairly well -- the three arguments he gave are definitely the top three. Covering authentication via other sources (e.g., OAuth, etc) was another use case (although this use case would also be a candidate for a plugin app)

Taking avatar as an example -- I'd frame the question like this:

* Could your project function without the concept of an avatar? You might need to use some other drop-in graphic in place of an avatar instead, but would the absence of an avatar fundamentally stop other parts of your site from working? On your site, is the concept of an avatar so tightly bound to a User that there's no practical way you could put that functionality in a separate model? Again, without knowing specifics, I can't say for certain, but generally, I'd say the answer is no - The fact that the default new user won't have an avatar is proof of this. This means that the avatar is a good candidate for *not* being on your User model, and being kept in a separate avatar management app.

* In practice, does the database overhead for your website mean the join to the "avatar" table is prohibitively costly? Is this something you can't overcome by caching the path to the avatar graphic on a per-user basis? This is something I can't answer canonically without seeing your server logs, but I'd be willing to wager the answer is "probably not".

Yours,

Russ Magee %-)

On Thu, Feb 28, 2013 at 1:05 AM, Doug <dmeehan@gmail.com> wrote:

Russ,

Thanks so much for your reply. I guess the confusion is around the subjectivity of what is considered "identifying the user". In my case, the additional data is not application related, it is project related and would be part of a "Profile" that is used throughout the site across many applications.

I guess the more specific question would be: should user data be limited to data necessary for _authentication_. This makes sense when you take into account that the app it is a part of is "auth".

So when you say "core identifying information", do you mean authentication information? In this case, avatar would not fit the description, in much the same way that bio or location would not.

Perhaps I am overcomplicating things, but I want to create a solution that is as simple as possible without limiting flexibility.

I guess what would help is an idea of what the primary reason was for the change to the user model in 1.5. Was it primarily to address the issue of an easier way to provide alternative authentication (versus writing a separate backend)? Or was it also to make it easier to create the concept of a "profile"?

On Saturday, February 23, 2013 11:15:20 PM UTC-5, Russell Keith-Magee wrote:
Hi Doug,

Obviously, it's still early days, so "best practice" hasn't really evolved yet. However, based on what I've done with custom user models so far, my advice would be to only put on the User model those things that are part of identifying the User, and maintain a profile for any application-related information that is user specific.

So - things like a username, primary contact email address, and an avatar would be reasonable things to have on the User model.

Phone number *might* be appropriate for the User model -- depending on whether a phone number is something that is core identifying information for users of you project, or just additional profile information.

Things like a biography or current location aren't key concepts for a user -- they're something that can be isolated as part of a profile that is contained in one or many separate user-related applications.

In many respects, this is exactly the same story that Django has always maintained -- the difference is that now you have more control over exactly what is considered "core" identifying information.

Of course, there are exceptions to every rule -- and the one exception that exists here is performance based. Using profile objects requires the use of a join, and if you're doing a *lot* of profile joins, you might find that denormalizing that join, and putting profile information on the base user object may be worthwhile.

However, this should be considered a potential performance enhancement, not architectural advice -- IMHO, most users won't be dealing with enough query volume to be affected by this problem, and should be using profile objects rather than denormalizing.

Yours,
Russ Magee %-)

On Fri, Feb 22, 2013 at 11:10 PM, Doug <dme...@gmail.com> wrote:

I am curious how people are handling the new 1.5 user model with regard to User Profiles. Is it best to add all profile information to a custom user model? Or keep the user model for authentication information only and create a one-to-on or foreign key to a profile model (similar to the pre-1.5 best practice)?

In my case, users will have an avatar, a bio, a location, and other profile type information.

What are the pros and cons of each approach?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.

Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: problem in displaying data on html

thanks i got it....
thanks

On Thu, Feb 28, 2013 at 7:19 PM, Roberto López López <roberto.lopez@uni.no> wrote:

If you just output a m2m field that's normal. If you rather prefer to
iterate over it and show all the related objects, use a for loop...

On 02/28/2013 02:43 PM, Avnesh Shakya wrote:
> hi i have one problem, i want to display data from database on html page
> all data is displaying but one attribute(university name) which i
> defined as models.ManyToManyField(University) is not being displyed,
> it's not generating error but it showing msz on html page-
> <django.db.models.fields.related.ManyRelatedManager object at 0x027AF0D0>
> instead of showing university name
>
> plz help me...
> thanks
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Kind regards,

Roberto López López

System Developer
Parallab, Uni Computing
Høyteknologisenteret, Thormøhlensgate 55
N-5008 Bergen, Norway
Tel: (+47) 555 84091

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: HTML5 Offline apps with Django 1.4

Hi Ranjith,

Perhaps I've confused things here -- when you're serving offline HTML5, you need to serve (at least) 2 pages -- a page with html, and a *completely separate* second page containing the manifest. The manifest file has a content type of text/cache-manifest; your HTML is served with a normal text/html content type.

From what you describe, it sounds like you're just serving the HTML as text/cache-manifest.

Yours,

Russ Magee %-)

On Tue, Feb 26, 2013 at 10:34 AM, Ranjith Chaz <ranjjose@gmail.com> wrote:

Thanks for the reply, Russell. I had tried it already. What I get when I do this is, the html source instead of the web page. That is, the complete html code gets printed out in the browser and it happens in all browsers irrespective of mobile, desktop.
On Thursday, February 21, 2013 1:08:16 PM UTC+5:30, Ranjith Chaz wrote:
Trying to implement offline feature of HTML5. Deployed in apache2.2 with mod_wsgi plugin.

It works as expected (i.e., loads the cached page when offline) in chrome, Opera (using window.openDatabase) and other desktop browsers. However it doesn't work in Android 2.x, iPhone default browsers. Strangely, it works with Android 4.0 browser!!

Here is the code:

HTML
<!DOCTYPE HTML>      <html manifest="{{MEDIA_URL}}cache.manifest">         <head>            <meta charset="utf-8">                  <title>MyHomeStuff</title>                  <script type="text/javascript" src="{{MEDIA_URL}}MyHomeStuff.js" ></script>            <script></script>         </head>         <body>           .............         </body>      </html>
Apache conf\mime.types  text/cache-manifest manifest

\Python27\Lib\mimetypes.py  Added '.manifest': 'text/cache-manifest', into types_map dict
  (With the above addition to mimetypes.py, it started working for android 4.0)

cache.manifest  CACHE MANIFEST
  CACHE:  index.html  MyHomeStuff.js

views.py:
def offlineApp(request):      t = get_template('index.html')      html = t.render(Context({'MEDIA_URL':'http://myDomain.com/site_media/'}))      return HttpResponse(html)

  Is it required to use any specific module/middleware to handle text/manifest in django ?
Any help is appreciated. Already spent a lot of time on this!
  
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Converting Django app into a Desktop app

@Loai, how did Pyinstaller work out for you? Is that the route you took?

On Thursday, December 20, 2012 10:20:31 PM UTC-8, Loai Ghoraba wrote:

@Filib: thanks a lot, seems that is what I will need exactly :)

On Fri, Dec 21, 2012 at 1:37 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:

See also https://us.pycon.org/2012/schedule/presentation/393/ by Ryan Kelly and his 'esky' package for safely updating distributed apps. There is a link to that and other items in the above pycon talk.

Mike

On 21/12/2012 9:55am, Filip Wasilewski wrote:

Hi,

On Tuesday, December 18, 2012 5:06:19 PM UTC+1, Loai Ghoraba wrote:

Hi

I am very comfortable with Django, and I was wondering about whether
there is some way to convert a Django web app into a Desktop app
(may be not 100%), so that I can distribute it to users. May be
wrapping it in a light web server "if there is something like this".

I've been recently going through the process of distributing Django web
application with binary dependencies (NumPy/SciPy) as an one-click
executable. I have evaluated several solutions and the most effective
was creating a single-file binary package using PyInstaller
(pyinstaller.org, development version with some modifications for proper
dependency discovery). As for the web server I went with the pure-Python
CherryPy server (cherrypy.org). See https://gist.github.com/4349257 for
sample server script.

Filip
en.ig.ma

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/7umVeAxLLBAJ.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to
django-users...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

This e-mail is the property of LightIron Digital LLC. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited.

Problem with 'ModelForm' vs 'Permission'

Dear All.

I've something like this :
--------START---------
class L2GroupForm(ModelForm):
    #Try to lock ForeignKey field to single value
    class Meta:
        model = L2Group
        widgets = {
            'company_id': TextInput(),
        }

class L2GroupAdmin(admin.ModelAdmin):
    #Choose the Form
    form = L2GroupForm()
    #Filtering Listed groups, only to which have right company_id
    def queryset(self, request):
        requserid =request.session.get('_auth_user_id', None)
        qs = self.model._default_manager.get_query_set()

        if not requserid is None :
            company_filter = L2User.objects.get(pk=requserid).company_id
            if not company_filter is None:
                qs = qs.filter(company_id=company_filter)
        print qs
        return qs

    #Try to set 'company_id' field initial value
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        if db_field.name == 'company_id':
            requserid =request.session.get('_auth_user_id', None)
            if not requserid is None :
                company_filter = L2User.objects.get(pk=requserid).company_id
                if not company_filter is None:
                    kwargs['initial'] = company_filter
            return db_field.formfield(**kwargs)
        return super(L2GroupAdmin, self).formfield_for_foreignkey(
            db_field, request, **kwargs
        )

l2admin.register(L2Group, L2GroupAdmin)

--------STOP----------

Problem is :
1. When I loged in (as superuser), it says that I've no right to edit anything, but
2. When I commented the ' form = L2GroupForm()' , all is works but the company_id field not locked to single choice ... yes the initial value setup is work.

Kindly please give me your enlighten to lock a ForeignKey field to single choice.

Sincerely
-bino-

Re: password encryption

Hi Tomas,

If you dig into Django's password tools, you'll discover that we use PBKDF2 by default, and have an option to use bcrypt. We also have a pluggable backend that allows you to define your own hashing algorithm if you'd prefer something harder, or if something emerges that supersedes PBKDF2.

We haven't used SHA-based or MD5-based hashing for some time.

Yours,

Russ Magee %-)

On Wed, Feb 27, 2013 at 11:36 PM, Tomas Neme <lacrymology@gmail.com> wrote:

and here it presses an even stronger case about NOT using bcrypt but
something even slower

http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html

On Wed, Feb 27, 2013 at 12:33 PM, Tomas Neme <lacrymology@gmail.com> wrote:
> I just ran into this. It presses a pretty strong case...
>
> http://codahale.com/how-to-safely-store-a-password/
>
> --
> "The whole of Japan is pure invention. There is no such country, there
> are no such people" --Oscar Wilde
>
> |_|0|_|
> |_|_|0|
> |0|0|0|
>
> (\__/)
> (='.'=)This is Bunny. Copy and paste bunny
> (")_(") to help him gain world domination.

--
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: default filtering model admin (crud) using user obj attribute

Dear Tom and all

I really appreciate your response

On Thursday, February 28, 2013 9:13:56 PM UTC+7, Tom Evans wrote:

It seems like you are asking how to do multi-tenancy in the stock django admin?

Yes, excatly

Multi tenancy is tricky in django. Is there any reason you are not
using one of the already existing multi-tenancy efforts?

I took a look on some existing multi-tenancy efforts, but most (all ?) of them share the same Idea that there is no bussiness relation between tenant.

I need to build a solution to let tenant do business between them.

'Car' is just an example-case to make it easy to post to this group.
Let's say it's a network of Rent-Car companies , that can rent each other cars to be re-rented to the end user.
1. I want each company to be able to manage their own staff, but don't want the to touch the real 'User' model/table.
2. I want each company to be able to manage (CrUD) thei asset, but only 'See' their partner asset.
3. I want all company to do business betwen them.

Sincerely
-bino-

Re: Daemonize django server

* carlos <crocha09.09@gmail.com> [130228 13:15]:
> you try http://gunicorn.org/ is fast and easy to deploy
:) It was as simple as easy_install gunicorn
then switch to the app directory and
ran
gunicorn_django --daemon --pid djpid --bind=127.0.0.1:8001
I have a daemonized process at localhost:8001
and to shut it down
kill $(cat djpid) ## Assuming still in the app directory
I wish it could be that easy on hostmonster ....
thanks again carlos :: good tip
--
Tim
tim at tee jay forty nine dot com or akwebsoft dot com
http://www.akwebsoft.com

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Daemonize django server

* carlos <crocha09.09@gmail.com> [130228 13:15]:
> you try http://gunicorn.org/ is fast and easy to deploy
>
> Cheers
Thank you! That looks great.
--
Tim
tim at tee jay forty nine dot com or akwebsoft dot com
http://www.akwebsoft.com

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to redirect to same page on failed login

Are you tried Login Redirect ?

2013/2/28 Suneil Rudra <suneil.rudra@gmail.com>

Hi, I'm quite new to using Django, and I've searched around for a while for a solution but haven't really found anything useful.

I'm using a context processor to make my login form available from base.html. When I login in with valid details, it redirects me to the the page I logged in from as expected. However when I enter incorrect credentials it redirects me to /login/. I've tried using HttpResponse Redirect which will redirect me back to the referring page but then my form is empty so it no longer displays the field error messages. I've tried using render_to_response which gives me the field error messages but on /login/ rather than on the original page.

Any help would be much appreciated,
Thanks

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
Rafael E. Ferrero
Claro: (03562) 15514856

Re: Wording in Djang Docs: "per instance" vs "every instance"

yeah, you are right, now I see it too…I shouldn't start reading django docs at the end of a working day…
cheers and thanks again!

On Feb 28, 2013, at 9:09 PM, Tomas Neme wrote:

> your view class is.. well, that, just a class.
>
> Every time you use it in an urlpattern, calling .as_view() a new
> instance object of that class is created. So the "per instance" should
> be pretty much self explanatory
>
> On Thu, Feb 28, 2013 at 5:04 PM, Ivo Brodien <ib@brodien.de> wrote:
>> Thanks Tomas,
>>
>> now I got it! Still the original usage of "per" and "every" sounds strange to me.. it should be more like "per instance within a URL pattern", but I am not a native in English, so nevermind.
>>
>> Thanks!
>>
>> On Feb 28, 2013, at 8:54 PM, Tomas Neme wrote:
>>
>>>> This approach applies the decorator on a per-instance basis. If you want
>>>> every instance of a view to be decorated, you need to take a different
>>>> approach.
>>>
>>> This means that with "this approach" you have to apply the decorator
>>> in every instance you want modified, that is, every time you have this
>>>
>>> url(<pattern>, YourView.as_view(),...)
>>>
>>> and want it decorated, you need to wrap it, individually, like
>>>
>>> url(<pattern>, decorator(YourView.as_view()), ....)
>>>
>>> and if you want to define the entire view as decorated, so you don't
>>> need to decorate it every time you use it in an urlpattern, because it
>>> ALWAYS needs, e.g., to be login_required, you'll need to take a
>>> different approach.
>>>
>>> With function views, this was the normal case, because you did
>>>
>>> @decorator
>>> def my_view(request, *args, **kwargs):
>>> ......
>>>
>>> and you didn't need to add anything in the urls, with class-based
>>> views, you need to do this:
>>> https://docs.djangoproject.com/en/1.5/topics/class-based-views/intro/#decorating-the-class
>>>
>>>
>>> --
>>> "The whole of Japan is pure invention. There is no such country, there
>>> are no such people" --Oscar Wilde
>>>
>>> |_|0|_|
>>> |_|_|0|
>>> |0|0|0|
>>>
>>> (\__/)
>>> (='.'=)This is Bunny. Copy and paste bunny
>>> (")_(") to help him gain world domination.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
>>> To post to this group, send email to django-users@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
>
> --
> "The whole of Japan is pure invention. There is no such country, there
> are no such people" --Oscar Wilde
>
> |_|0|_|
> |_|_|0|
> |0|0|0|
>
> (\__/)
> (='.'=)This is Bunny. Copy and paste bunny
> (")_(") to help him gain world domination.
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Wording in Djang Docs: "per instance" vs "every instance"

your view class is.. well, that, just a class.

Every time you use it in an urlpattern, calling .as_view() a new
instance object of that class is created. So the "per instance" should
be pretty much self explanatory

On Thu, Feb 28, 2013 at 5:04 PM, Ivo Brodien <ib@brodien.de> wrote:
> Thanks Tomas,
>
> now I got it! Still the original usage of "per" and "every" sounds strange to me.. it should be more like "per instance within a URL pattern", but I am not a native in English, so nevermind.
>
> Thanks!
>
> On Feb 28, 2013, at 8:54 PM, Tomas Neme wrote:
>
>>> This approach applies the decorator on a per-instance basis. If you want
>>> every instance of a view to be decorated, you need to take a different
>>> approach.
>>
>> This means that with "this approach" you have to apply the decorator
>> in every instance you want modified, that is, every time you have this
>>
>> url(<pattern>, YourView.as_view(),...)
>>
>> and want it decorated, you need to wrap it, individually, like
>>
>> url(<pattern>, decorator(YourView.as_view()), ....)
>>
>> and if you want to define the entire view as decorated, so you don't
>> need to decorate it every time you use it in an urlpattern, because it
>> ALWAYS needs, e.g., to be login_required, you'll need to take a
>> different approach.
>>
>> With function views, this was the normal case, because you did
>>
>> @decorator
>> def my_view(request, *args, **kwargs):
>> ......
>>
>> and you didn't need to add anything in the urls, with class-based
>> views, you need to do this:
>> https://docs.djangoproject.com/en/1.5/topics/class-based-views/intro/#decorating-the-class
>>
>>
>> --
>> "The whole of Japan is pure invention. There is no such country, there
>> are no such people" --Oscar Wilde
>>
>> |_|0|_|
>> |_|_|0|
>> |0|0|0|
>>
>> (\__/)
>> (='.'=)This is Bunny. Copy and paste bunny
>> (")_(") to help him gain world domination.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Wording in Djang Docs: "per instance" vs "every instance"

Thanks Tomas,

now I got it! Still the original usage of "per" and "every" sounds strange to me.. it should be more like "per instance within a URL pattern", but I am not a native in English, so nevermind.

Thanks!

On Feb 28, 2013, at 8:54 PM, Tomas Neme wrote:

>> This approach applies the decorator on a per-instance basis. If you want
>> every instance of a view to be decorated, you need to take a different
>> approach.
>
> This means that with "this approach" you have to apply the decorator
> in every instance you want modified, that is, every time you have this
>
> url(<pattern>, YourView.as_view(),...)
>
> and want it decorated, you need to wrap it, individually, like
>
> url(<pattern>, decorator(YourView.as_view()), ....)
>
> and if you want to define the entire view as decorated, so you don't
> need to decorate it every time you use it in an urlpattern, because it
> ALWAYS needs, e.g., to be login_required, you'll need to take a
> different approach.
>
> With function views, this was the normal case, because you did
>
> @decorator
> def my_view(request, *args, **kwargs):
> ......
>
> and you didn't need to add anything in the urls, with class-based
> views, you need to do this:
> https://docs.djangoproject.com/en/1.5/topics/class-based-views/intro/#decorating-the-class
>
>
> --
> "The whole of Japan is pure invention. There is no such country, there
> are no such people" --Oscar Wilde
>
> |_|0|_|
> |_|_|0|
> |0|0|0|
>
> (\__/)
> (='.'=)This is Bunny. Copy and paste bunny
> (")_(") to help him gain world domination.
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

How to redirect to same page on failed login

Hi, I'm quite new to using Django, and I've searched around for a while for a solution but haven't really found anything useful.

I'm using a context processor to make my login form available from base.html. When I login in with valid details, it redirects me to the the page I logged in from as expected. However when I enter incorrect credentials it redirects me to /login/. I've tried using HttpResponse Redirect which will redirect me back to the referring page but then my form is empty so it no longer displays the field error messages. I've tried using render_to_response which gives me the field error messages but on /login/ rather than on the original page.

Any help would be much appreciated,

Thanks

Re: Wording in Djang Docs: "per instance" vs "every instance"

> This approach applies the decorator on a per-instance basis. If you want
> every instance of a view to be decorated, you need to take a different
> approach.

This means that with "this approach" you have to apply the decorator
in every instance you want modified, that is, every time you have this

url(<pattern>, YourView.as_view(),...)

and want it decorated, you need to wrap it, individually, like

url(<pattern>, decorator(YourView.as_view()), ....)

and if you want to define the entire view as decorated, so you don't
need to decorate it every time you use it in an urlpattern, because it
ALWAYS needs, e.g., to be login_required, you'll need to take a
different approach.

With function views, this was the normal case, because you did

@decorator
def my_view(request, *args, **kwargs):
......

and you didn't need to add anything in the urls, with class-based
views, you need to do this:
https://docs.djangoproject.com/en/1.5/topics/class-based-views/intro/#decorating-the-class

--
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Wording in Djang Docs: "per instance" vs "every instance"

Hello,

in the Django Docs for Class Based Views[1] it says under the green box:

This approach applies the decorator on a per-instance basis. If you want every instance of a view to be decorated, you need to take a different approach.

I don't quite get that, since "per instance" and "every instance" is for me the same, although in the context above it is used as if they were different in order to make you use a different approach.

My English is probably not good enough to get the difference so it would be nice if someone could explain it to me!

Thanks!

[1]https://docs.djangoproject.com/en/1.5/topics/class-based-views/intro/#decorating-in-urlconf

Re: Daemonize django server

* Josh Cartmell <joshcartme@gmail.com> [130228 09:48]:
> This (http://software.clapper.org/daemonize/) may do what you want and
> can be installed with homebrew on a mac, but if this is in any way a
> production setting, I wouldn't do it. The dev server hasn't gone
> through any security audits and could and probably does have unknown
> weaknesses in that regard, more info here:
> https://docs.djangoproject.com/en/dev/ref/django-admin/#runserver-port-or-address-port

Thanks Josh. Any deployment I would do would be on fastcgi or some
other recommended method in a linux environ. It is just that I
have failed to get fastcgi working on my mac and I presume that in
time, my feet will be wet enough to resolve those issues. In the meantime,
I may look into that.

--
Tim
tim at tee jay forty nine dot com or akwebsoft dot com
http://www.akwebsoft.com

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Daemonize django server

This (http://software.clapper.org/daemonize/) may do what you want and
can be installed with homebrew on a mac, but if this is in any way a
production setting, I wouldn't do it. The dev server hasn't gone
through any security audits and could and probably does have unknown
weaknesses in that regard, more info here:
https://docs.djangoproject.com/en/dev/ref/django-admin/#runserver-port-or-address-port

On Feb 28, 10:23 am, Tim Johnson <t...@akwebsoft.com> wrote:
> I'm having a hell of a time getting fastcgi to work on my mac, so
> for the time being I'll just stick with using the django server.
>
> Is it possible to daemonize the server? I would prefer that in some
> cases.
>
> Fromhttps://docs.djangoproject.com/en/dev/ref/django-admin/
> I see daemonize as an option for runfcgi but not for runserver.
>
> thanks
> --
> Tim
> tim at tee jay forty nine dot com or akwebsoft dot comhttp://www.akwebsoft.com

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Daemonize django server

I'm having a hell of a time getting fastcgi to work on my mac, so
for the time being I'll just stick with using the django server.

Is it possible to daemonize the server? I would prefer that in some
cases.

From https://docs.djangoproject.com/en/dev/ref/django-admin/
I see daemonize as an option for runfcgi but not for runserver.

thanks
--
Tim
tim at tee jay forty nine dot com or akwebsoft dot com
http://www.akwebsoft.com

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] Django Endless Pagination v2.0

Hi all,

I just released Endless Pagination v2.0: Django pagination tools supporting

Ajax, multiple and lazy pagination, Twitter-style and Digg-style pagination.

New features include Python 3 support, Javascript improvements, code clean up

and many other bug fixes and changes.

If you are interested, please take a look at the complete Changelog here:

https://django-endless-pagination.readthedocs.org/en/latest/changelog.html

Code and documentation:

Git: https://github.com/frankban/django-endless-pagination

Mercurial: https://bitbucket.org/frankban/django-endless-pagination

Docs: http://django-endless-pagination.readthedocs.org

How to contribute:

https://django-endless-pagination.readthedocs.org/en/latest/contributing.html

Many thanks.

Re: StreamingHttpResponse into a Template

Not sure if this is what you meant by "we'll probably keep the javascript reloading to process junks, waiting for the support of celery", but one option without celery is to have the initial request save a bunch of "PendingEmail" objects in the database and then redirect you to a "send_queued_emails" page that sends as many emails as it can in 5 seconds and then returns a page telling you how many it needs to send remaining and javascript to refresh the page immediately (if you use browsers that will show a blank page as soon as the refresh is initiated, you can use ajax or something for these requests).

Something somewhat closer to the celery option, but possible to set up on slightly more restrictive systems is to do the same thing with "PendingEmail" objects and set up a cron job to run a django management command every minute that consumes as many PendingEmail objects it can in 55 seconds.

For either of these solutions, make sure autocommit is enabled for those functions and that you mark an email as sent before you start the api call otherwise if somehow two things are consuming from the same queue you could send duplicate emails. Alternatively (or additionally) you could even create a lock-file or some similar thing to make sure only one thing is consuming from the queue at a time.

On Thursday, February 28, 2013 1:31:29 AM UTC-8, Stefano Tranquillini wrote:

Yes, you are perfectly right about the fact that this is a bad implementation.
the fact is that where i host the code it does not support celery (so far). so i've to find out a workaround to be able to process a bunch of external APIs Call (that include the one for sending email).
we'll probably keep the javascript reloading to process junks, waiting for the support of celery.

BTW: the StreamingHttpResposnse, when should it be used? i get the example on the docs about writing a cvs, pdf or similar, but, what else?

Thanks for the help.

On Wednesday, February 27, 2013 6:23:52 PM UTC+1, Stefano Tranquillini wrote:
Django 1.5 is just came out and it ships the StreamingHttpResponse.
What i want to do is to print the output of a stream response into a template, having for example a bar that grows based on the streamed data (something similar to a loading bar).
so far i've found a solution that basically is to write the pieces of the final html page into the generator function, so each yield does a render_to_text of a piece of the final html page (i splitted it manually) putting each time the data just processed.
The problem of this solution is that i can't have the loading bar. What I'm able to have are incremental data, so i can print out the list of processed data, but it's different to what i want to do.
Is there a way to do what i would like to do?
thanks.

Re: Use variable in my template?

By the way, in your marke.py, the "global" declaration doesn't do what you seem to think,
and may be a syntax error. I know that in some other languages, "global" is used to make
a variable available to all code. This is not the case in python. Without the "global"
declaration, any piece of code can do:

import marke

and then reference your variable as marke.marke .

The top level variables of a module which has been imported can be referenced by the
same "." syntax as is used to reference the attributes of classes and class instances.

In python "global" is used inside of a function definition to allow the function (or method)
to write to (set the value of) a variable in the global namespace (the top level of the
module in almost all cases). The function can read from (use the current value of) a
global (module top level) variable without using any special syntax. But while python
is internalizing (compiling) the function definition, if it sees you setting a variable which
you have not declared global within that function body, it makes a variable that is local
to the function. If this variable has the same name as a global variable, the global
variable is hidden from that function body. The global declaration tells python that
you really do want to use the global variable, even if you are setting it.

Bill

On Thu, Feb 28, 2013 at 11:57 AM, Bill Freeman <ke1g.nh@gmail.com> wrote:

In the lines:

    return render_to_response('polls/detail.html', {'poll': p},
                               context_instance=RequestContext(request))

you have two choices. Both:

    return render_to_response('polls/detail.html', {'poll': p, 'marke': marke},
                               context_instance=RequestContext(request))

and

    return render_to_response('polls/detail.html', {'poll': p},
                               context_instance=RequestContext(request), dict(marke=marke))

will work. Also, in both places you have the choice of the dictionary literal syntax: {...}
or the type constructor syntax: dict(...) -- it's a matter of tast, so long as the keys are
legal python identifiers. That is, the second example could also be written as:

    return render_to_response('polls/detail.html', {'poll': p},
                               context_instance=RequestContext(request), {'marke': marke})

The second argument of render_to_response is used to update the context_instance,
or to initialize a new one if context_instance is not provided.

As to where marke comes from, my suggestions were written from the point of view
that your marke.py worked, and that you had done:

import marke

Higher in the file. Since I don't understand the purpose of marke (versus a constant
string, or an attribute of an image field on one of your models, I can't help you with
it. Perhaps you could better describe why this is a variable, and from where its
contents are intended to come?

Bill

On Thu, Feb 28, 2013 at 11:30 AM, Maria <mariahenkel@gmx.de> wrote:

Can you tell me where exactly to insert that Variable?

def detail(request, poll_id):
    p = get_object_or_404(Poll, pk=poll_id)
    return render_to_response('polls/detail.html', {'poll': p},
                                context_instance=RequestContext(request))

Also, do I have to create a class "marke"? Because up until now I only have:

from choice import*

global marke
marke = read_m()

This variable reads an image name. I want to use it for {{ marke }}.jpg

On Thursday, February 28, 2013 12:06:02 PM UTC+1, Maria wrote:

Hello everyone,

I have a variable I want to have access to in my Django template. But somehow I can't manage to do that.

I got Django/mytemplates/polls/detail.html (template) where I want to insert an image:

{% load staticfiles %}
<html>
<head>
<link href="{% static "style.css" %}" rel="stylesheet" type="text/css" media="screen" />
</head>

<body>
<img src="{{ STATIC_URL }}images/{{ marke.marke }}.jpg" alt="Picture" />

and

Django/mysite/polls/marke.py :

from choice import*
global marke
marke = read_m()

The value of marke is marke3 and I have an image marke3.jpg. I successfully used another variable to insert an image (poll.id) but this time it wont work.

The folder 'polls' is in my INSTALLED_APPS.

What can I do?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Use variable in my template?

In the lines:

    return render_to_response('polls/detail.html', {'poll': p},
                               context_instance=RequestContext(request))

you have two choices. Both:

    return render_to_response('polls/detail.html', {'poll': p, 'marke': marke},
                               context_instance=RequestContext(request))

and

    return render_to_response('polls/detail.html', {'poll': p},
                               context_instance=RequestContext(request), dict(marke=marke))

will work. Also, in both places you have the choice of the dictionary literal syntax: {...}
or the type constructor syntax: dict(...) -- it's a matter of tast, so long as the keys are
legal python identifiers. That is, the second example could also be written as:

    return render_to_response('polls/detail.html', {'poll': p},
                               context_instance=RequestContext(request), {'marke': marke})

The second argument of render_to_response is used to update the context_instance,
or to initialize a new one if context_instance is not provided.

As to where marke comes from, my suggestions were written from the point of view
that your marke.py worked, and that you had done:

import marke

Higher in the file. Since I don't understand the purpose of marke (versus a constant
string, or an attribute of an image field on one of your models, I can't help you with
it. Perhaps you could better describe why this is a variable, and from where its
contents are intended to come?

Bill

On Thu, Feb 28, 2013 at 11:30 AM, Maria <mariahenkel@gmx.de> wrote:

Can you tell me where exactly to insert that Variable?

def detail(request, poll_id):
    p = get_object_or_404(Poll, pk=poll_id)
    return render_to_response('polls/detail.html', {'poll': p},
                                context_instance=RequestContext(request))

Also, do I have to create a class "marke"? Because up until now I only have:

from choice import*

global marke
marke = read_m()

This variable reads an image name. I want to use it for {{ marke }}.jpg

On Thursday, February 28, 2013 12:06:02 PM UTC+1, Maria wrote:

Hello everyone,

I have a variable I want to have access to in my Django template. But somehow I can't manage to do that.

I got Django/mytemplates/polls/detail.html (template) where I want to insert an image:

{% load staticfiles %}
<html>
<head>
<link href="{% static "style.css" %}" rel="stylesheet" type="text/css" media="screen" />
</head>

<body>
<img src="{{ STATIC_URL }}images/{{ marke.marke }}.jpg" alt="Picture" />

and

Django/mysite/polls/marke.py :

from choice import*
global marke
marke = read_m()

The value of marke is marke3 and I have an image marke3.jpg. I successfully used another variable to insert an image (poll.id) but this time it wont work.

The folder 'polls' is in my INSTALLED_APPS.

What can I do?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: blank and null with Oracle

On Wednesday, February 27, 2013 3:31:20 PM UTC-7, Skylar Saveland wrote:

Some odd behavior with Oracle involving blank and null.

blank is True on this field:
my_auto = models.AutoField(blank=False, null=False, primary_key=True)

null is True on this field:
uncles = models.ManyToManyField(Uncle, blank=False, null=False)

These two have nothing to do with Oracle specifically. AutoFields are coerced to blank=True regardless of backend. You can see that here:

https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L534

I don't know exactly why this is done, but I would guess it is because the point of the AutoField is that it can be left blank and automatically be filled in. If you don't want that, then you probably want an IntegerField instead.

I'm not sure where null=True is getting set on the ManyToManyField, but I guess that the reason for this is that null=False represents a database constraint, and there is no way to actually set that constraint because the field does not map to an actual column in the model table; it maps to an intermediate relational table instead.

null is True on this field:
photo = models.ImageField(upload_to="uploads/")

This one is due to Oracle, because ImageField is a string-based field (it stores the filename where the image is stored). A null value here in Oracle is equivalent to an empty filename in another backend.

And, then, as documented null=True on CharFields.

Note that the docs say, "fields that have the empty string as a possible value", not specifically CharFields. This is because it also includes things like FileField, ImageField, CommaSeparatedIntegerField, GenericIPAddressField, etc.

Re: Possible bug with Form Wizard and condition_dict?

When "starting" the wizard, the "current" step is the *first* step.

The "first" step is the first in the list of *currently enabled* steps.

The list of "currently enabled" steps is constructed by checking each step wrt. condition_dict.

In other words; obtaining the current step implicitly runs the callables in condition_dict, so doing that from one of the callables leads to infinite recursion.

Personally, I'm not sure whether this should be considered a bug; the wizard implementation could probably be reorganised to only check condition_dict until a "first" step was found; but the resulting behaviour would be somewhat difficult to describe; accessing wizard.steps.current from the callables in condition_dict would still be unsafe from those callables checked in order to find the "first"; i.e. in the general case, the problem cannot be solved. On the other hand, the current behaviour/limitation does not appear to be documented...

I have a hard time imagining a scenario where checking the current step makes sense for determining what steps are available --- the step being checked for would clearly not be visited on every run-through of the wizard, but if that step is enabled based on some different conditional, reusing that might make more sense? (... or at least work with the current wizard.)

A possible workaround may be to store some data on an instance member on the wizard object --- or on the wizard objects storage --- in process_step(), and then check that in the callable.

On Friday, 5 October 2012 17:16:02 UTC+2, Scott Woodall wrote:

I searched the bug tracker and the django users with no results, so is what I'm seeing a bug?

I have a form wizard that is using a callable within condition_dict. If I try to access "wizard.steps.current" inside the callable, I get the following error:

"maximum recursion depth exceeded in __instancecheck__"
Exception Location: /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py in _reconstruct, line 307

Just trying to figure out if I should file a bug report or I'm doing something wrong?

Django talk

Thursday, February 28, 2013

Re: 1.5 custom user model: Add User with default UserCreationForm results in "no such table: auth_user"

error in filling data in database through admin page

error in filling data in dtabase through admin page..

Re: Best practices for 1.5 configurable user model and profiles

Re: problem in displaying data on html

Re: HTML5 Offline apps with Django 1.4

Re: Converting Django app into a Desktop app

Problem with 'ModelForm' vs 'Permission'

Re: password encryption

Re: default filtering model admin (crud) using user obj attribute

Re: Daemonize django server

Re: Daemonize django server

Re: How to redirect to same page on failed login

Re: Wording in Djang Docs: "per instance" vs "every instance"

Re: Wording in Djang Docs: "per instance" vs "every instance"

Re: Wording in Djang Docs: "per instance" vs "every instance"

How to redirect to same page on failed login

Re: Wording in Djang Docs: "per instance" vs "every instance"

Wording in Djang Docs: "per instance" vs "every instance"

Re: Daemonize django server

Re: Daemonize django server

Daemonize django server

[ANN] Django Endless Pagination v2.0

Re: StreamingHttpResponse into a Template

Re: Use variable in my template?

Re: Use variable in my template?

Re: blank and null with Oracle

Re: Possible bug with Form Wizard and condition_dict?

Followers

Blog Archive

About Me