I did the tutorial successfully but couldn't find similar examples for small project (for better understanding of Django programming)

[softie...@gmail.com]

Hi!

I'm doing OOP now for some years (C++/C#, no Python) but never had much contact with database stuff. I did the tutorial in a virtualenv ((nearly?) current Python 3.6 for Windows and Django 1.11). Now, for better understanding of Django, I'd like to program a small website (just for internal use). I assume Django is suited for it :-)
The bad thing is that I couldn't find any similar examples (and also when I tryed to edit the tutorial program in that way, I didn't came far). Probably I just don't know the right keywords.

I'd like to do something like this:
An internal tool, let me call it "Internal car configurator". So every user(!) is allowed to do everything mentioned below.
- There're car model A, B and C (which needs to be extendable and deletable like by a "+"/"-" buttons on the website - renaming would be a plus).
- There's a table where every model has it's own row. Every model is shown there once.
- In that table, there're columns like "exterior package" and "interior package" (dropdown box to select the corresponding package). The columns need to be extendable and deletable like by a "+"/"-" buttons on the website - renaming would be a plus.
- For each like exterior and interior package, there's a number of elements which may only exist once per like "exterior" and "interior". Like for exterior "more_chrome", "bigger_wheels", ... and for interior "more_chrome" (that's completely independent of exterior "more_chrome"!), "leather_seats", "6th_and_7th_seat", ... (which needs to be extendable and deletable like by a "+"/"-" buttons on the website - renaming would be a plus).
- Packages have to be defined for each like "exterior" and "interior" (the number of and the contents in the packages need to be extendable and deletable like by a "+"/"-" buttons on the website - renaming would be a plus).
- Only the packages are selectable in the table (with rows for each model) metioned above. For each column, exactly one package must be selected (which can contain no elements and can be called like "nothing").
- Exterior packages can only contain exterior elements. E.g.: The exterior package "nothing" doesn't contain any of the (of courser only exterior) elements. The exterior package "chrome" only contains "more_chrome". The exterior package "extend" only contains "more_chrome" and "bigger wheels". The packages "everything" contains everything (of the exterior elements). Same for interior etc.
- If the contents of package is changed (element added, deleted, renamed...), this change applies immediately to all models where that package is selected.
- "everything" mustn't automatically contain new elements. New elements have to be manually added to "everything".
- Deleting a package mustn't delete elements. It's ok if there're elements which currently aren't part of any package.

Later this will be extended like by (but for that I think I'll find something on my own):
- All elements, all packages with their elements and all car models with the elements selected via selecting packages will be exported to text files in a certains format to be stored in a Git repository (so that database contents (but not the basic database structure)) can be restored from that text files, see below and that text files can be processed by other software).
- Delete current database contents and import that text files from the Git repository (=vice versa to the line above - only works if the basic database structure wasn't change since when creating that text files).
- LDAP login (also because of Git)

So if you have links or keywords to similar examples (which work with Django 1.11 very well) or could even write some example code here -> thank you! :-)

[softie...@gmail.com]

Hi!

I think I found something. But it seems to be an very old example, couldn't find forms.py (and no word about where to create it) -> http://blog.e-shell.org/130
So if anybody here has an idea -> thank you!

PS: "dynamic choices" seem to be the keywords here.

[Jani Tiainen]

Hi,

Seems that you've on right track. Just don't chew up too big bites.

I suggest that first you start mapping your real world ideas to models. Don't worry if you don't get it right at first try thats why migrations do exist.

Also test driven development model could work nicely.

Most of the things you describe are clienside operations and Django being agnostic for that you're free to implement clientside as you wish.

You probably won't find much for similar project but there might be solutions to individual problems.

18.6.2017 11.23 <softie...@gmail.com> kirjoitti:

--
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 https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f63fd9be-b5ec-4778-b1e3-b92f34dac684%40googlegroups.com.

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

[softie...@gmail.com]

Hi Jani!

Am Sonntag, 18. Juni 2017 11:05:27 UTC+2 schrieb Jani Tiainen:

Hi,

Seems that you've on right track. Just don't chew up too big bites.

Thanks! Good to know that I'm not completely wrong :-)
 

I suggest that first you start mapping your real world ideas to models. Don't worry if you don't get it right at first try thats why migrations do exist.

 
That's where the first problem starts. Like I said I'm not that much familiar with database stuff.

Also test driven development model could work nicely.

That doesn't tell me anything :-(
I know what test driven development is, but don't understand the context with this.

 

Most of the things you describe are clienside operations and Django being agnostic for that you're free to implement clientside as you wish.

You probably won't find much for similar project but there might be solutions to individual problems.

