Am 29.07.2010, 10:25 Uhr, schrieb Free Ekanayaka <free.ekanay...@gmail.com>:
> I agree that model objects and forms are not generally tight together, > even though I'd argue that virtually every web application will need > basic CRUD for the core entities. Form inference via schema adapter should be possible but I think there is consensus that interfaces that are schemas can cause more problems than they solve. Convenience versus overhead and confusion. > TH> I use a UML modeling tool to generate all my models and form > schemas so I > TH> tend not to write much code in these entities. > That's interesting, any pointer/link for this specific tool? > TH> I personally think the form schema is much more about the view than > the > TH> model. > Sure, however I believe the issue I was raising is orthogonal to this > one. Regardless how tight or loosely the form schema is bound to the > model, the authorization for a view in Repoze.bfg can effectively be > only True or False, which is simple and nice, but sometimes doesn't fit > what you need to do. In those cases you are free to add more to it such as, as Chris said, security proxies. Making this standard adds a lot of overhead to cases where it is totally irrelevant. NB. BFG's openness with regard to storage means you have to think about non-ZODB environments if you wish to have object-level security. > Let's make an example. You have a web application for sharing drawings, > you can upload drawings and for each drawing decide which other users > you want to share that drawing with. If you share a drawing with another > person, that other person can perform the same operations as you on it, > like tagging it or removing it. > Now let's say that you have views that act on collections of drawings, > like you could have a view for handling an HTTP request for tagging a > certain group of drawings or deleting them. The HTTP request for those > views would typically have a parameter holding a list for drawing IDs to > act on. How do you define the permission on those views? With a > model-based permissions system, you would simply make the view public > and let the model raise Unauthorized if you attempt to do something on a > drawing you don't have access too. However with a view-based permission > system you need to use some other pattern, and I'm not sure what would > be best. I would think you would need to add something to your application to handle this (something akin to workflow) but I don't see why you can't stick with security. BFG provides all the necessary hooks for fine-grained security. Regarding Maartijn's discussion of configuration close to the objects. Having grown up with Zope 2 I'm not keen to see declareProtected(), etc. return for this even if you have decorators. Much better, in my view, to have adapters and views implement behaviour and secure these. I guess the only thing that's missing is security aware form generation, ie. the ability to lock down parts of the form. With a form generation library such as deform this can be done at the view level, although it's not ideal. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
