Loading ...
Sorry, an error occurred while loading the content.

[Cheetahtemplate-discuss] searchList overriding settings?

Expand Messages
  • Jurie Horneman
    I have a base template which more or less does this: #settings python String = Yada yada #end settings $String Somewhere I call addToSearchList() to add the
    Message 1 of 10 , Nov 1, 2002
    • 0 Attachment
      I have a base template which more or less does this:

      #settings python
      String = "Yada yada"
      #end settings
      $String

      Somewhere I call addToSearchList() to add the settings to the search list.
      And then I have a derived template, which I fill with a search list
      containing "Something else" for the key 'String'.

      The result, however, is 'Yada yada', not 'Something else'. In other words,
      the settings from the base class override the values in the search list. Is
      there a way for me to reverse that behavior?

      In the users' guide it says:

      "The searchList can be used to override or supplement the variables in the
      template object's namespace without needing to create a subclass."

      and

      "Extra namespaces can be added to the end of the searchList at at any time
      using the .addToSearchList() method"

      Even though I've glossed over the details of my actual templates here, they
      do work in general and I did check if the placeholder names were OK, whether
      a key with the right value is in the search list, etc.

      Jurie.




      -------------------------------------------------------
      This sf.net email is sponsored by: See the NEW Palm
      Tungsten T handheld. Power & Color in a compact size!
      http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
      _______________________________________________
      Cheetahtemplate-discuss mailing list
      Cheetahtemplate-discuss@...
      https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
    • Tavis Rudd
      Hi Jurie, for various reasons the #settings directive has been axed. It s not available in Cheetah 0.9.15a1 and up. I suggest you use inheritance and
      Message 2 of 10 , Nov 1, 2002
      • 0 Attachment
        Hi Jurie,
        for various reasons the #settings directive has been axed. It's not available
        in Cheetah 0.9.15a1 and up. I suggest you use inheritance and containment to
        control the variables available in the searchList rather than using the
        addToSearchList() method.
        Cheers,
        Tavis

        On November 1, 2002 04:56 am, Jurie Horneman wrote:
        > I have a base template which more or less does this:
        >
        > #settings python
        > String = "Yada yada"
        > #end settings
        > $String
        >
        > Somewhere I call addToSearchList() to add the settings to the search list.
        > And then I have a derived template, which I fill with a search list
        > containing "Something else" for the key 'String'.
        >
        > The result, however, is 'Yada yada', not 'Something else'. In other words,
        > the settings from the base class override the values in the search list. Is
        > there a way for me to reverse that behavior?
        >
        > In the users' guide it says:
        >
        > "The searchList can be used to override or supplement the variables in the
        > template object's namespace without needing to create a subclass."
        >
        > and
        >
        > "Extra namespaces can be added to the end of the searchList at at any time
        > using the .addToSearchList() method"
        >
        > Even though I've glossed over the details of my actual templates here, they
        > do work in general and I did check if the placeholder names were OK,
        > whether a key with the right value is in the search list, etc.
        >
        > Jurie.



        -------------------------------------------------------
        This sf.net email is sponsored by: See the NEW Palm
        Tungsten T handheld. Power & Color in a compact size!
        http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
        _______________________________________________
        Cheetahtemplate-discuss mailing list
        Cheetahtemplate-discuss@...
        https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
      • Mike Orr
        ... As Tavis said, #settings has been removed because it causes too much confusion for too little benefit. Instead use #attr or #def. ... The searchList is
        Message 3 of 10 , Nov 1, 2002
        • 0 Attachment
          On Fri, Nov 01, 2002 at 01:56:01PM +0100, Jurie Horneman wrote:
          > I have a base template which more or less does this:
          >
          > #settings python
          > String = "Yada yada"
          > #end settings
          > $String

          As Tavis said, #settings has been removed because it causes too much
          confusion for too little benefit. Instead use #attr or #def.

          > The result, however, is 'Yada yada', not 'Something else'. In other words,
          > the settings from the base class override the values in the search list. Is
          > there a way for me to reverse that behavior?
          >
          > In the users' guide it says:
          >
          > "The searchList can be used to override or supplement the variables in the
          > template object's namespace without needing to create a subclass."
          >
          > and
          >
          > "Extra namespaces can be added to the end of the searchList at at any time
          > using the .addToSearchList() method"

          The searchList is evaluated from left to right. First are the objects
          you passed to the Template constructor. Then 'self'. Then anything you
          added via .addToSearchList(). So if there's a same-name variable in
          the template instance (created via #attr or #def) or an ancestor class,
          it overrides the variable in your .addToSearchList object. If *you*
          want to override a same-name variable in the template instance:

          1) Use .prependToSearchList() instead of .addToSearchList().

          2) Modify one of the objects you passed to the Template constructor,
          adding that variable.

          3) In Python code, assign a Template instance attribute:
          t.String = "Yada yada".

          --
          -Mike (Iron) Orr, iron@... (if mail problems: mso@...)
          http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol


          -------------------------------------------------------
          This sf.net email is sponsored by: See the NEW Palm
          Tungsten T handheld. Power & Color in a compact size!
          http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
          _______________________________________________
          Cheetahtemplate-discuss mailing list
          Cheetahtemplate-discuss@...
          https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
        • Jurie Horneman
          Mike, ... the same problem occurs. See below. ... I m basically using the SkeletonPage structure that comes with Cheetah, meaning I have a base template (like
          Message 4 of 10 , Nov 1, 2002
          • 0 Attachment
            Mike,

            > As Tavis said, #settings has been removed because it causes too much
            > confusion for too little benefit. Instead use #attr or #def.

            the same problem occurs. See below.

            > The searchList is evaluated from left to right. First are the objects
            > you passed to the Template constructor. Then 'self'. Then anything you
            > added via .addToSearchList(). So if there's a same-name variable in
            > the template instance (created via #attr or #def) or an ancestor class,
            > it overrides the variable in your .addToSearchList object. If *you*
            > want to override a same-name variable in the template instance:
            >
            > 1) Use .prependToSearchList() instead of .addToSearchList().
            >
            > 2) Modify one of the objects you passed to the Template constructor,
            > adding that variable.
            >
            > 3) In Python code, assign a Template instance attribute:
            > t.String = "Yada yada".

            I'm basically using the SkeletonPage structure that comes with Cheetah,
            meaning I have a base template (like _SkeletonPage) that has a function that
            defines a whole bunch of settings and adds them with .addToSearchList. So
            given that I want the base template search list to be evaluated after my
            own, addToSearchList would seem to be correct (and works fine in a slightly
            different program using the same structure).

            I also have settings in a derived page, which I have now changed to #attr.

            I've done some debugging and this is what the search list looks like over
            time when instantiating and filling my template:

            After Template.py, line 162:
            [ {}, my search list, the template object ]

            After the call to compiler.compile() in Template.py, line 241:
            (actually after the call to self.parse() in Compiler.py )
            [ {}, <Cheetah.Parser.GenTemplate instance at 0xblah>, the search list from
            my base class, maybe more I can't see in my IDE ]

            I didn't want to single-step through self.parse(). I did do some
            single-stepping through NameMapper.py. For some reason, compiler.compile()
            manipulates the search list, and after that the search list I passed in can
            no longer be found.

            I'm using version 0.9.14.

            Jurie.




            -------------------------------------------------------
            This sf.net email is sponsored by: See the NEW Palm
            Tungsten T handheld. Power & Color in a compact size!
            http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
            _______________________________________________
            Cheetahtemplate-discuss mailing list
            Cheetahtemplate-discuss@...
            https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
          • Mike Orr
            ... If you want the base template search list (which I assume means self ) to be evaluated after yours, use .prependToSearchList. Another possibility is, if
            Message 5 of 10 , Nov 1, 2002
            • 0 Attachment
              On Fri, Nov 01, 2002 at 10:03:28PM +0100, Jurie Horneman wrote:
              > > The searchList is evaluated from left to right. First are the objects
              > > you passed to the Template constructor. Then 'self'. Then anything you
              > > added via .addToSearchList(). So if there's a same-name variable in
              > > the template instance (created via #attr or #def) or an ancestor class,
              > > it overrides the variable in your .addToSearchList object. If *you*
              > > want to override a same-name variable in the template instance:
              > >
              > > 1) Use .prependToSearchList() instead of .addToSearchList().
              > >
              > > 2) Modify one of the objects you passed to the Template constructor,
              > > adding that variable.
              > >
              > > 3) In Python code, assign a Template instance attribute:
              > > t.String = "Yada yada".
              >
              > I'm basically using the SkeletonPage structure that comes with Cheetah,
              > meaning I have a base template (like _SkeletonPage) that has a function that
              > defines a whole bunch of settings and adds them with .addToSearchList. So
              > given that I want the base template search list to be evaluated after my
              > own, addToSearchList would seem to be correct (and works fine in a slightly
              > different program using the same structure).

              If you want the base template search list (which I assume means 'self')
              to be evaluated after yours, use .prependToSearchList.

              Another possibility is, if you really want to modify searchList
              variables from within the template, add an search object to the
              Template constructor, and put another reference to that object
              someplace where the template (or called method) can access it.
              Then that method can modify the object in place, and you won't
              need .add/prependToSearchList .

              All bets are off if you are using #settings.

              > I've done some debugging and this is what the search list looks like over
              > time when instantiating and filling my template:
              >
              > After Template.py, line 162:
              > [ {}, my search list, the template object ]

              The normal case. {} is the "#set global" dictionary.

              > After the call to compiler.compile() in Template.py, line 241:
              > (actually after the call to self.parse() in Compiler.py )
              > [ {}, <Cheetah.Parser.GenTemplate instance at 0xblah>, the search list from
              > my base class, maybe more I can't see in my IDE ]

              The GenTemplate instance is probably the template object in
              disguise. It changes name due to the class munging Cheetah does,
              according to rules I haven't been able to fathom. What does
              "the search list from my base class" mean? Sorry if I'm being
              dense, I just want to be sure I understand your situation. Was it
              the thing created by .addToSearchList(), or passed to the Template
              constructor, or ...?

              > I didn't want to single-step through self.parse(). I did do some
              > single-stepping through NameMapper.py. For some reason, compiler.compile()
              > manipulates the search list, and after that the search list I passed in can
              > no longer be found.

              > I'm using version 0.9.14.

              Ah, you're likely being hit by the "double init" bug. This was fixed in
              Cheetah 0.9.15a1. If you have a template that #extends another,
              __init__ ends up being called twice, and that has the effect of
              discarding your custom searchList and substituting the default.

              Upgrade to Cheetah 0.9.15a1 or CVS and see if it still happens.
              If you're afraid of disrupting existing production templates,
              install the new version into another directory and put it in
              your PYTHONPATH for testing. In particular, #settings won't work
              anymore.

              Not recommended, but you could modify the searchList directly; e.g.,
              $searchList()[1]['myVar']
              but this is unsupported, because you don't really know which subscript
              your object is unless you count carefully, and Cheetah reserves the
              right to modify the list at any time. I wouldn't
              presume to know that [1] is the object I expect it to be unless I first
              checked it via type(), isinstance() and/or "is".

              --
              -Mike (Iron) Orr, iron@... (if mail problems: mso@...)
              http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol


              -------------------------------------------------------
              This sf.net email is sponsored by: See the NEW Palm
              Tungsten T handheld. Power & Color in a compact size!
              http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
              _______________________________________________
              Cheetahtemplate-discuss mailing list
              Cheetahtemplate-discuss@...
              https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
            • Jurie Horneman
              ... I don t want that per se - SkeletonPage wants that. I assume it s a good idea and a good use of Cheetah. The template hierarchy is: _SkeletonPage - Python
              Message 6 of 10 , Nov 1, 2002
              • 0 Attachment
                > Another possibility is, if you really want to modify searchList
                > variables from within the template

                I don't want that per se - SkeletonPage wants that. I assume it's a good
                idea and a good use of Cheetah.

                The template hierarchy is:

                _SkeletonPage - Python base class that defines a lot of default settings
                SkeletonPage - template that defines some more settings
                MyBaseTemplate - my template that defines the look of my site. It defines
                some more settings, if that is the right terminology, using #attr (now)
                Content - my template that defines the actual content of the page

                When I fill Content, I pass a searchList that I want to override whatever
                default values might have been defined in base classes.

                > > After the call to compiler.compile() in Template.py, line 241:
                > > (actually after the call to self.parse() in Compiler.py )
                > > [ {}, <Cheetah.Parser.GenTemplate instance at 0xblah>, the search list
                from
                > > my base class, maybe more I can't see in my IDE ]
                >
                > The GenTemplate instance is probably the template object in
                > disguise. It changes name due to the class munging Cheetah does,
                > according to rules I haven't been able to fathom. What does
                > "the search list from my base class" mean? Sorry if I'm being
                > dense, I just want to be sure I understand your situation. Was it
                > the thing created by .addToSearchList(), or passed to the Template
                > constructor, or ...?

                No, I'm probably mixing a lot of terminology, not being familiar with
                Cheetah's innards.

                With "the search list from my base class" I mean what is passed as a
                parameter to .addToSearchList() in _SkeletonPage.__init__, line 39 of
                _SkeletonPage.py.

                > > I'm using version 0.9.14.
                >
                > Ah, you're likely being hit by the "double init" bug. This was fixed in
                > Cheetah 0.9.15a1. If you have a template that #extends another,
                > __init__ ends up being called twice, and that has the effect of
                > discarding your custom searchList and substituting the default.
                >
                > Upgrade to Cheetah 0.9.15a1 or CVS and see if it still happens.
                > If you're afraid of disrupting existing production templates,
                > install the new version into another directory and put it in
                > your PYTHONPATH for testing. In particular, #settings won't work
                > anymore.

                It does sound like a similar bug, and I'm surprised it hasn't hit me until
                now. I'll try that tomorrow and let you know.

                Thanks!

                Jurie.




                -------------------------------------------------------
                This sf.net email is sponsored by: See the NEW Palm
                Tungsten T handheld. Power & Color in a compact size!
                http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
                _______________________________________________
                Cheetahtemplate-discuss mailing list
                Cheetahtemplate-discuss@...
                https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
              • Mike Orr
                Apologies if I m getting Jurie s and Jamie s situations confused with each other.... ... SkeletonPage was rewritten not to use #settings. Hopefully the change
                Message 7 of 10 , Nov 1, 2002
                • 0 Attachment
                  Apologies if I'm getting Jurie's and Jamie's situations confused with
                  each other....

                  On Sat, Nov 02, 2002 at 12:10:22AM +0100, Jurie Horneman wrote:
                  > > Another possibility is, if you really want to modify searchList
                  > > variables from within the template
                  >
                  > I don't want that per se - SkeletonPage wants that. I assume it's a good
                  > idea and a good use of Cheetah.
                  >
                  > The template hierarchy is:
                  >
                  > _SkeletonPage - Python base class that defines a lot of default settings
                  > SkeletonPage - template that defines some more settings
                  > MyBaseTemplate - my template that defines the look of my site. It defines
                  > some more settings, if that is the right terminology, using #attr (now)
                  > Content - my template that defines the actual content of the page

                  SkeletonPage was rewritten not to use #settings. Hopefully the
                  change made it into Cheetah 0.9.15a1.

                  The most important purpose of SkeletonPage is as an example of
                  #block and #def. I think Edmund explained this adequately, but
                  just to augment it:

                  1) The parent template contains text and top-level
                  placeholders for the entire page, from <HTML> to </HTML>.
                  Replaceable sections are defined as #block. The most important
                  one conventionally is "#block content", containing dummy text.
                  It is convenient during testing to fill this template
                  standalone. In this case, you must provide default (dummy)
                  values for all placeholders, perhaps via #attr.

                  2) The child template contains #def's for every block that should
                  be overridden; e.g., "#def content".

                  3) Only one template in the inheritance chain contains ordinary
                  text and top-level placeholders. In the SkeletonPage scenario,
                  that template is the parent, and it must be the one that
                  implements respond. If it does not #extends anything, that will
                  happen automatically. If it does #extends something, you must
                  add "#implements respond".

                  4) All other templates in the inheritance chain (those that do
                  not contain the top-level text and placeholders) must not
                  implement respond. Since they #extends the parent, this happens
                  automatically.

                  Thus, in the SkeletonPage scenario, the main template is the
                  parent, and the child merely provides method overrides. It is
                  possible to turn this around and make the child the main
                  template (with top-level text), and the parent would merely
                  provide common methods. But in that case, you wouldn't use #block.

                  SkeletonPage provides some special methods to deal with style
                  sheets, etc. Use these if they're convenient, but I think most
                  people make their own skeleton page and omit that stuff.

                  We need a simpler example in the distribution of a block
                  structure that does not have all the extra stuff of SkeletonPage.
                  I'll make that a todo item.

                  --
                  -Mike (Iron) Orr, iron@... (if mail problems: mso@...)
                  http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol


                  -------------------------------------------------------
                  This sf.net email is sponsored by: See the NEW Palm
                  Tungsten T handheld. Power & Color in a compact size!
                  http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
                  _______________________________________________
                  Cheetahtemplate-discuss mailing list
                  Cheetahtemplate-discuss@...
                  https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                • Jurie Horneman
                  Well, I installed Cheetah 0.9.15a1. I adapted by base templates (very similar to SkeletonPage). I ran it. It worked. Then I noticed a small problem. I fixed
                  Message 8 of 10 , Nov 2, 2002
                  • 0 Attachment
                    Well, I installed Cheetah 0.9.15a1. I adapted by base templates (very
                    similar to SkeletonPage). I ran it. It worked. Then I noticed a small
                    problem. I fixed it. I ran it. It threw an exception. I changed it back. I
                    ran it. It still threw an exception. I've spent some time debugging, and I
                    just don't get it.

                    The exception is in:

                    File "D:\PYTHON22\Lib\site-packages\Cheetah\NameMapper.py", line 188, in
                    valueForKey
                    return obj[key]
                    AttributeError: MyPage instance has no attribute '__getitem__'

                    It tries to find a placeholder value in a base class of MyPage (the leaf
                    class containing the content). It goes into valueFromSearchList, iterates
                    over the elements of searchList, comes to the MyPage instance, goes into
                    _valueForName, tries to read obj[key] and boom. And it's right: MyPage
                    instance doesn't implement __getitem__.

                    I am totally flabberghasted.

                    Jurie.




                    -------------------------------------------------------
                    This sf.net email is sponsored by: See the NEW Palm
                    Tungsten T handheld. Power & Color in a compact size!
                    http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
                    _______________________________________________
                    Cheetahtemplate-discuss mailing list
                    Cheetahtemplate-discuss@...
                    https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                  • Jurie Horneman
                    OK, I pretty much solved my own problems by single-stepping and trial and error. The problem I described below: in template 1, I used a placeholder $thing,
                    Message 9 of 10 , Nov 2, 2002
                    • 0 Attachment
                      OK, I pretty much solved my own problems by single-stepping and trial and
                      error.

                      The problem I described below: in template 1, I used a placeholder $thing,
                      which I defined in a dictionary passed to the constructor of a derived
                      template. By adding #attr thing="" to the definition of template 1, the
                      problem went away.

                      A subsequent problem which took me a while to figure out was caused by a
                      method and an attribute having the same name, and Cheetah not calling the
                      one I expected.

                      Both of these were my own mistakes, but it took me a long time to figure out
                      where the problem was. Is there a better way to go about this? Are there
                      diagnostic functions in Cheetah that could have helped? Should there be?

                      Jurie.

                      ----- Original Message -----
                      From: "Jurie Horneman" <jhorneman@...>
                      To: <cheetahtemplate-discuss@...>
                      Sent: Saturday, November 02, 2002 11:33 AM
                      Subject: Re: [Cheetahtemplate-discuss] searchList overriding settings?


                      > Well, I installed Cheetah 0.9.15a1. I adapted by base templates (very
                      > similar to SkeletonPage). I ran it. It worked. Then I noticed a small
                      > problem. I fixed it. I ran it. It threw an exception. I changed it back. I
                      > ran it. It still threw an exception. I've spent some time debugging, and I
                      > just don't get it.
                      >
                      > The exception is in:
                      >
                      > File "D:\PYTHON22\Lib\site-packages\Cheetah\NameMapper.py", line 188, in
                      > valueForKey
                      > return obj[key]
                      > AttributeError: MyPage instance has no attribute '__getitem__'
                      >
                      > It tries to find a placeholder value in a base class of MyPage (the leaf
                      > class containing the content). It goes into valueFromSearchList, iterates
                      > over the elements of searchList, comes to the MyPage instance, goes into
                      > _valueForName, tries to read obj[key] and boom. And it's right: MyPage
                      > instance doesn't implement __getitem__.
                      >
                      > I am totally flabberghasted.
                      >
                      > Jurie.
                      >
                      >
                      >
                      >
                      > -------------------------------------------------------
                      > This sf.net email is sponsored by: See the NEW Palm
                      > Tungsten T handheld. Power & Color in a compact size!
                      > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
                      > _______________________________________________
                      > Cheetahtemplate-discuss mailing list
                      > Cheetahtemplate-discuss@...
                      > https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                      >



                      -------------------------------------------------------
                      This sf.net email is sponsored by: See the NEW Palm
                      Tungsten T handheld. Power & Color in a compact size!
                      http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
                      _______________________________________________
                      Cheetahtemplate-discuss mailing list
                      Cheetahtemplate-discuss@...
                      https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                    • Mike Orr
                      It looks like you ve stumbled on another bug. I think (but Tavis will have to verify this) that it should have caught this exception and either raised
                      Message 10 of 10 , Nov 2, 2002
                      • 0 Attachment
                        It looks like you've stumbled on another bug. I think (but Tavis
                        will have to verify this) that it should have caught this exception
                        and either raised NameMapper.NotFound instead, or gone on to the
                        next object in the searchList.

                        Re diagnostic methods, I tried writing a couple last month but
                        they don't do much. Inspecting the top level of the searchList
                        is easy:
                        $searchList
                        or if you need to escape HTML metacharacters:
                        #filter WebSafe
                        $searchList
                        #filter None
                        I tried to make a routine that would display all the placeholder vars
                        accessible from each searchList element, and one that would do the
                        same but sort all the variables alphabetically, but I got stuck by:
                        (1) how to parse all the inherited variables so you don't miss any,
                        and don't call functions that have undesired side effects, and (2)
                        cStringIO wasn't giving output in a way it seems it should.
                        So the diagnostic methods are on hold until we get some better
                        ideas.

                        On Sat, Nov 02, 2002 at 05:27:38PM +0100, Jurie Horneman wrote:
                        > OK, I pretty much solved my own problems by single-stepping and trial and
                        > error.
                        >
                        > The problem I described below: in template 1, I used a placeholder $thing,
                        > which I defined in a dictionary passed to the constructor of a derived
                        > template. By adding #attr thing="" to the definition of template 1, the
                        > problem went away.
                        >
                        > A subsequent problem which took me a while to figure out was caused by a
                        > method and an attribute having the same name, and Cheetah not calling the
                        > one I expected.
                        >
                        > Both of these were my own mistakes, but it took me a long time to figure out
                        > where the problem was. Is there a better way to go about this? Are there
                        > diagnostic functions in Cheetah that could have helped? Should there be?
                        >
                        > Jurie.
                        >
                        > ----- Original Message -----
                        > From: "Jurie Horneman" <jhorneman@...>
                        > To: <cheetahtemplate-discuss@...>
                        > Sent: Saturday, November 02, 2002 11:33 AM
                        > Subject: Re: [Cheetahtemplate-discuss] searchList overriding settings?
                        >
                        >
                        > > Well, I installed Cheetah 0.9.15a1. I adapted by base templates (very
                        > > similar to SkeletonPage). I ran it. It worked. Then I noticed a small
                        > > problem. I fixed it. I ran it. It threw an exception. I changed it back. I
                        > > ran it. It still threw an exception. I've spent some time debugging, and I
                        > > just don't get it.
                        > >
                        > > The exception is in:
                        > >
                        > > File "D:\PYTHON22\Lib\site-packages\Cheetah\NameMapper.py", line 188, in
                        > > valueForKey
                        > > return obj[key]
                        > > AttributeError: MyPage instance has no attribute '__getitem__'
                        > >
                        > > It tries to find a placeholder value in a base class of MyPage (the leaf
                        > > class containing the content). It goes into valueFromSearchList, iterates
                        > > over the elements of searchList, comes to the MyPage instance, goes into
                        > > _valueForName, tries to read obj[key] and boom. And it's right: MyPage
                        > > instance doesn't implement __getitem__.
                        > >
                        > > I am totally flabberghasted.
                        > >
                        > > Jurie.
                        > >
                        > >
                        > >
                        > >
                        > > -------------------------------------------------------
                        > > This sf.net email is sponsored by: See the NEW Palm
                        > > Tungsten T handheld. Power & Color in a compact size!
                        > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
                        > > _______________________________________________
                        > > Cheetahtemplate-discuss mailing list
                        > > Cheetahtemplate-discuss@...
                        > > https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                        > >
                        >
                        >
                        >
                        > -------------------------------------------------------
                        > This sf.net email is sponsored by: See the NEW Palm
                        > Tungsten T handheld. Power & Color in a compact size!
                        > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
                        > _______________________________________________
                        > Cheetahtemplate-discuss mailing list
                        > Cheetahtemplate-discuss@...
                        > https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss

                        --
                        -Mike (Iron) Orr, iron@... (if mail problems: mso@...)
                        http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol


                        -------------------------------------------------------
                        This sf.net email is sponsored by: See the NEW Palm
                        Tungsten T handheld. Power & Color in a compact size!
                        http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
                        _______________________________________________
                        Cheetahtemplate-discuss mailing list
                        Cheetahtemplate-discuss@...
                        https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                      Your message has been successfully submitted and would be delivered to recipients shortly.