Sadly in that example (http://blog.e-shell.org/130) it's not clear what to put where. Maybe you can help me with that.

class Project(models.Model):
    name = models.CharField('Name of the project', max_length=100)
    code = models.CharField('Code number of the project', max_length=10)
    creator = models.ForeignKey(User, related_name='created_projects')
    maintainer = models.ManyToManyField(User, related_name='maintained_projects')

That's easy:  polls\models.py which starts with

from django.db import models
from django.contrib.auth.models import User

("User" because of creator and maintainer)

But polls\forms.py is change several times.

#from myproject.myapp.models import Project
from .models import Project 

class ProjectForm(forms.ModelForm):
    class Meta:
        model = Proyecto

Then

#from myproject.myapp.models import Project

from .models import Project
from django.contrib.auth.models import Group

class ProjectForm(forms.ModelForm):

    creator_choices = [(c.id, c.username) for c in Group.objects.get(name__icontains='creator').user_set.all()]
    maintainer_choices = [(m.id, m.username) for m in Group.objects.get(name__icontains='maintainer').user_set.all()]

    creator = forms.ChoiceField(required=True, label='Project creator', choices=creator_choices)
    maintainer = forms.MultipleChoiceField(required=True, label='Project maintainer(s)', choices=maintainer_choices)

    class Meta:
        model = Proyecto

 And then

#from myproject.myapp.forms import ProjectForm 

from .forms import ProjectForm
from django.contrib.auth.models import Group

creator_choices = [(c.id, c.username) for c in Group.objects.get(name__icontains='creator').user_set.all()]
maintainer_choices = [(m.id, m.username) for m in Group.objects.get(name__icontains='maintainer').user_set.all()]

creator = forms.ChoiceField(required=True, label='Project creator', choices=creator_choices)
maintainer = forms.MultipleChoiceField(required=True, label='Project maintainer(s)', choices=maintainer_choices)

myform = ProjectForm()

myform.fields['creator'].choices = creator_choices
myform.fields['maintainer'].choices = maintainer_choices

But here's "import ProjectForm" instead of import "Project" and "class Meta" is missing.

Can you tell me what I did wrong? python manage.py makemigrations always can't find something (project, ProjectForm, ...), no matter what I'm trying to change to resolve that error. I'm completely confused :-(
Thank you!

[softie...@gmail.com]

Hi!

Am Sonntag, 18. Juni 2017 10:23:26 UTC+2 schrieb softie...@gmail.com:

Yes, wrong position in the thread, but I hope to reach people looking not that deep in my thread.

Hi!

I think I found something. But it seems to be an very old example, couldn't find forms.py (and no word about where to create it) -> http://blog.e-shell.org/130
So if anybody here has an idea -> thank you!

PS: "dynamic choices" seem to be the keywords here.

Got the example running now (with things like

TITLE_CHOICES = (
    ('MR', 'Mr.'),
    ('MRS', 'Mrs.'),
    ('MS', 'Ms.'),
)

 instead of that User thing.

But it's still the question what my models should look like that
1. I can't replace that array(?, see above) with like a table from the database (created via models).
2. that the database relationships are the way it should be for that task.

Thank you for any help!

[Jani Tiainen]

Hi,

On 18 Jun 2017, at 14.47, softie...@gmail.com wrote:

Hi Jani!

Am Sonntag, 18. Juni 2017 11:05:27 UTC+2 schrieb Jani Tiainen:

Hi,

Seems that you've on right track. Just don't chew up too big bites.

Thanks! Good to know that I'm not completely wrong :-)
 

I suggest that first you start mapping your real world ideas to models. Don't worry if you don't get it right at first try thats why migrations do exist.

 
That's where the first problem starts. Like I said I'm not that much familiar with database stuff.

Well this has nothing actually to do with databases. ORM takes most of the troubles away. It helps though to learn a bit of SQL and how relational databases do work to understand if things go wrong.

Also test driven development model could work nicely.

That doesn't tell me anything :-(
I know what test driven development is, but don't understand the context with this.

 

Well at some point you have some application logic, or business logic that you need to test. Currently your Project model is simple and doesn’t involve any real logic.

Now here is a lot of code that just can’t work as is. If possible, please publish your work in GitHub for example. Makes easier to follow your project and progress.

Can you tell me what I did wrong? python manage.py makemigrations always can't find something (project, ProjectForm, ...), no matter what I'm trying to change to resolve that error. I'm completely confused :-(
Thank you!

I also suggest that you hop in to your magnificent IRC channel. You’ll get (almost) instant help 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...@googlegroups.com.

To post to this group, send email to django...@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/91a2c682-a360-49a5-80ad-d287da0e30e6%40googlegroups.com.