[Django] Afweging opzet webapp

[Shinji]

Ik zit al een tijdje tegen een probleem aan te hikken waar ik graag wat advies voor wil.

Ik wil een site maken (met behulp van Django) maar zit me af te vragen wat de handigste constructie is. De site is een intranet pagina waarin bepaalde gegevens bijgehouden kunnen worden. Per klant gaat dit om dezelfde gegevens.

Ik heb nu een pagina gebouwd die op basis van de klanten die in de database staan het menu maakt. Alleen weet ik even niet hoe verder. Is het verstandig om van elke klant een aparte 'app' te maken? (Maakt het lastiger voor beheer als ik er niet ben). Of kan ik hier mee uit de voeten met 1 app.

De richting waar ik nu op aan het denken ben is:
Site
- Klant1
Gegevens1 (url: site/klant1/gegevens1)
Gegevens2 (url: site/klant1/gegevens2)
- Klant2
Gegevens1 (url: site/klant2/gegevens1)
Gegevens2 (url: site/klant2/gegevens2)

De gegevens van de verschillende klanten moet volledig gescheiden zijn als in, mag best in zelfde database staan maar als je op een pagina van één klant zit mag je ook alleen gegevens zien van die klant.

Het probleem waar ik tegen aanloop is dat volgens mij zoals Django opgebouwd is hij de klanten als verschillende apps ziet, maar omdat het exact dezelfde gegevenstypen zijn leek mij dit dus weer niet handig.

Ik ben nog vrij nieuw met Django dus wellicht zie ik ook wat over het hoofd, ik heb geprobeerd zo duidelijk mogelijk moet zijn maar kan me voorstellen dat het toch nog een beetje wazig is. Mocht dit voor jou zo zijn, hopelijk kan ik dan met wat concrete vragen het proberen duidelijker te maken.

Ik kwam deze tegen: http://stackoverflow.com/...ir-own-database-in-django maar daar gaat het echt om gescheiden databases en dat hoeft van mij niet per sé. De gegevens zijn onderling aan een bepaalde klant gekoppeld door de relaties dus daarmee zou de scheiding prima aan te brengen zijn.

[BasilFX]

Als ik het dus goed begrijp heb je dus één database-layout die voor beide klanten hetzelfde is.

Ik zou aan elk model in de database een veld toevoegen genaamd klant_id. Vervolgens parse ik de URLs zo dat het klant_id uit de URL gehaald wordt, en deze meenemen in de queries. In zo'n geval kun je uit de voeten met één enkele app (een app hoeft niet persé een URL prefix te hebben, wellicht dat dit voor enige verwarring zorgt).

Je zou dit kunnen vergemakkelijken door middel van een middleware. Zie het als een stukje code dat voor je daadwerkelijke request uitgevoerd wordt. Hieronder een eenvoudig voorbeeld (let op: dit zal in de gehele URL naar /klant1 zoeken!):

Python:

class CustomerMiddleware(object):
    def process_request(self, request):
        if '/klant1' in request.path:
            request.klant_id = 1
        elif '/klant2' in request.path:
            request.klant_id = 2

Vanaf nu zal in de view function de variable klant_id op het request-object bestaan:

Python:

def my_view(request):
    my_models = MyModel.objects.filter(klant_id=request.klant_id)

    return render(request, "template.html", locals())

[Kalua]

je kan ook iets als django-guardian gebruiken, dan kan je per object permissies aanhangen. Dan zou het nooit door elkaar kunnen lopen.

[Shinji]

Bedankt voor de input, zit het even door te kijken, als ik het goed begrijp doet die middleware het geheel scheiden op basis van de URL. Geeft dit dan geen problemen voor mijn menu? Ik heb nu boven een nav bar met voor elke klant een drop down menu met daarin dezelfde opties. Deze worden uit het model Customer gehaald. Dit model is dan als het ware overkoepelend en zou niet onder de middleware moeten vallen.

[Guillome]

Dan zou ik niet kiezen voor /klant-1 maar voor een niet-te-raden hash per gebruiker.

