[Zope3-dev] Re: Zope3/src/zope/app/browser/skins/debug/exceptions.py:1.1

[Steve Alexander]

>>The suggestion:
>>	
>>   There's an exceptionformatter module that you might want to use:
>>
>>   from zope.exceptions.exceptionformatter import format_exception
>>   t, v, tb = sys.exc_info()
>>   try:
>>       self.traceback = ''.join(format_exception(t, v, tb, as_html=1))
>>   finally:
>>       tb = None
> 
> 
> Hmm, it doesn't feel right to me to have the view class do the
> "templating" bit in its __init__.  Perhaps it should just make
> that service available to the template?

I was discussing the issue of view classes doing work in __init__ with 
Jim just the other day. One problem is that some views get constructed, 
but never called. The browser menu code does this.

We agreed that the zcml views directive should include a zcml attribute 
to name a method of the class that gets called just before the template 
is rendered. This would be a good place to do rendering that the 
template requires, without having to include a dummy tal element to call 
  a method.

No-one has actually implemented this new zcml attribute yet.


>>The query:
>>
>>   I'm pretty sure that __used_for__ has been a single interface,
>>   not a tuple of interfaces. Was there a particular reason you used
>>   a tuple?
> 
> Nope.  I think I saw it that way someplace, but could be wrong.  I
> thought of it as syntactically similar to __implements__.

Good point. I guess this should be reevaluated when the new interfaces 
proposal is implemented.


>>   Classes in Zope 3 should usually be new-style classes rather
>>   than classic classes. This is usually done using
>>
>>     __metaclass__ = type
>>
>>   at the module level.
>>
>>   This is important for views, as the code that sets up views from zcml
>>   directives sometimes does some fancy things that only work properly
>>   with new-style classes.
> 
> 
> Cool.  I've seen that, but didn't know when / why to follow suit.

As a rule, whenever the module contains classes that don't derive from 
other classes.


> I hadn't considered that the module was doing anything testable, and was
> looking at the content of the other two skin directories when I built
> 'debug'.  Neither of '{rotterdam,zopetop}/standardmacros.py' has tests
> (but they don't do much interesting, either).

The rotterdam/standardmacros.py and zopetop/standardmacros.py should 
have a minimal unit test.

A typical scenario is:

   * Joe Developer corrects a typo in a comment in standardmacros.py

   * Unfortunately, his finger slips and he introduces a syntax error,
     or deletes a name from a variable, without realising it

   * Joe runs all the unit tests before checking in with no problems

   * Joe also starts up Zope, and it seems to work and render some
     basic pages in the browser

   * Joe checks in the broken code

Actually, because these classes are refered to in zcml, the 'functional' 
test of starting up Zope should catch any syntax errors. However, 
unplanned changes in variable names would still slip through.

Have I made a good enough case to persuade the zopetop/rotterdam 
maintainers to add a unit test? ;-)

If they're too busy just now, they let me know and I'll write the tests.


>>Do you mind if I alter your code to conform to this style?
>  
> Nope.  I see you made a start;  I'll normalize the whitespace, and add
> a minimal test.

Thanks.

--
Steve Alexander