Comments (12)
True, I use context factories a lot, I now that switching the flow based on context is powerful, in practice for some of views that I use in production when we have url like:
report/5
we fetch a Report object that in turn is related to a Resource object that users have permissions to, so I do something like in my context factory:
def __init__(request):
self.report = fetch_report()
self.resource = report.resource
self.__acl__ = resource.acls_for_user(request.user)
I wasn't sure how to showcase this in a nice way and not confuse users as to what the context can be used for.
from pyramid_blogr.
On Dec 1, 2015, at 9:18 AM, Marcin Lulek [email protected] wrote:
I wasn't sure how to showcase this in a nice way and not confuse users as to what the context can be used for.
As background, I was bringing this up with Michael and Steve. I did a 6h screencast series on Pyramid for O’Reilly, and wound up really emphasizing (step by step) route factories. I think I can propose a series of changes that makes “context” sound like something both easier and more powerful.
But it would mean a big refactoring of pyramid_blogr. For example, the model/service duality would be collapsed into just a model (with class methods for the unbound stuff.) The view functions would shrink down into general nothingness. :)
This might be more change than you’re up for, so we might apply this treatment elsewhere.
—Paul
from pyramid_blogr.
Actually it was like this in past and the general consensus on the IRC channel was to introduce service approach and decouple everything from models.
For big and complex applications you also have services that use multiple model objects for queries - it also helps you to avoid dependancy hell in that case - after introducting services in my opinion it was much easier to organize model code and queries when queries got separated from ORM models.
from pyramid_blogr.
Well, you still could return models.services.blog_record.BlogRecordService as the context for a route factory. But if you are comfortable with your approach, we should leave it as-is.
from pyramid_blogr.
Maybe I'm misundestanding the idea here but that would mean you would have to fetch same object from db more than once per request I think, once in factory and once inside the view?
from pyramid_blogr.
Nope, the route factory would do the fetch and then pass into the view as "context".
from pyramid_blogr.
hmm... but you stated that it could pass the BlogRecordService - not the actual BlogRecord? Maybe you meant the ORM object :)
from pyramid_blogr.
Ah, sorry, I might be misunderstanding your misunderstanding. :) Can you explain "you would have to fetch same object from db more than once per request I think, once in factory and once inside the view"?
from pyramid_blogr.
Well, you still could return models.services.blog_record.BlogRecordService as the context...
I think you meant that we should return BlogRecord. And that would work well indeed.
url: /objectDType/55
It's just that in my experience you fetch object D that belongs to A(because user has permissions set on A) and you have to go via objects B and C to get there, and I like to return ALL of them at once as view context to avoid reasking the db for them again - because often views operate on multiple objects.
But what you suggest works in many cases, I just like the idea of showing people that context object can be a container of "anything" :-)
from pyramid_blogr.
On Dec 1, 2015, at 3:18 PM, Marcin Lulek [email protected] wrote:
Well, you still could return models.services.blog_record.BlogRecordService as the context...
I think you meant that we should return BlogRecord. And that would work well indeed.url: /objectDType/55
It's just that in my experience you fetch object D that belongs to A(because user has permissions set on A) and you have to go via objects B and C to get there, and I like to return ALL of them at once as view context to avoid reasking the db for them again - because often views operate on multiple objects.Hmm, it sounds like you are describing a resource tree and hierarchical security. I was intentionally leaving out that discussion and focusing on the case most non-Pyramid people think about…getting the resource for a route.
In your description above, is 55 related to C->B->A in a consistent way, or are these ACL hierarchies all ad-hoc?
Actually, let’s drop this conversation. I think you’d like pyramid_blogr to continue doing object lookups in views, and it’s your package, so you win. :)
—Paul
from pyramid_blogr.
That depends, about 80% of time single ORM object is the context of factory in my code - like you suggest, however it makes sense to point out that context and acl is very flexible may return different results based on time of day or whatever other condition condition is met, this is a very interesting use case - to close some urls on weekend for example.
I very often use reource-less permissions like "access_admin_panel" that will not have ORM object as context.
It is perfectly valid to provide an example of object returned by factory, but it would make sense to introduce a new step that would showcase that to show people multiple approaches to the problem. I'm all open for a use case for this - maybe... user settings/profile updates? That could return user object as context - would that work?
from pyramid_blogr.
Will reopen if needed.
from pyramid_blogr.
Related Issues (15)
- AttributeError: add_request_method HOT 4
- provide a better example of models package that includes a meta.py and imports objects into the root
- Old value in intro.rst?
- Project management to become more like Pyramid HOT 6
- Does not work with Python 3 HOT 3
- Add a step for tests toward the end of the tutorial
- Suggestion: authentication form. HOT 3
- forms.py not in views directory? HOT 5
- Consider re-organizing by component? HOT 2
- Yes,it should work HOT 2
- Suggestion: Adding remove posts functionality HOT 10
- not able to edit the blog entires HOT 10
- unable to host in production with Nginx HOT 1
- Installation, setup, and `$VENV` path are in conflict
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pyramid_blogr.