it ends up for our application there are a lot of rule based permissions(not every application needs this). and pyramids traversal/acl mechanism works great for this in keeping the rules for permissions separate from your view code. Without it, I would guess that 90% of every view would be asserting permissions under different conditions(repeated and prone to error), but instead with traversal we have a good separation of concerns in this area.
The reason I suggested that we move away from web2py at the time was because we were set on using appengine, and it was very aggravating for me(the only employed dev at the time) to try to do things the "appengine way" through an abstraction layer I didnt understand and it never seemed to be caught up with appengines monthly sdk releases.
We tried the django non-rel and again, you read the appengine docs(which are mostly awesome btw), they say "do it like this" and then you are diving into source code trying to figure out how to trick the abstraction layer into doing what appengines docs would suggest. I also found it annoying that so many supposedly reusable pieces I ended up having to fork and hack in order to get them to do what I wanted. So no value there either.
In the end, to me, the abstraction had no value. And we decided to accept appengine as our platform and use it as it was intended rather than use some layer that promises that if by remote chance we might want to switch to something else, we could(in theory).
Hopefully whoever reads this can understand, I am judging these frameworks based on the criteria of the application I was hired to build. I'm not saying they have no value, they just didn't have any value for us, and when you are trying to get a company off the ground and funded, you don't have the luxury of time or patience. Decisions had to be made quickly, and 24 months later, I'm pretty happy with those decisions. My decisions aren't necessarily the right ones for anyone else.
it ends up for our application there are a lot of rule based permissions(not every application needs this). and pyramids traversal/acl mechanism works great for this in keeping the rules for permissions separate from your view code. Without it, I would guess that 90% of every view would be asserting permissions under different conditions(repeated and prone to error), but instead with traversal we have a good separation of concerns in this area.
The reason I suggested that we move away from web2py at the time was because we were set on using appengine, and it was very aggravating for me(the only employed dev at the time) to try to do things the "appengine way" through an abstraction layer I didnt understand and it never seemed to be caught up with appengines monthly sdk releases.
We tried the django non-rel and again, you read the appengine docs(which are mostly awesome btw), they say "do it like this" and then you are diving into source code trying to figure out how to trick the abstraction layer into doing what appengines docs would suggest. I also found it annoying that so many supposedly reusable pieces I ended up having to fork and hack in order to get them to do what I wanted. So no value there either.
In the end, to me, the abstraction had no value. And we decided to accept appengine as our platform and use it as it was intended rather than use some layer that promises that if by remote chance we might want to switch to something else, we could(in theory).
Hopefully whoever reads this can understand, I am judging these frameworks based on the criteria of the application I was hired to build. I'm not saying they have no value, they just didn't have any value for us, and when you are trying to get a company off the ground and funded, you don't have the luxury of time or patience. Decisions had to be made quickly, and 24 months later, I'm pretty happy with those decisions. My decisions aren't necessarily the right ones for anyone else.