Hoi, 2014-07-15 10:28 GMT+02:00 Wichert Akkerman <wich...@wiggy.net>: >> Omdat je vaak heel verschillende dingen met hetzelfde model wil doen. >> Bijvoorbeeld: > > een account object als context gebruiken voor een instellingen-formulier en > een profiel-pagina
Als je echt verschillend gebruik hebt kun je een applicatie-specifiek model maken dat de database account wrapped voor tenminste een van de gevallen - dan krijg je iets wat op jouw resources lijkt, met als het verschil dat het een model is, dus zonder kennis van de request en alleen het applicatie domein. Maar voor simpele gevallen volstaan een aantal views op het account object. In een rich client side applicatie zou ik eerder zoiets verwachten dan "instellingen" en "profiel" op hele andere server side URLs plaatsen (zoals je zelf ook zegt over een hele pure REST context). En dan kun je in Morepath nog twee applicaties maken; een instellingen app en een profile app, en daarin het account object een andere pad geven. > evenement gegevens tonen in een admin-context voor organisatoren versus een > evenement tonen in een publieke kalender Klinkt als twee applicaties. > een edit-scherm versus een view van hetzelfde object Dat klinkt als twee views. > > Je kunt met SQLResource > > blijkbaar een SQLAlchemy object als context in de view gebruiken ipv > > de resource zelf, maar hoe dat precies gaat is me niet helemaal > > duidelijk. > > Niet direct. Er is een SQLResource die je als context aan een view hangt. > Die resource heeft een SQL query om iets uit SQL te halen, wat gebruikt > wordt als een attribuut in die resource. Als er niks word gevonden gooit de > SQLResource constructor een exception. Het SQLAlchemy object is daarmee dus > niet direct zelf de context. Hoe praat de view dan met het SQLAlchemy object? show_user krijgt een 'user' object waaruit het attributen haalt. Is een SQLResource die een soort proxy is voor het echte SQLAlchemy object? In Morepath, als er niks gevonden wordt, geeft de "get model" functie een None terug en krijg je een 404. > Dat zou je wel kunnen doen, maar dan moet je al > snel view-logica aan je model toevoegen en persoonlijk hou ik daar minder > van. Dat snap ik niet helemaal; waarom zou er view logica aan het model moeten worden toegevoegd? Collection models zijn een apart geval; ze zitten niet in de database, en je krijgt al snel een 'add' method en wat search en filtering faciliteiten om queries te doen. Maar dat zijn dan ook models die je zelf kunt schrijven, en ze krijgen geen request, dus ook geen view logica. > Bedankt voor die feedback trouwens; blijkbaar heeft de documentatie van > SQLResource meer aandacht nodig. Geen probleem. Het is voor mij ook interessant om de verschillende subtiel verschillende manieren om applicaties te organiseren naast elkaar te leggen. > Het lijkt vooral een kwestie van terminologie te zijn. Ik gebruik de term > model eigenlijk helemaal niet in rest-toolkit. Hij komt alleen voor in > stukken documentatie waar een SQL model wordt gebruikt. Ik gebruik verder de > term resource omdat die aansluit bij de REST, URL en Pyramid terminologie. > Waar ik de term resource gebruik lijkt morepath de term model te gebruiken. Ze vervullen soms dezelfde rol, maar er is een wezelijk verschil. Jouw resources krijgen de request. In Morepath gebeurt dat nooit - ze krijgen de informatie pas als deze uit de request is gehaald door de views of door routing. Oorspronkelijk heetten de *views* in Morepath "resource", goed dat ik dat heb veranderd. :) Groeten, Martijn _______________________________________________ Python-nl mailing list Python-nl@python.org https://mail.python.org/mailman/listinfo/python-nl
