[Checkins] SVN: traject/trunk/ Move these out of the main document.
Martijn Faassen
faassen at startifact.com
Mon Oct 26 12:04:39 EDT 2009
Log message for revision 105302:
Move these out of the main document.
Changed:
U traject/trunk/src/traject/traject.txt
A traject/trunk/thoughts.txt
-=-
Modified: traject/trunk/src/traject/traject.txt
===================================================================
--- traject/trunk/src/traject/traject.txt 2009-10-26 15:10:47 UTC (rev 105301)
+++ traject/trunk/src/traject/traject.txt 2009-10-26 16:04:38 UTC (rev 105302)
@@ -376,109 +376,3 @@
u'departments'
>>> p3.__parent__ is root
True
-
-Problems:
-
-* how do we turn this into traversal? The classes of the objects
- traversed to need to have traversers registered for them just in
- time? Alternatively write a traversal mechanic that delivers the
- object while eating as much of the path as possible, taking the last
- bit as the view?
-
-* how do we know traversing ends? actually each step of the traversal
- returns a model. The traverser registered for each model checks for
- the view itself.
-
-* when the route traverser is in place, it will determine traversal
- based on what is traversed already and the next step in the
- traversal. This means that this traversal can be universal for the
- entire route traversing process. Each route traversing object can be
- provided with an interface that this traverser adapts to, during
- traversal. This can be done just in time.
-
-* URL parameters -> object: given parameters, return object inverse:
- object -> URL parameters: given object, give back URL parameters
- this allows us to reconstruct the parent trail, though there is a
- cost involved, and how do we make sure that every object has a
- __parent__ and __name__ when returned from session.query()?
-
-* MapperExtension with reconstruct_instance could set __parent__ and
- such.
-
-* how to handle collections/relations? If we have the default
- collection, how do we attach views? If so, can we safely put in
- __parent__ and friends? If so, when? Or do we require the web app to
- return a proxy-like object that does have views?
-
-* collection.on_link can be used to set parent.
-
-* is it possible to transparently install other collection proxies into
- the mapper or something?
-
-* the performance of doing a resolve for each query result isn't very high,
- better do something that smartly detects a __parent__ on its parent and
- bails out early if so.
-
-* we could install a special function locatedquery which is a wrapped
- session.query that retrieves objects from the database that are
- wrapped. It could take care of relation objects too (and so could
- traversal), but what about the objects in relations and such? And so on?
- We don't want to thrawl through everythign to wrap 'm.
- Nicer would be a mapper extension that puts this in automatically,
- but that might be tricky to implement...
-
-* we need a lot of tests for failures: wrong parameters, what if the
- query raises an exception, what if the argument reconstruction
- returns the wrong parameters, what if the query returns None, etc.
-
-* We need to figure out whether we can hijack traversal in some
- structured way to allow multi-step traversal, or smoothly extend
- resolve so it can work with the traversal process? using the
- traversal stack mechanism on the request, perhaps?
-
-* reconstruct: build the object *without* parents, then see whether
- it already *has* parents, and if so, be done. Otherwise, construct
- parent, walking up path. Finally, connect to root.
-
-* factory function now receives parent. That's fine for resolving
- routes, but when trying to efficiently reconstruct a parent chain
- it's in the way: we'd need a parent in order to reconstruct a
- parent!
-
-* can a factory return None? What happens?
-
-* can an inverse return None? what happens?
-
-class EmployeePattern(traject.Traject):
- grok.context(AppRoot)
- traject.pattern('departments/:department_id/employees/:employee_id')
- traject.model(model.Employee)
-
- def factory(department_id, employee_id):
- return session.query(model.Employee).first()
-
- def arguments(employee):
- return dict(department_id=employee.department.id,
- employee_id=employee.id)
-
-
- at traject.pattern(AppRoot, 'departments/:department_id/employees/:employee_id')
-def factory(department_id, employee_id):
- ...
-
- at traject.inverse(AppRoot, model.Employee, 'departments/:department_id..')
-def arguments(employee):
- ...
-
-
-
-class ModelRoute(megrok.traject.Traject):
- grok.context(Model)
- traject.pattern('foo/:bar/clusters/:baz')
-
- def factory(bar, baz):
- return session.query(...).first()
-
- def arguments(obj):
- return {'bar': obj.zorgverzekeraar.id, 'baz': obj.id}
-
Added: traject/trunk/thoughts.txt
===================================================================
--- traject/trunk/thoughts.txt (rev 0)
+++ traject/trunk/thoughts.txt 2009-10-26 16:04:38 UTC (rev 105302)
@@ -0,0 +1,105 @@
+Problems:
+
+* how do we turn this into traversal? The classes of the objects
+ traversed to need to have traversers registered for them just in
+ time? Alternatively write a traversal mechanic that delivers the
+ object while eating as much of the path as possible, taking the last
+ bit as the view?
+
+* how do we know traversing ends? actually each step of the traversal
+ returns a model. The traverser registered for each model checks for
+ the view itself.
+
+* when the route traverser is in place, it will determine traversal
+ based on what is traversed already and the next step in the
+ traversal. This means that this traversal can be universal for the
+ entire route traversing process. Each route traversing object can be
+ provided with an interface that this traverser adapts to, during
+ traversal. This can be done just in time.
+
+* URL parameters -> object: given parameters, return object inverse:
+ object -> URL parameters: given object, give back URL parameters
+ this allows us to reconstruct the parent trail, though there is a
+ cost involved, and how do we make sure that every object has a
+ __parent__ and __name__ when returned from session.query()?
+
+* MapperExtension with reconstruct_instance could set __parent__ and
+ such.
+
+* how to handle collections/relations? If we have the default
+ collection, how do we attach views? If so, can we safely put in
+ __parent__ and friends? If so, when? Or do we require the web app to
+ return a proxy-like object that does have views?
+
+* collection.on_link can be used to set parent.
+
+* is it possible to transparently install other collection proxies into
+ the mapper or something?
+
+* the performance of doing a resolve for each query result isn't very high,
+ better do something that smartly detects a __parent__ on its parent and
+ bails out early if so.
+
+* we could install a special function locatedquery which is a wrapped
+ session.query that retrieves objects from the database that are
+ wrapped. It could take care of relation objects too (and so could
+ traversal), but what about the objects in relations and such? And so on?
+ We don't want to thrawl through everythign to wrap 'm.
+ Nicer would be a mapper extension that puts this in automatically,
+ but that might be tricky to implement...
+
+* we need a lot of tests for failures: wrong parameters, what if the
+ query raises an exception, what if the argument reconstruction
+ returns the wrong parameters, what if the query returns None, etc.
+
+* We need to figure out whether we can hijack traversal in some
+ structured way to allow multi-step traversal, or smoothly extend
+ resolve so it can work with the traversal process? using the
+ traversal stack mechanism on the request, perhaps?
+
+* reconstruct: build the object *without* parents, then see whether
+ it already *has* parents, and if so, be done. Otherwise, construct
+ parent, walking up path. Finally, connect to root.
+
+* factory function now receives parent. That's fine for resolving
+ routes, but when trying to efficiently reconstruct a parent chain
+ it's in the way: we'd need a parent in order to reconstruct a
+ parent!
+
+* can a factory return None? What happens?
+
+* can an inverse return None? what happens?
+
+class EmployeePattern(traject.Traject):
+ grok.context(AppRoot)
+ traject.pattern('departments/:department_id/employees/:employee_id')
+ traject.model(model.Employee)
+
+ def factory(department_id, employee_id):
+ return session.query(model.Employee).first()
+
+ def arguments(employee):
+ return dict(department_id=employee.department.id,
+ employee_id=employee.id)
+
+
+ at traject.pattern(AppRoot, 'departments/:department_id/employees/:employee_id')
+def factory(department_id, employee_id):
+ ...
+
+ at traject.inverse(AppRoot, model.Employee, 'departments/:department_id..')
+def arguments(employee):
+ ...
+
+
+
+class ModelRoute(megrok.traject.Traject):
+ grok.context(Model)
+ traject.pattern('foo/:bar/clusters/:baz')
+
+ def factory(bar, baz):
+ return session.query(...).first()
+
+ def arguments(obj):
+ return {'bar': obj.zorgverzekeraar.id, 'baz': obj.id}
+
More information about the checkins
mailing list