[python-nl] rest-toolkit release

[Wichert Akkerman]

> On 14 Jul 2014, at 13:32, Martijn Faassen <faassen at startifact.com> wrote:
> 
> Hoi,
> 
> 2014-07-14 12:32 GMT+02:00 Wichert Akkerman <wichert at wiggy.net>:
>>> Pyramid doet toch alleen traversal naar models met views erop? Routes
>>> gaan in Pyramid toch direct naar views? Voegt rest-toolkit dan niet
>>> routing naar models toe?
>> 
>> Pyramid, en repoze.bfg daarvoor, heeft altijd al twee publicatie modellen gehad: traversal zoals Zope dat
>> kent, en het meer bekende URL dispatch waarbij je grofweg een URL via een regexp matched met een route.
>> Een route heeft dan weer een context factory die je de context geeft, en bij de route of route+context kan je
>> dan views registeren. Je kan zelfs helemaal los gaan en ze combineren.
> 
> Het context verhaal heb ik wel eens gelezen. Het lijkt me dat dit toch
> ietwat anders is dan een view lookup op de context zoals bij
> traversal. Het is meer een manier om een view van een context te
> voorzien. Hoewel het registreren van een view op "route+context" dan
> weer wel daarop lijkt. Dat heb ik in de docs nog niet teruggevonden.

Dat werkt vrij exact zoals je zou verwachten:

@view_config(route_name=‘my-route’, context=MyModel)
def my_view(context, request):
    pass

> Echt routen naar models valt natuurlijk te bouwen in Pyramid -- het is
> een erg flexibel ding. Er staat dan een wel waarschuwingsteken in de
> handleiding bij het combineren van traversal en routing. :)

In de praktijk blijkt dat mensen traversal al moeilijk snappen, en de combinatie van dispatch+traversal al helemaal een brug te ver is. Vandaar dat de focus in de pyramid documentatie in verloop van tijd ook sterk van traversal naar dispatch is verandert.

> 
>> rest-toolkit bouwt op dat systeem voort, maar introduceert het dus niet zelf.
> 
> Pyramid heeft een filosofie van geen policy, dus dan is het handig als
> er een laagje komt wat het een en andere duidelijker maakt. Het
> "routing to models" valt veel meer op in rest-toolkit.
> 
>>> De meeste web frameworks denken dat een route naam met een manier om
>>> via de naam een link te genererenn goed genoeg is voor link generatie.
>>> Ik denk daar nogal anders over. Morepath associeert routes met model
>>> classes zodat om een link naar een model instance kan vragen.
>> 
>> Dat is wel anders, en heeft een redelijk belangrijk minpunt: je forceert een 1-op-1 mapping tussen models en
>> URLs, terwijl het niet ongebruikelijk is om hetzelfde model voor meerdere URLs te gebruiken.
> 
> Ja, da's een beperking. Maar ik denk meestal een goede: waarom laat je
> het model nu op meerdere plekken terugkomen als je gewoon een link kan
> maken? De voordelen zijn natuurlijk dat je zonder nadenken en opzoeken
> van een route naam kunt linken. Maar er zijn natuurlijk tradeoffs.

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
evenement gegevens tonen in een admin-context voor organisatoren versus een evenement tonen in een publieke kalender
een edit-scherm versus een view van hetzelfde object

In een hele pure REST-context gaat dat niet op omdat REST voorschrijft dat een resource uniek wordt geïdentificeerd door een URL. In de praktijk geeft dat echter veel duplicatie en wil je snel hetzelfde model op meerdere plekken gebruiken. Vandaar dat ik die harde koppeling tussen URL en model niet als een nuttig patroon zien.

> Maar je kunt in Morepath overigens ook dezelfde model class op
> meerdere plekken gebruiken, als het maar in een andere applicatie is
> (in dezelfde runtime).
> 
>> Ik zal nooit models rechtstreeks aan URLs linken omdat ik dat als een anti-pattern zie, maar het is natuurlijk
>> vrij makkelijk voor iemand om dat bovenop rest-toolkit te doen.
> 
> Het concrete patroon in rest toolkit lijkt op dat van Morepath.
> 
> Je hebt in rest-toolkit resources. Die hebben een pad via een route.
> Je hebt views die je aan resources hangt. 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. 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.

Bedankt voor die feedback trouwens; blijkbaar heeft de documentatie van SQLResource meer aandacht nodig.

> In Morepath doe je wat jij met resources doet met models. Die kunnen
> of uit een database komen, of ze kunnen applicatie-specifiek zijn
> (collecties meestal), dat kan Morepath niets schelen. De applicatie
> specifieke models kunnen dan weer queries doen, zoals jij doet in
> resources. Verschil is dat een model geen request heeft zoals
> resources - dat wordt altijd in een Morepath view afgehandeld, en
> models weten niks van het web. Ander verschil: het ophalen van models
> vanuit de route in Morepath gaat via een functie die een query kan
> doen of een applicatie-specifieke model instance kan maken, of wat dan
> ook.

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.

Gr,
Wichert.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-nl/attachments/20140715/26b945c9/attachment-0001.html>