Re: Silently continuing past an exception: is this proper? how else can I do this?

2016-10-23 Thread Andrew Chiw
It seems there's a problem with my code, because you're just supposed to 
pass a dict to DocumentForm (or any modelForm really), not a model instance.

I actually want to make a DocumentForm initialized with values from an 
existing Document, so I can list existing Documents and provide a way to 
re-upload them and edit their description. Is this the right way to do it? 
Or should I only create DocumentForms only for new Documents to be created?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d80c08f2-f9d6-4a3f-a0a9-7db9d4a29cee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Silently continuing past an exception: is this proper? how else can I do this?

2016-10-23 Thread Andrew Chiw
I've got my models setup in Django where a Document is a model that can be 
related to a Transaction.
Now I'd like to make a DocumentForm with a dropdown of Transactions owned 
by the current Client, so that a client can say that this Document is 
related to this Transaction.

So I wrote some code that looks like this:
class DocumentForm(forms.ModelForm):
path = forms.FileField(label='Choose a file')
description = forms.CharField(label='What is it?')
related_to = forms.ModelChoiceField(queryset=Transaction.objects.none())

class Meta:
model = Document
fields = ['description', 'path', 'related_to']

def __init__(self, *args, **kwargs):
super(DocumentForm, self).__init__(*args, **kwargs)
self.fields["related_to"].queryset = Transaction.objects.filter(
client=self.data.client)

So now I can do:
d = Document()
DocumentForm(d)

and the related_to field in this DocumentForm will automatically be 
populated by Transactions owned by the current client.

The problem is, when Document() isn't yet saved to the db, it isn't 
associated with a client. So DocumentForm's self.data.client will throw an 
exception, and I can't test for it with if.

So I'm thinking of just using try/except and doing nothing on except.

Is there a better way to do this? I heard that you shouldn't use exceptions 
for control flow, but here it looks like I am.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6cce68bc-03be-4a8c-a58b-ec9b0bf43153%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Am I missing a design pattern? My views code somehow isn't as elegant as it should be...

2016-10-21 Thread Andrew Chiw
As someone POSTs a questionnaire, I lookup some additional info about the 
IP and save that into a model's JSONField.
I'm sending the request into django-ipware's get_ip(), which will return 
the IP address as a string. Since this data is ephemeral, I put it directly 
in the constructor instead of storing the return value in a variable.
My bad, should've included the imports at the top of the file so you know 
where get_ip() comes from.

On Friday, 21 October 2016 21:33:42 UTC+2, Alex Heyden wrote:
>
> Are you intentionally sending the whole request into that constructor and 
> concatenating it to a URL string? I can't imagine any way this doesn't end 
> in disaster.
>
> I'm sure the community would happily help, but it's not at all obvious 
> from the supplied code what you're trying to do here.
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ad4ef983-3430-4058-ae24-e036cd6205f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Am I missing a design pattern? My views code somehow isn't as elegant as it should be...

2016-10-21 Thread Andrew Chiw
In my views, I have this:
def questionnaire(request):
def save_the_lead(cleaned_data, ipinfo):
email = cleaned_data.pop('email', None)
lead, created = Lead.objects.update_or_create(email=email)
lead.q = cleaned_data
lead.ipinfo = ipinfo
lead.save()
return lead

form = LeadForm(request.POST or request.GET or None)
"""
Why am I still checking for request.method == "POST"?
if POST (valid data) to questionnaire, process it.
if GET (valid data) to questionnaire, display it first. Even if it's 
all valid.
"""
if request.method == "POST":
if form.is_valid():
i = IPInfo(get_ip(request), dummy=True)
lead = save_the_lead(form.cleaned_data, i.get_result())
m = Matcher()
m.match([lead])
e = Emailer(lead)
e.send()
return redirect('results', lead.id)

return render(request, 'wizard/questionnaire.html', {'form': form})

And IPInfo looks like this:
import requests
import ipdb


class IPInfo:
def __init__(self, ip, dummy=False):
self.result = dict()
if (ip and not dummy):
response = requests.get('http://ipinfo.io/' + ip)
self.result = response.json()
elif (ip and dummy):
self.result = {"ip": ip}

def get_result(self):
return self.result


The part I'm worried about is the IPInfo lookup class and how it is used in 
the view. I know you can mock classes in tests, but maybe I should use 
dependency injection instead? or is that not needed in Python?
If I'm missing dependency injection: I don't have control over the code 
that runs before the view, so I cannot tell it to inject another instance 
of IPInfo in there.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2777f9b7-ec87-4dc5-ac8f-de971860c83b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


In a new Model with a OneToOne(User) relationship, how to get the username?

2016-04-10 Thread Andrew Chiw
class Client(UserenaBaseProfile):
def __str__(self):
return self.name

user = models.OneToOneField(User,
unique=True,
verbose_name=_('Django Login'),
related_name='client')

name = models.CharField(max_length=100, unique=True, default=user.name)


The title says it all - this class is supposed to have a OneToOneField 
relationship with a Django User, and through django-toolbar I've seen that 
when a user signs up, the Django User is created first and then my Client 
class. But how do I get the Client class to have the same name as the 
Django User's name?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/cadbc069-1cbd-49e7-996c-fdb94adb537a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


I might need a different control panel... or do I?

2016-04-08 Thread Andrew Chiw
I'm making a Django site for a company, and the way I envision it working 
is this:
The company's employees can manage and validate clients who sign up on the 
site as well as link them to other services.
Once the clients login, they have their own little control panel where they 
can change their own profile.
The question is, can I or should I use Django's built in admin control 
panel for the clients' mini control panel?
If not, then is http://django-user-accounts.readthedocs.org/en/latest/ what 
I'm looking for?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9c3dfeb8-4c03-4622-9036-d70fd8a349eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Should I use Django's builtin control panel for user facing purposes?

2016-04-08 Thread Andrew Chiw
I'm making a Django website for a company, where the company's employees 
will validate clients that sign up.
I'm thinking that the clients should have a mini control panel where they 
can change their own information only, while the company's employees have 
their own control panel where they can manage the clients and set whether 
or not they can change their information anymore, etc.
Should I / Can I use the built in Django control panel for this purpose?
If not, is django-user-accounts what I'm looking for?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/fc08ed2a-754a-40d8-922d-059c7616f4bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.