Hi,

For a product I'm developing, I'm adding Newsletter objects using a
centralized storage utility - similar to how plone.contentrules and
plone.app.contentrules store rules. Each newsletter object also stores
subareas (sections of a page), each of which stores different newsletter
portlets inside it ("article," "article," "good-bye") - but none of this
storage is with a regular container-object mechanism.

Because these aren't Archetypes objects, and because they are not stored
with a folderish mechanism (I was trying to avoid all that machinery) of
striaghtforward containment, I'm getting very confused about how to do
acquisition and permissions and security properly. I'm using plone.portlets
and plone.app.portlets as some reference, but I am wondering if there are
best practices for doing this. I've figured out how to return
obj.__of__(some_other_obj) when I need to add an acquisition parent and
context. Do I just declare security on methods in the same way I would for
Archetypes objects, with ClassSecurityInfo and initializing the class (I
don't see an of that in plone.app.portlets)? Also, does registering with
<browser:page> as opposed to <adapter> (on ISomeContextInterface,
IBrowserRequest) do any more magic in terms of security? Is there a way to
change security permissions on an object that would affect the objects it
"stores" but doesn't directly contain? Or should I just go ahead and use
container-contained mehanisms?

Also, what are the key differences between plone.* objects and plone.app.*
classes? Is the second set intended to be Zope2 implementations - with
acquisition (e.g., subclassing SimpleItem) and Zope2-ish storage mechanisms?

Martin, is there a reason you chose to have content rules store actions and
conditions in a persistent list instead of as subobjects proper? And how did
that affect managing security on those items?

Thanks; peace,
George
-- 
View this message in context: 
http://www.nabble.com/Security-and-Acquisition-on-Zope3-objects-tf4489115s20094.html#a12802479
Sent from the Product Developers mailing list archive at Nabble.com.


_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers

Reply via email to