newbie questions regarding models and admin

[Andreas Kuntzagk]

Hi,

I'm quite new to django and very new to this list.
I'm in the process of writing a small webapp for our lab.
Working with the tutorial I already put together a small model and some
admin pages.
But now I came to some stumbling blocks:

First is a broader question: I'm wondering what belongs to an admin page
and what should be in a "normal" form. I want to keep track on some
experiments so some (authenticated) users should create experiment
entries and add comments etc. And then I have "machines" where these
experiments run. These don't change so often. So does setting these
things belong into the admin area?

Second experiments of type x always consist of 8 parallel
subexperiments. How do I model this? These subexperiments should
(automagically) be named subexp1 to subexp8.

Regards, Andreas

[nek4life]

The philosophy of the admin app is that it is a simple CRUD interface
for trusted staff members to manage data. If you need data entry for
non staff members (i.e. people you do not trust with the admin) you
should create public facing forms and setup some permissions for the
users to be able to use them.

As for you second question it sounds like you need two models, one for
experiment_x and one for sub_experiment_x with a foreignkey to
experiment_x. You could probably use inline formsets to generate the
extra 8 forms. I'm not sure how you would limit the inline formsets
though to exactly 8.

Hope this helps.

On Nov 24, 5:33 am, Andreas Kuntzagk <andreas.kuntz...@mdc-berlin.de>
wrote:

[Andreas Kuntzagk]

Hi

nek4life wrote:
> The philosophy of the admin app is that it is a simple CRUD interface
> for trusted staff members to manage data. If you need data entry for
> non staff members (i.e. people you do not trust with the admin) you
> should create public facing forms and setup some permissions for the
> users to be able to use them.

Ok, will look into this.

> As for you second question it sounds like you need two models, one for
> experiment_x and one for sub_experiment_x with a foreignkey to
> experiment_x. You could probably use inline formsets to generate the
> extra 8 forms. I'm not sure how you would limit the inline formsets
> though to exactly 8.

I already have it like this. But I was wondering if there is a
possibility to set it fixed to 8. I set extra and max_num to 8 for the
StackedInline. But as far as I understand it this only works on the
admin page and not generally.
Second thing I don't know is how to have the 8 subexperiments have their
number automatically set. Is there a way to create the 8 subexperiments
when an experiment is created?

Regards, Andreas

>
> Hope this helps.
>
> On Nov 24, 5:33 am, Andreas Kuntzagk <andreas.kuntz...@mdc-berlin.de>
> wrote:
>> Hi,
>>
>> I'm quite new to django and very new to this list.
>> I'm in the process of writing a small webapp for our lab.
>> Working with the tutorial I already put together a small model and some
>> admin pages.
>> But now I came to some stumbling blocks:
>>
>> First is a broader question: I'm wondering what belongs to an admin page
>> and what should be in a "normal" form. I want to keep track on some
>> experiments so some (authenticated) users should create experiment
>> entries and add comments etc. And then I have "machines" where these
>> experiments run. These don't change so often. So does setting these
>> things belong into the admin area?
>>
>> Second experiments of type x always consist of 8 parallel
>> subexperiments. How do I model this? These subexperiments should
>> (automagically) be named subexp1 to subexp8.
>>
>> Regards, Andreas
>

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

[Tim Valenta]

Your first question about how to separate fields is not perfectly
clear to me. However, I can say that I typically put *all* fields on
the actual admin objects, since an admin is typically not the one
you're trying to restrict. Then, in your own custom views (and the
forms you render in those views), you just include the items that you
want to be publicly visible.

> But as far as I understand it this only works on the
> admin page and not generally.

You are correct. Notice how you're setting the "max_num" attribute on
your subclassed ModelAdmin. The Admin is really just an app, though
bundled with Django. Anything you do with the admin won't ever have a
Django- or site-wide impact. That might seem frustrating, but it does
help a lot for people who write general apps, which they distribute to
others. We would find it far *more* frustrating to have to deal with
site-wide side effects that only were intended for the admin site.

The actual solution, since you seem to want to make your own forms and
not use the admin, would be to code this maximum-of-8 logic into your
views. When you render the form, you'll want to do one of two things.

1) If you think you want to just hard code this, just copy and paste
your template HTML to a total of 8 times, so that your form will
appear that many times. You'll of course want to take care to use
proper HTML "name" attributes on the various elements, so that each of
the 8 forms has unique values there. Point blank, you need the 8
forms to have unique names so that they don't get in a traffic jam
when you submit the form.

2) A better solution might be to generate the 8 forms in Python in
your actual view function. slap them in a list, and then just use the
template language to iterate them with a for loop. This way, you can
more easily manipulate the data before it gets to the template.

And when they submit the form back onto the same view, the view will
check for `request.method == "POST"`, and then verify that there are
no more than 8 being submitted. Defensive coding.

> Second thing I don't know is how to have the 8 subexperiments have their
> number automatically set. Is there a way to create the 8 subexperiments
> when an experiment is created?

This can go in a couple of directions... If all you care about is the
way the name is display, you can make your __unicode__ method do
something like the following, assuming your top-level model was
"Parent", and your sub-level model was "Child"

def __unicode__(self):
total_children = self.parent.child_set.count()
return u'Experiment %d' % (i+1,) for i in range(0,
total_children)

This is a bigger hit to the database, but it could be totally
negligible if this is a fairly small project.

The idea is that you just count how many children there are, and
dynamically render a name based on their order. Once you create a new
one, it'll automatically get a name in sequence with the others.

I hope that helps.

On Nov 24, 8:11 am, Andreas Kuntzagk <andreas.kuntz...@mdc-berlin.de>