Apology! (was: [Zope] Problems with DTML-IN patch!!!)

Dieter Maurer dieter@handshake.de, zope@zope.org
Mon, 5 Mar 2001 19:46:08 +0100 (CET)


John Morton writes:
 > On Fri, 2 Mar 2001 20:55:40 +0100 (CET) Dieter Maurer <dieter@handshake.de>
 >  wrote:
 > 
 > > Chris Withers writes:
 > >  > John Morton wrote:
 > >  > > 
 > >  > > It doesn't appear to be defined in DT_In.py in 2.2.5, but it is ment
 > ion in
 > >  > > it's doc string, and is available in the dtml-in namespace. I never 
 > got
 > >  > > around to tracking down where it was added in.
 > > "DT_InSV.py" (for DTML In Sequence Variables) defines it, if
 > > it is defined (when I recently looked through the sources, it has
 > > not been).
 > 
 > I can't find them in either DT_In.py or DT_InSV.py in 2.2.5, yet they do
 > actually work fine...
You are right!

"{next,previous}-sequence-start-number" and friends are still there.
Nobody made the stupidity to remove them.
Please (Brian) accept my apology for my quite rude accusation.
I was just not smart enough to understand the ingenious code in
"DT_In" and "DT_InSV".

Let's review the situation:

  "DT_In" only defines "next-sequence-start-index".
  But what is pushed onto the DTML namespace is in fact
  a "DT_InSV.sequence_variables" object.
  Its "__getitem__" is used to look up sequence variables.

  The "__getitme__" code is quite sophisticated:
  If the key is not defined, it splits it at the last
  '-' into prefix and suffix (in our case, suffix is "number").

  If the class "sequence_variables" has a method whose
  name is given by suffix (this is the case for "number"
  and many of its friends),
  then the corresponding "index" key is looked up and
  the method applied to it.
  This way, "next-sequence-start-number" and friends come
  into existence, without that one easily recognized how
  this happens.


Sorry for the false accusations!

Dieter