transforming form input

12 views
Skip to first unread message

Kai Kobschätzki

unread,
Jul 7, 2020, 5:59:29 PM7/7/20
to Django users
Hi:

Although I spent time with researching I have no starting point for
solving my problem. Perhaps someone of you could give me a tip..

I have a simple model.py, e.g.

class AdressData(models.Model):

    forename=models.CharField(max_length=20,null=True,blank=True)

   surname=models.CharField(max_length=10,null=True,blank=False)

  

and forms.py e.g.

class AdressForm(forms.ModelForm):

   forename=forms.CharField(required=False)

   surname=forms.CharField(required=True)

   class Meta():

      model=AdressData

     fields= ['forename',surname']


and views.py e.g.

def question(request):

   if request.method=='Post':

      form=AdressForm(request.POST)

      if form.is_valid():

         form.save()


I render one input field surname. And if the user writes one string in
the input field it should be saved to surname (so forename is None). If
the user writes two strings (separated through a white space) than the
first part should be saved to forename and the second one to surname
(and perhaps I want to make some string manipulation further). My
problem is not the string manipulation. In result I have the forename in
a variable and the surname in an other variable.

I tried my luck with def clean_surname in the form.py and I could do the
string manipulation which I want. But I did not find a way to say django
- please save e.g. 'Mike' in forename and 'Smith' in surname.

Could anyone show me the path for solving it?

Thanks in advance,

bengoshi



Clive Bruton

unread,
Jul 8, 2020, 6:45:14 PM7/8/20
to django...@googlegroups.com

On 7 Jul 2020, at 22:58, Kai Kobschätzki wrote:

> I render one input field surname. And if the user writes one string in
> the input field it should be saved to surname (so forename is
> None). If
> the user writes two strings (separated through a white space) than the
> first part should be saved to forename and the second one to surname
> (and perhaps I want to make some string manipulation further).

This isn't a "safe" way of delineating forename/surname. It isn't
that uncommon for people to have unhyphenated compound surnames, eg:

Bruce Smith Jones

To see the confusion this may cause:

https://en.wikipedia.org/wiki/Arthur_Conan_Doyle

It is better to ask for the forename input separately, or at least
give the user the option to override your decision.


-- Clive

Benjamin Schollnick

unread,
Jul 8, 2020, 6:50:31 PM7/8/20
to django...@googlegroups.com
What I generally do is use https://pypi.org/project/nameparser/

While Clive is correct, I haven’t seen name parser fail at breaking it apart correct so far.

- Benjamin
> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-users/E644135A-7C74-4689-B3CB-6AA03224AC84%40indx.co.uk.

Kai Kobschätzki

unread,
Jul 9, 2020, 7:43:02 AM7/9/20
to django...@googlegroups.com
Hi Benjamin and Clive,

thanks a lot for your response!

My explanation was mistakable because I tried to simplify it. My reals
use case is accountancy (German-GAAP). If I get an accounting record I
have two accounts, for example telephone costs and bank. If my company
is liable to VAT I have to register the input VAT, too. These will be
realized through accounting numbers, e.g. for telephon costs 04930 and
for bank 01200, normal input-VAT-rate is 9.

Usually the VAT will be not record in an own field, you combine it with
the cost-account. So you have one field where you write '904930'. (e.g.
9,90€ | 904930 | 1200 | 09.07.2020 | Vodafone; and if you are not able
to get the input VAT you 'd write 9,90 € | 4930 | 1200 | 09.07.2020 |
Vodafone).
In the background I have to save it in two data fields debit-account
(04930) and VAT (9). It is not a problem to divide 9 and 04930 through
slicing. But I wasn't able to say django - hey, now I have more data
than input fields, please do it in the database anyway. This notation is
the method of the biggest accounting software here so I would adapt it,
because it is boosting the usability.

Greetings

bengoshi
Reply all
Reply to author
Forward
0 new messages