Anders kan ik gewoon hacken en andere gegevens opvragen

[Shinji]

Guillome schreef op dinsdag 05 april 2016 @ 12:03:
Dan zou ik niet kiezen voor /klant-1 maar voor een niet-te-raden hash per gebruiker.

Anders kan ik gewoon hacken en andere gegevens opvragen

Het gaat nergens om security, maar puur om duidelijkheid. Je bent bezig voor klant X en ziet dus alleen gegevens van klant X en niet ook van Y. Tenzij je in je menu naar klant Y gaat.

Gebruikers kunnen dus gewoon bij alle klanten, alleen om overzicht te bewaren worden gegevens per klant gescheiden.

[Guillome]

Ok duidelijk

[Shinji]

Inmiddels stuk verder, stukje middelware werkt nu. Als ik request.customerId weergeef dan wijzigd dit als de URL veranderd, dus wat dat betreft ben ik eigenlijk klaar.

Enige is dat nu mijn data niet meer geladen wordt maar daar gaan we nog wel even over zitten puzzelen.

Uiteindelijk is de middleware onderstaand geworden:

Python:

from webapp.models import Customer

class CustomerMiddleware(object):
    def process_request(self, request):
        allCustomers = Customer.objects.all()
        for c in allCustomers:
            if '/' + c.customerName in request.path:
                request.customerId = c.id

Zal nog wel wat foutafhandeling toe moeten voegen voor als er random iets ingevuld wordt etc.

[EngineerCoding]

Ik raad je af om deze middleware te gebruiken, want het kan veel en veel makkelijker

Hiervoor gebruik je de urls.py, waarbij je in je url eigenlijk deze customer in meegeeft.
Een voorbeeld hiervan is te vinden in de django tutorial. Hier doen ze het voor met publicaties op datum, dit kan je ook zien als een id voor een klant.

Ik raad je aan om die gehele django tutorial door te lopen, het is zeer handig en bouwt wat mij betreft een zeer goede basis. Vergeet niet: oefening baart kunst

[Pizzalucht]

Shinji schreef op dinsdag 05 april 2016 @ 16:43:
Inmiddels stuk verder, stukje middelware werkt nu. Als ik request.customerId weergeef dan wijzigd dit als de URL veranderd, dus wat dat betreft ben ik eigenlijk klaar.

Enige is dat nu mijn data niet meer geladen wordt maar daar gaan we nog wel even over zitten puzzelen.

Uiteindelijk is de middleware onderstaand geworden:

Python:

from webapp.models import Customer

class CustomerMiddleware(object):
    def process_request(self, request):
        allCustomers = Customer.objects.all()
        for c in allCustomers:
            if '/' + c.customerName in request.path:
                request.customerId = c.id

Zal nog wel wat foutafhandeling toe moeten voegen voor als er random iets ingevuld wordt etc.

Zou je niet direct kunnen zoeken op de customerName? Nu moet je bij elke request door alle customers heen.

[Shinji]

EngineerCoding schreef op maandag 11 april 2016 @ 23:03:
Ik raad je af om deze middleware te gebruiken, want het kan veel en veel makkelijker

Hiervoor gebruik je de urls.py, waarbij je in je url eigenlijk deze customer in meegeeft.
Een voorbeeld hiervan is te vinden in de django tutorial. Hier doen ze het voor met publicaties op datum, dit kan je ook zien als een id voor een klant.

Ik raad je aan om die gehele django tutorial door te lopen, het is zeer handig en bouwt wat mij betreft een zeer goede basis. Vergeet niet: oefening baart kunst

Ik had de tutorials gedaan van https://pythonprogramming.net/

Heb het nog even doorgekeken en zonder middleware is het ook mogelijk inderdaad. Heb nu met behulp van je link middels de urls.py opgelost, zoiets als onderstaand:

Python:

url(r'(?P<req_customerName>[a-zA-Z0-9_]+)/categories/$', views.categories, name='Categories')

Python:

def categories(request, req_customerName):

[ Voor 4% gewijzigd door Shinji op 19-04-2016 14:34 ]