calculate default values for fields based on the content of other fields

[Jaroslav Dobrek]

Hello,

is there a way to calculate default values for certain fields based
on the content of other fields?

I am implementing a dictionary. Admins are supposed to add words of
certain languages and parts-of-speech. Some words of some
part-of-speech and language are, on one hand, morphologically very
regular, but, one the other hand, come with a huge number of
morphological
forms. This is true for German adjectives: They usually have 183
morphological forms (if form-meaning pairs are counted). On the other
hand, there are very few irregular adjectives. The most user-friendly
way for admins to code German adjectives would be this: The admin adds
a new adjective and types in the adjective's base form:

base form: |gut|

Then he clicks some button or saves the adjective or, ideally, does
nothing, and the program fills in the 183 fields below, using the base
form and
assuming that the adjective is regular:

attributive positive strong masculine nominative singular: |guter|
attributive positive strong masculine genitive singular: |guten|
attributive positive strong masculine dative singular: |gutem|
attributive positive strong masculine accusative singular: |guten|
...
attributive comparative strong masculine nominative singular: |
guterer|
...

The admin now has the possibility to correct the wrong forms before
saving the adjective. This way, in the vast majority of cases all the
coding is done completely
automatically. And for the very few irregular adjectives, the admin
only has to modify those
forms that have been guessed wrongly.

Any ideas how to realize this?

Jaroslav

[Tom Evans]

On Wed, Apr 4, 2012 at 2:09 PM, Jaroslav Dobrek
<jarosla...@gmail.com> wrote:
> Hello,
>
> is there a way to calculate default values for certain fields based
> on the content of other fields?
>

> […]

>
> Any ideas how to realize this?
>
> Jaroslav

Three ways immediately spring to mind.

You could override Model.save() on the model you wish to calculate
fields for. This could populate the fields if they are not already
populated and the instance has a base adjective.

Similar, but not the same, you could add a pre_save signal to that
model which does the same thing. The pre_save signal is emitted as
part of Model.save(), so you can see how similar it is.

Finally, you could leave the model unmodified, and simply make an AJAX
service for generating the various adjective forms, and hook that into
a custom admin form, adding a widget that collects the adjective from
the un-submitted form, calls the AJAX service, and populates the
appropriate fields.

Cheers

Tom

[Jaroslav Dobrek]

> You could override Model.save() on the model you wish to calculate
> fields for. This could populate the fields if they are not already
> populated and the instance has a base adjective.
>

I had thought of this possibilty, too. I would prefer it, because it
is the simplest one.
But I don't understand how to find out in the save() function if the
admin has modified the field.
If I don't know this, the field will get the default value every time
an administrator saves the word.

[Tom Evans]

save() happens before the data is saved to the database (well, its the
last things that happens in Model.save()). So you can pull the
original data from the database, and compare it to the one you are
being asked to save.

However, I don't think you need to do this at all. I would say you
would only populate the other fields if they are all empty, and the
base is not empty. If the other fields are not empty, either it has
already been pre-populated, or it has been filled in manually, and you
should not change it. Seems pretty straightforward!

Cheers

Tom

[Jaroslav Dobrek]

> However, I don't think you need to do this at all. I would say you
> would only populate the other fields if they are all empty, and the
> base is not empty. If the other fields are not empty, either it has
> already been pre-populated, or it has been filled in manually, and you
> should not change it. Seems pretty straightforward!

I think this is not an option: In the majority of cases, correcting a
form will mean to delete it.
Example: The program might generate the comparative form "magicaler"
and the superlative form
"magicalest" for the English adjective "magical". The administrator's
job is to delete these
forms. Of course, I might require every field to have a content and
use some special symbol, such
as '-' to denote that a field is empty. But I think this would
unnecessarily complicate the coders'
work. The fewer rules and conventions the coder needs to know, the
better. And it wouldn't help
either, because sometimes - for example in the case of English
adjectives of a certain length -
the program would assign this symbol or the empty string itself.

> save() happens before the data is saved to the database (well, its the
> last things that happens in Model.save()). So you can pull the
> original data from the database, and compare it to the one you are
> being asked to save.

I don't quite understand you. Where exactly is the data I am "being
asked to save"? The following
function might be an approximation to what you suggest:

def save(self, *args,
**kwargs):
#1
tmp =
self.attr_pos_str_masc_nom_sing
#2
if tmp !=
self.default_attr_pos_str_masc_nom_sing()
#3

pass
#4

else:
#5
self.attr_pos_str_masc_nom_sing =
self.default_attr_pos_str_masc_nom_sing() #6
super(GermanAdjective, self).save(*args,
**kwargs) #7

(I hope this will keep its indentation.)

In line 2, I look up the value of the field
attr_pos_str_masc_nom_sing. In line 3, I check
if the current value of this field differs from the default value for
this field. If so, I assume that
the field has been edited and do nothing. Yet, when an adjective is
created, this field is empty,
so the test is positive and nothing is done.

Jaroslav

[Xavier Ordoquy]

Hi,

I'm not sure I clearly understood your issue.
Do you want some choice fields to limit their choices according to another choice field value ?

Regards,
Xavier.

> --
> 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.
>

[Jaroslav Dobrek]

On 5 Apr., 10:40, Xavier Ordoquy <xordo...@linovia.com> wrote:
> Hi,
>
> I'm not sure I clearly understood your issue.
> Do you want some choice fields to limit their choices according to another choice field value ?

No. I want to use prepopulated editable char fields. The content of
those fields should be calculated using the content of another char
field.

[Ejah]

I think there are two sensible approaches to this:
1. Write some customer javaScript and set the values of your form fields based on the first field
2. Use a form wizard, form 1 contains the base word, form 2 contains all the various variants. As you generate form 2 after 1, you are able to use the input to create the standard via a default value.
There is a discussion on this at stackoverflow as well.
HTH

Op woensdag 4 april 2012 15:09:40 UTC+2 schreef Jaroslav Dobrek het volgende:

Op woensdag 4 april 2012 15:09:40 UTC+2 schreef Jaroslav Dobrek het volgende:

[Python_Junkie]

Capture the value from the form submitted into a variable.

Use straight sql to query the table and the field that you are interested in and translate the field based on sql.

It is not necessary to only use the ORM.

This is an abstraction layer, and sometimes the restrictions based upon using this abstraction can block what you want to accomplish.