Re: Our story for re-using content types

On Fri, 07 Apr 2006 00:04:51 +0100, George Lee  
<[email protected]> wrote:
  Since hearing Alan R. say that one should always program defensively and
> redefine classes:
>
>   from Bluh import ClassA
>  def MyClassA(ClassA):
>       pass

Sigh. When Alan says ALWAYS ALWAYS he means, "I do it". The problem is  
just that Alan is really smart and knows how to leverage these patterns  
properly. As a general piece of advice, this is overkill and makes code  
harder to read, and as you discover, isn't quite as defensive as it first  
looks. My advice is - don't do this unless you have a really good reason  
to.

> ...this made me how to actually do this in practice. What happens to:
>   * all the installation code you use for ClassA

Well, exactly. You're not meant to refer to MyClassA at all. You're just  
meant to inherit from it and instantiate with it. It's purely there as a  
module alias before a module alias is ever needed. I think using  
sys.modules for this later is fine, because when your code breaks because  
ClassA changed, you'll have to make some change anyway. If that change is  
to add something to sys.modules or even a simple migration step if  
appropriate, that's not much different from changing the import and  
possibly adding some compatability into MyClassA. And then you avoid the  
up-front pain of doing this in the 95% of cases where it's not an issue.

If the external library is very volatile, you may want to do this.  
Actually, what you *should* do is write an adapter for it behind an  
interface you eiether trust or control, using Zope 3 technology. Then you  
get a lot of other benefits, including cleaner code, and you can swap out  
the adapter code if ClassA changes.

>   * how meta_type, portal_type, archetype_name of the classes work, how  
> they
> show up in add menus (both? by waht name?)

You don't. You don't use MyClassA as a portal type at all, you just use it  
as an insulation layer in your python code. The fact that you don't  
understand this isn't your fault, it's because this pattern is  
unnecessarily confusing unless you think carefully about how Python types  
and inheritance works. And it'll be just as confusing to someone reading  
your code. :-(O

>   * any other interactions between ClassA and other portal objects  
> (e.g., if it
> looks up info in a property sheet, or a vocabulary manager, etc.)

Same answer.

> How does all of this get managed in a clean way? Seems like a  
> combination of
> good standardized coding practices to allow redefining easily, plus some  
> changes
> in Archetypes.

No, no, no, no. :) No more hacking in Archetypes for insane use cases (and  
this doesn't need it anyway).

Look - if this is over your head, don't worry. Ignore Alan's advice on  
this one, you aren't going to need it. If it does make sense to you, then  
you're smart enough to figure it out for yourself when you need to do this  
and when it's unnecessary.

Martin

-- 
(muted)



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642