Model to create forms

[Lorenzo Bernardi]

Hello All,

  I'm rather new to django and also web and database stuff and so I might not use the correct term.

  i need to write an application which is a log book for experiments. The purpose is to store information about various experiments on different experiment to keep a trace and compute some statistics on the experiments.

I have started writing one  app and creating a model for each experiments but it is rather a lengthy process and I was wondering if it would be possible to

1) offer a form generator for the experiments and store the contents in a table defined by a model. It can also be created programmatically (in starting python manage.py shell for exemple)
I was thinking using formset to define this form (using django-dynamic-formset) and it will be like a recipe thing ( I only need a few items textinput, textarea, date and predefined lists)

2) use this form to fill a database of data. (the key idea here is that the model for the data will just contain an uid (which will be created when the form is submitted) and a datatype and a value)) the many information of the forms will be stored as many rows in the database table and will be connected by the uid created when the form is submitted. It might not be clear but I got this idea from the bureaucracy plugin in dokuwiki.

Since this looks rather advanced for my skill I was wondering if
1) there is no other approach (like creating a model on the fly, that is not writing in models.py. But it looks against the way django works) and any idea is welcomed.
2) Also keeping all the experiments data in only one table and getting all the information for one experiment by finding all the row with the same uid looks a little bit a time consuming process but for now we used the bureaucracy plugin for the last six month and it doesn't look like it is slowing down too much the response of the wiki so it might not be so inefficient after all. Maybe it will scale badly. Here again any advice is welcomed.
3) The data to create the form is stored in a table (as a say, like a recipe) and so will it be better to create the form in the views.py or in the template (in that case in the view I gather the field definitions and then in templates loops through the table and create the widget at that time).

Thank for reading up to this point and if you have any suggestion or pointers related to this I'll be glad to get them (I mean even if you don't answer directly my questions I'm interested of new ideas).

sincerely

L.

[Collin Anderson]

Hi,

1) there is no other approach (like creating a model on the fly, that is not writing in models.py. But it looks against the way django works) and any idea is welcomed.

Generally I've found that creating a real model to store the data is easiest in the long run and usually involves less programming.

2) Also keeping all the experiments data in only one table and getting all the information for one experiment by finding all the row with the same uid looks a little bit a time consuming process but for now we used the bureaucracy plugin for the last six month and it doesn't look like it is slowing down too much the response of the wiki so it might not be so inefficient after all. Maybe it will scale badly. Here again any advice is welcomed.

Databases are usually good at this sort of thing. It shouldn't be a problem, but might require some database tuning.

3) The data to create the form is stored in a table (as a say, like a recipe) and so will it be better to create the form in the views.py or in the template (in that case in the view I gather the field definitions and then in templates loops through the table and create the widget at that time).

Again, it's possible to do this, but it's hard. Are all of the fields just plain text fields, or are some choice fields?

Collin

[Javier Guerra Giraldez]

On Thu, Jan 8, 2015 at 1:03 PM, Collin Anderson <cmawe...@gmail.com> wrote:
> 2) Also keeping all the experiments data in only one table and getting all
> the information for one experiment by finding all the row with the same uid
> looks a little bit a time consuming process but for now we used the
> bureaucracy plugin for the last six month and it doesn't look like it is
> slowing down too much the response of the wiki so it might not be so
> inefficient after all. Maybe it will scale badly. Here again any advice is
> welcomed.
>
> Databases are usually good at this sort of thing. It shouldn't be a problem,
> but might require some database tuning.

this is what _relational_ databases are built for. if you have two
tables, one for the description of the experiment (one record per
experiment), and another for the statistics (one record per data
sample, with a foreign key to the experiment record); then fetching
the description of the experiment, plus all the related data will be
much faster, simpler, more compact and all-around more efficient than
having one table per experiment.

databases aren't flat files, use them as designed and they'll perform very well.

--
Javier

[Lorenzo Bernardi]

Hello,

> 1) there is no other approach (like creating a model on the fly, that
> is not writing in models.py. But it looks against the way django
> works) and any idea is welcomed.
>
> Generally I've found that creating a real model to store the data is
> easiest in the long run and usually involves less programming.

It definitely looks easier for me to code a model per experiment. But
I'm writing this app for seomeone else and I foind it will be easier to
give to this person the opportunity to create by himself the definition
of the experiment. Of course it means my app should be rather simple to
make it handle this (adding or substracting field of the form or
changing things ) without loosing the data and this is where I don't
know if I can really program this. I'll try with a simpler version and
look again at our advice after some tests.

>
> 2) Also keeping all the experiments data in only one table and getting
> all the information for one experiment by finding all the row with the
> same uid looks a little bit a time consuming process but for now we
> used the bureaucracy plugin for the last six month and it doesn't look
> like it is slowing down too much the response of the wiki so it might
> not be so inefficient after all. Maybe it will scale badly. Here again
> any advice is welcomed.
>
> Databases are usually good at this sort of thing. It shouldn't be a
> problem, but might require some database tuning.
>

OK.

> 3) The data to create the form is stored in a table (as a say, like a
> recipe) and so will it be better to create the form in the views.py or
> in the template (in that case in the view I gather the field
> definitions and then in templates loops through the table and create
> the widget at that time).
>
> Again, it's possible to do this, but it's hard. Are all of the fields
> just plain text fields, or are some choice fields?
>

there are some choice field, and date field but may be I can gather some
common field in the definition of the experiment.

thanks for the information

sincerely

L.

[Lorenzo Bernardi]

Hello,

> this is what _relational_ databases are built for. if you have two
> tables, one for the description of the experiment (one record per
> experiment), and another for the statistics (one record per data
> sample, with a foreign key to the experiment record); then fetching
> the description of the experiment, plus all the related data will be
> much faster, simpler, more compact and all-around more efficient than
> having one table per experiment.

it looks to me that the resulting code should be more compact but more
difficult to write and maybe too clever for me. I'm writing this code
for someone who is not completely sure of what he really wants (I mean
the data that should be stored in the table) and so the code should be
able to accept some change in the definition of the experiments without
breaking the old data.

> databases aren't flat files, use them as designed and they'll perform very well.

I agree with that. My main worry is that I'm not so familiar with
databases and I hope I can estimate if the code will perform well in
real condition when I'll do some limited tests.

thanks for the information and I'll give it a try

sincerely

L.

[Timothy W. Cook]

I think you are looking for a way to provide an abstraction like this http://django-forms-builder.readthedocs.org/en/latest/ 

sincerely

L.

--
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...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54AEEE0B.3020408%40lpn.cnrs.fr.

For more options, visit https://groups.google.com/d/optout.

--

============================================
Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook

MLHIM http://www.mlhim.org

[Lorenzo Bernardi]

On 01/09/2015 10:39 AM, Timothy W. Cook wrote:

I think you are looking for a way to provide an abstraction like this http://django-forms-builder.readthedocs.org/en/latest/

yes it looks like I'll have to do something like that. Or see if the data collected from the form can be put in a model. Thanks for the pointer.

sincerely

L.