[Zope3-dev] Back to Job editing

[Jim Fulton]

Jeffrey P Shell wrote:
> A fairly common Zope 2 idiot^Hm is for classes to define a catch-all 'edit'
> method to batch-update object attributes.  In the PythonProgrammerTutorial
> 'Contact' example, this idiom seems to persist:
> 
> class IContact(IContactInfo):
>     "Provides the ability to change contact information."
> 
>     def update(first, last, email, address, pc):
>         """Modifies contact data
>         
>         'None' values are ignored.
>         """
> 
> Which makes a degree of sense - it's easier to protect a single 'update'
> method than to allow direct attribute setting.  But, with Schema and Python
> 2.2+ Properties, is it still the right way? 

It's not the wrong way, but most people prefer other ways. ;)

When I first wrote the tutorial, you could *only* protect methods. This limitation
no longer exists. If I were writing the tutorial from scratch, I might
write it to use mutable attributes.

I could use an interface (with or without Schema fields) to describe
the attributes and make the security assetions easier to spell.

Properties have nothing to do with this unless you want validation to happen
as attributes are being set.

 > It feels more like something
> that would go on an Adapter / Edit View, since targets of web forms, RPC
> calls, etc..., have an easier time calling a single 'update' method that
> doesn't make as much sense on a fundamental business, er, content component
> except as a convenience function (and again - that convenience seems to
> exist more for security/web situations).

I don't agree. Either the content advertizes it's attributes as writable, or it
provides mutating functions. The update method from the example seems like a
reasonable mutator to me.  Note that the Contact update method is never called
directly in a web request. it is called by a view that is called by a web request.


> I'm bringing this up because the current JobBoardEx package doesn't allow
> editing of single Jobs, which I was trying to make a sortof third-party edit
> view for as a test/example of how to do such things in Zope 3.  Since
> there's no convenient 'update()' method for Job instances, and the untrusted
> code of my new JobEditView can't set attributes, it doesn't work.

All you need to do is to add security assertions to make the Job attributes writable.

> I'm not sure what the best practice is, or should be.

To some degree, it's a matter of taste, but many people seem to find direct
attribute access yummy these days.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org