Hi Tim,

|--==> On Thu, 29 Jul 2010 07:36:57 +0800, Tim Hoffman <zutes...@gmail.com> 

  TH> Hi
  >>2) With the security proxy machinery I can have a view that
  >>conditionally displays certain HTML elements (like form fields)
  >>depending on the permissions that the accessing user has on the context
  TH> I too came to bfg from zope2 and zope 3 and was used to model based
  TH> security,
  TH> however the complete disconnection of forms from models in bfg is just
  TH> fantastic ;-)

Yeah, I'm fascinated by that as well, and I'm trying to understand how
it could fit the requirements I need to meet.

  TH> I always found that whilst forms tied to the model was nice for simple
  TH> things (ala basic crud) the minute
  TH> you had complex forms (aggregate forms, forms with no model etc) that the
  TH> tight binding of model and form was
  TH> a big pain.  Separating form from model has been a real godsend for some 
  TH> my latest projects.

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.

  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.

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.


Repoze-dev mailing list

Reply via email to