Projectstructuur voor Google App Engine

| | | | | | | | | | | | | | | | | | | |

Ik startte meteen een applicatie in Google App Engine toen die uitkwam, om met de technologie te spelen en aan een huisdierproject te werken waar ik al lang over nadacht, maar waar ik nooit aan toekwam. Het resultaat is BowlSK. Naarmate het echter groeide en er functies werden toegevoegd, is het erg moeilijk geworden om dingen georganiseerd te houden - voornamelijk vanwege het feit dat dit mijn eerste python-project is, en ik wist er niets van totdat ik begon te werken.

Wat ik heb:

  • Hoofdniveau bevat:
    • alle .py-bestanden (wist niet hoe pakketten werkten)
    • alle .html-sjablonen voor pagina's op het hoofdniveau
  • Submappen:
    • aparte mappen voor css, afbeeldingen, js, enz.
    • mappen die .html-sjablonen bevatten voor URL's van het subdirecty-type

Voorbeeld:
http://www.bowlsk.com/ verwijst naar HomePage (standaardpakket), sjabloon op "index.html"
http://www.bowlsk.com/games/view-series.html?series=7130 kaarten naar ViewSeriesPage (alweer, standaardpakket), sjabloon op "games/view-series.html"

Het is smerig. Hoe kan ik herstructureren? Ik had 2 ideeën:

  • Hoofdmap met daarin: appdef, indexes, main.py?

    • Submap voor code. Moet dit mijn eerste pakket zijn?
    • Submap voor sjablonen. Maphiërarchie komt overeen met pakkethiërarchie
    • Individuele submappen voor css, afbeeldingen, js, enz.
  • Hoofdmap met appdef, indexen, hoofdmap .py?

    • Submap voor code + sjablonen. Op deze manier heb ik de klasse handler direct naast de sjabloon, omdat ik in deze fase veel functies aan het toevoegen ben, dus wijzigingen aan de ene betekenen wijzigingen aan de andere. Nogmaals, moet deze mapnaam het eerste pakket zijn naam voor mijn klassen? Ik wil dat de map "src" is, maar ik wil niet dat mijn klassen "src.WhateverPage" zijn

Is er een best practice? Met Django 1.0 in het verschiet, kan ik nu iets doen om mijn vermogen om ermee te integreren te verbeteren wanneer het de officiële GAE-templating-engine wordt? Ik zou gewoon beginnen met het proberen van deze dingen, en kijken wat lijkt beter, maar de refactoring-ondersteuning van pyDev lijkt de pakketverplaatsingen niet erg goed aan te kunnen, dus het zal waarschijnlijk een niet-triviale taak zijn om dit allemaal weer werkend te krijgen.