[Zope-dev] Testing Zope applications

[Jim Fulton]

Toby Dickenson wrote:
> 
(snip)
> >I'm not sure exactly what problem you are refering to. It sound's
> >like an issue of depending on a specific acquired name and having
> >the name overridden with something bogus. Is that it?
> 
> There are two related issues that conspire to make the problem hard:
> 
> A. What you descibe above, that looks like it will be fixed in part
>    by NO_SUBOBJECTS_OVERRIDE (which looks great). The outstanding
>    issue is what happens when a new version of a product wants to
>    add a new NO_SUBOBJECTS_OVERRIDE name (when objects of that
>    name may already exist in old subobjects).

I think that there should be some discussion of this design
pattern. Specifically, I'm not sure I like the idea of an application
that depends on fixed names in a hierarchy. In fact, I know I
don't. :)  I think it would be a good to have a discussion of
this pattern. In particular, I'd like to see:

  - Problems it solves

  - Alternative approaches

*I* would like to see this discussion happen in a Wiki,
but I won't insist. :)  FWIW, it will be much more likely
for me to make comments in a wiki, especially if someone
sends me the wiki link when they are ready for comments.
 
>    In many cases these to-be-protected names are part of a
>    product's API.
>    http://dev.zope.org/Wikis/DevSite/Proposals/APINamingConvention
>    suggests a naming convention for new API attributes. I suggested
>    in the discussion Wiki that it should not be possible to create
>    subobjects with an id of the form reserved for API attributes -
>    but it seems to have got lost in the Wiki noise :-(

I thought, until a couple of days ago, that this proposal had been rejected.
I found out recently that it hadn't. I'll look at your comments when
I move the proposal forward.

<aside>
On Wikis, while they need improvement (see
http://dev.zope.org/Wikis/DevSite/Proposals/WikiNG)
I personally find them far less noisy than mail
lists. Hopefully, we'll make the wiki's provide
the best of both worlds soon.
</aside>


 
> >  2. There will be a new interface in Zope 2.3 that will allow
> >     you to prevent a name from being used lower in a containement
> >     hierarchy. This change is documented at:
> >     http://dev.zope.org/Wikis/DevSite/Proposals/ReplaceableProperty.
> >     The work has already been done and checked into CVS. I've asked Shane,
> >     the author, to update the interfaces wiki to capture this change.
> 
> B. A common mistake in DTML authoring is to look up a name in the
>    DTML namespace when the context expected to contain the name is
>    not at the top of the namespace stack. The bug goes undetected
>    if the context at the top of the stack does not contain that
>    name.

But if the name isn't found in the inner (aka top ;) namespace,
then the search should proceed further in.
 
>    I have found that this happens too frequently even for
>    skilled authors, and is rarely detected in review. In summary:
>    one namespace isnt enough.
> 
>    I suspect that this is the problem percieved by Andrew Kuchling
>    (who started this thread back on zope-zeo). Our solution
>    to this (successful so far) has been to replace DTML in any use
>    other than Document Templates.

I think that there is broad agreement that DTML should be
uses soley for templates and shouldn't contain complex logic.
 
>    (For me, the greatest horror is the name 'DTML Method'. The name
>    'method' implies a tight coupling to the instance that it is a
>    method of, however it is possible for a DTML Method to execute in
>    a context where all of it's instances attributes are masked by
>    those of other objects. Urgh)

This is a great point. The intent was that DTML Methods would be bound
most tightly to the instances they were accessed in, but this is not what's
done.
 
Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.