[python-nl] rest-toolkit release

[Martijn Faassen]

Hoi,

2014-07-15 10:28 GMT+02:00 Wichert Akkerman <wichert at 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