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

Re: [Cheetahtemplate-discuss] Feedback, bugs, extensions (again)

Expand Messages
  • Chuck Esterbrook
    ... I never imagined there would even be a #return outside of an #if. Otherwise, you could just chop off the template... -Chuck
    Message 1 of 20 , Aug 7, 2001
    • 0 Attachment
      At 10:57 AM 8/7/2001 -0700, Mike Orr wrote:
      >I'm not sure I like this. It makes it impossible for the parser
      >to warn about runaway comments. How difficult would it be to
      >implement #stop or #return? Seems like it would be much
      >easier than most of our directives, at least if implemented at
      >compile time.
      >
      >Implemented at run time (inside an #if block) would be much
      >trickier, of course, since it would add much complexity to the
      >generated function. We may decide not to support this.

      I never imagined there would even be a #return outside of an #if.
      Otherwise, you could just chop off the template...

      -Chuck


      _______________________________________________
      Cheetahtemplate-discuss mailing list
      Cheetahtemplate-discuss@...
      http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
    • Tavis Rudd
      ... Apparently that s exactly what #stop does in Velocity. It stops not only parsing, but also output. _______________________________________________
      Message 2 of 20 , Aug 7, 2001
      • 0 Attachment
        On Tuesday 07 August 2001 10:58, Chuck Esterbrook wrote:
        > I never imagined there would even be a #return outside of
        > an #if. Otherwise, you could just chop off the
        > template...

        Apparently that's exactly what #stop does in Velocity. It
        stops not only parsing, but also output.

        _______________________________________________
        Cheetahtemplate-discuss mailing list
        Cheetahtemplate-discuss@...
        http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
      • Tavis Rudd
        ... I m starting to agree. ... At first I thought that would be impossible without a radical restructuring of Cheetah s CodeGenerator. On second thought, I
        Message 3 of 20 , Aug 7, 2001
        • 0 Attachment
          On Tuesday 07 August 2001 10:57, Mike Orr wrote:
          > On Mon, Aug 06, 2001 at 11:09:43PM -0700, Tavis Rudd
          wrote:
          > > I think I misunderstood what #stop was doing in
          > > Velocity. I'd assumed that it was just stopping the
          > > parsing of the template from that point on and
          > > rendering the rest of the template verbatim. So you
          > > want to exit a template at a certain point and return
          > > ONLY what has been processed up to that point? You can
          > > do this with the multiline comment directive #* ... *#.
          > > I've just checked in a change to allow the *# closure
          > > to be left off. When it is the rest of the template
          > > from #* will not be processed.
          >
          > I'm not sure I like this. It makes it impossible for the
          > parser to warn about runaway comments. How difficult
          > would it be to implement #stop or #return? Seems like it
          > would be much easier than most of our directives, at
          > least if implemented at compile time.

          I'm starting to agree.

          > Implemented at run time (inside an #if block) would be
          > much trickier, of course, since it would add much
          > complexity to the generated function. We may decide not
          > to support this.

          At first I thought that would be impossible without a
          radical restructuring of Cheetah's CodeGenerator. On second
          thought, I think it might be quite easy!

          All we have to do is generate the following code from #stop
          (or whatever we call it):
          output = ''.join(outputList)
          if trans and not iAmNested:
          trans.response().write(output)
          return output

          Have a look at this example and you'll see where it should
          go:
          =========================================
          from Cheetah.Template import Template as T
          TD = """
          $a
          aoeu
          #if 1
          inside the if block
          #return
          #end if
          $b
          """
          TO = T(TD, {'a':1234, 'b':999})
          print TO._generatedCode
          =========================================

          Cheers,
          Tavis



          _______________________________________________
          Cheetahtemplate-discuss mailing list
          Cheetahtemplate-discuss@...
          http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
        • Chuck Esterbrook
          ... I m split 50/50. Who s got a coin? -Chuck _______________________________________________ Cheetahtemplate-discuss mailing list
          Message 4 of 20 , Aug 7, 2001
          • 0 Attachment
            At 11:51 AM 8/7/2001 -0700, Tavis Rudd wrote:
            >Hi,
            >if we do decide to implement "#stop", what is the best name
            >for it? #stop, #return, #...?
            >Tavis

            I'm split 50/50. Who's got a coin?

            -Chuck


            _______________________________________________
            Cheetahtemplate-discuss mailing list
            Cheetahtemplate-discuss@...
            http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
          • Tavis Rudd
            Hi, if we do decide to implement #stop , what is the best name for it? #stop, #return, #...? Tavis _______________________________________________
            Message 5 of 20 , Aug 7, 2001
            • 0 Attachment
              Hi,
              if we do decide to implement "#stop", what is the best name
              for it? #stop, #return, #...?
              Tavis


              _______________________________________________
              Cheetahtemplate-discuss mailing list
              Cheetahtemplate-discuss@...
              http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
            • Mike Orr
              ... I was originally in favor of #return, but now I like #stop better. The name is self-evident, even to the uninitiated non-programmer. It provides Velocity
              Message 6 of 20 , Aug 7, 2001
              • 0 Attachment
                At 11:51 AM 8/7/2001 -0700, Tavis Rudd wrote:
                >if we do decide to implement "#stop", what is the best name
                >for it? #stop, #return, #...?

                I was originally in favor of #return, but now I like #stop better.
                The name is self-evident, even to the uninitiated non-programmer.
                It provides Velocity compatibility ("adherence to existing standards").
                And #return has connotations of returning from a function, which is
                partially true but partially not. For instance, users might think it
                can return a value, but that's not what it's for.

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

                _______________________________________________
                Cheetahtemplate-discuss mailing list
                Cheetahtemplate-discuss@...
                http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
              • Tavis Rudd
                that s 2 votes in favour of #stop and one ambivalent. #stop it is. I ll add the code to the CVS in a few minutes. ...
                Message 7 of 20 , Aug 7, 2001
                • 0 Attachment
                  that's 2 votes in favour of #stop and one ambivalent. #stop
                  it is. I'll add the code to the CVS in a few minutes.


                  On Tuesday 07 August 2001 11:56, Mike Orr wrote:
                  > At 11:51 AM 8/7/2001 -0700, Tavis Rudd wrote:
                  > >if we do decide to implement "#stop", what is the best
                  > > name for it? #stop, #return, #...?
                  >
                  > I was originally in favor of #return, but now I like
                  > #stop better. The name is self-evident, even to the
                  > uninitiated non-programmer. It provides Velocity
                  > compatibility ("adherence to existing standards"). And
                  > #return has connotations of returning from a function,
                  > which is partially true but partially not. For instance,
                  > users might think it can return a value, but that's not
                  > what it's for.

                  _______________________________________________
                  Cheetahtemplate-discuss mailing list
                  Cheetahtemplate-discuss@...
                  http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                • grahamd@dscpl.com.au
                  ... Not that simple I fear. The problem comes from the getattr method in my class. When using these classes, you wouldn t normally use (). Ie., I am not
                  Message 8 of 20 , Aug 7, 2001
                  • 0 Attachment
                    On Aug 06 23:09, Tavis Rudd <tavis@...> wrote:
                    >
                    > Subject: Re: [Cheetahtemplate-discuss] Feedback, bugs, extensions (again)
                    > This is a bit off-topic, but I should point out that I
                    > implemented autocalling so that it would only work when
                    > there are no parentheses or brackets in the $placeholder.
                    > I didn't want to make too many assumptions about when it
                    > should be used. In these case you have to manually include
                    > the (). For your situation it probably would be easiest if
                    > you just did it manually for these service objects anyway.
                    > Less chance of autocalling making the wrong choice that way.

                    Not that simple I fear. The problem comes from the getattr method in
                    my class. When using these classes, you wouldn't normally use (). Ie.,
                    I am not relying on autocalling. There is something about the generated
                    code which is triggering a call to getattr with empty attribute name.
                    Things start falling apart at that point. I will be looking at it some
                    more so I should be able to work out what is going on.

                    > Good idea. I'm not sure about the best way to implement
                    > this. .normalizePath() would probably be better than
                    > .getFileContents(). Also it would be best to have
                    > 'includeRoot', or whatever it's called, defined as setting:
                    > TO = Template(file="/somepath/file.tmpl",
                    > settings={'includeRoot':"/somepath"})
                    > You can already do this by subclassing Template. Do you
                    > think it's worthwhile adding this to the base class?

                    I guess it doesn't have to be. I would still pass the value in as
                    a setting, which I hope Cheetah would preseve, and have any derived
                    class query the setting. The reason for this is to avoid overriding
                    the __init__ method in the base class. If the __init__ method needs
                    to be overridden in the derived class, always need to be mindful of
                    any changes in Template __init__ to add extra arguments if I want
                    all possibilities still reflected in derived class __init__. It would
                    also be necessary to ensure I don't use a value for the setting
                    which you then adopt for something else later on.

                    > I think I misunderstood what #stop was doing in Velocity.
                    > I'd assumed that it was just stopping the parsing of the
                    > template from that point on and rendering the rest of the
                    > template verbatim. So you want to exit a template at a
                    > certain point and return ONLY what has been processed up to
                    > that point? You can do this with the multiline comment
                    > directive #* ... *#. I've just checked in a change to allow
                    > the *# closure to be left off. When it is the rest of the
                    > template from #* will not be processed. Note, that there
                    > is currently a limit to the length of multiline comments
                    > due to a silly implemenation restriction. I'll have this
                    > fixed by the tomorrow night.

                    When you open a multiline comment and don't close it, does that extend
                    indefinitely or only to the end of the scope of the file being processed.
                    Ie., if it is done in an included file, does that only mean the rest of
                    that file is thrown away, or everything. I only ask because SSI auto closes
                    open comments on end of file scope.


                    _______________________________________________
                    Cheetahtemplate-discuss mailing list
                    Cheetahtemplate-discuss@...
                    http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                  • grahamd@dscpl.com.au
                    ... Not that simple I fear. The problem comes from the getattr method in my class. When using these classes, you wouldn t normally use (). Ie., I am not
                    Message 9 of 20 , Aug 7, 2001
                    • 0 Attachment
                      On Aug 06 23:09, Tavis Rudd <tavis@...> wrote:
                      >
                      > Subject: Re: [Cheetahtemplate-discuss] Feedback, bugs, extensions (again)
                      > This is a bit off-topic, but I should point out that I
                      > implemented autocalling so that it would only work when
                      > there are no parentheses or brackets in the $placeholder.
                      > I didn't want to make too many assumptions about when it
                      > should be used. In these case you have to manually include
                      > the (). For your situation it probably would be easiest if
                      > you just did it manually for these service objects anyway.
                      > Less chance of autocalling making the wrong choice that way.

                      Not that simple I fear. The problem comes from the getattr method in
                      my class. When using these classes, you wouldn't normally use (). Ie.,
                      I am not relying on autocalling. There is something about the generated
                      code which is triggering a call to getattr with empty attribute name.
                      Things start falling apart at that point. I will be looking at it some
                      more so I should be able to work out what is going on.

                      > Good idea. I'm not sure about the best way to implement
                      > this. .normalizePath() would probably be better than
                      > .getFileContents(). Also it would be best to have
                      > 'includeRoot', or whatever it's called, defined as setting:
                      > TO = Template(file="/somepath/file.tmpl",
                      > settings={'includeRoot':"/somepath"})
                      > You can already do this by subclassing Template. Do you
                      > think it's worthwhile adding this to the base class?

                      I guess it doesn't have to be. I would still pass the value in as
                      a setting, which I hope Cheetah would preseve, and have any derived
                      class query the setting. The reason for this is to avoid overriding
                      the __init__ method in the base class. If the __init__ method needs
                      to be overridden in the derived class, always need to be mindful of
                      any changes in Template __init__ to add extra arguments if I want
                      all possibilities still reflected in derived class __init__. It would
                      also be necessary to ensure I don't use a value for the setting
                      which you then adopt for something else later on.

                      > I think I misunderstood what #stop was doing in Velocity.
                      > I'd assumed that it was just stopping the parsing of the
                      > template from that point on and rendering the rest of the
                      > template verbatim. So you want to exit a template at a
                      > certain point and return ONLY what has been processed up to
                      > that point? You can do this with the multiline comment
                      > directive #* ... *#. I've just checked in a change to allow
                      > the *# closure to be left off. When it is the rest of the
                      > template from #* will not be processed. Note, that there
                      > is currently a limit to the length of multiline comments
                      > due to a silly implemenation restriction. I'll have this
                      > fixed by the tomorrow night.

                      When you open a multiline comment and don't close it, does that extend
                      indefinitely or only to the end of the scope of the file being processed.
                      Ie., if it is done in an included file, does that only mean the rest of
                      that file is thrown away, or everything. I only ask because SSI auto closes
                      open comments on end of file scope.

                      _______________________________________________
                      Cheetahtemplate-discuss mailing list
                      Cheetahtemplate-discuss@...
                      http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                    • Tavis Rudd
                      ... I ll have another look at you example code. ... Actually, the __init__() method of Cheetah was coded to make extending the keyword args in subclasses or in
                      Message 10 of 20 , Aug 7, 2001
                      • 0 Attachment
                        On Tuesday 07 August 2001 16:45, you wrote:
                        > On Aug 06 23:09, Tavis Rudd <tavis@...> wrote:
                        > > Subject: Re: [Cheetahtemplate-discuss] Feedback, bugs,
                        > > extensions (again) This is a bit off-topic, but I
                        > > should point out that I implemented autocalling so that
                        > > it would only work when there are no parentheses or
                        > > brackets in the $placeholder. I didn't want to make too
                        > > many assumptions about when it should be used. In
                        > > these case you have to manually include the (). For
                        > > your situation it probably would be easiest if you just
                        > > did it manually for these service objects anyway. Less
                        > > chance of autocalling making the wrong choice that way.
                        >
                        > Not that simple I fear. The problem comes from the
                        > getattr method in my class. When using these classes, you
                        > wouldn't normally use (). Ie., I am not relying on
                        > autocalling. There is something about the generated code
                        > which is triggering a call to getattr with empty
                        > attribute name. Things start falling apart at that point.
                        > I will be looking at it some more so I should be able to
                        > work out what is going on.

                        I'll have another look at you example code.

                        > > Good idea. I'm not sure about the best way to implement
                        > > this. .normalizePath() would probably be better than
                        > > .getFileContents(). Also it would be best to have
                        > > 'includeRoot', or whatever it's called, defined as
                        > > setting: TO = Template(file="/somepath/file.tmpl",
                        > >
                        > > settings={'includeRoot':"/somepath"}) You can already
                        > > do this by subclassing Template. Do you think it's
                        > > worthwhile adding this to the base class?
                        >
                        > I guess it doesn't have to be. I would still pass the
                        > value in as a setting, which I hope Cheetah would
                        > preseve, and have any derived class query the setting.
                        > The reason for this is to avoid overriding the __init__
                        > method in the base class. If the __init__ method needs to
                        > be overridden in the derived class, always need to be
                        > mindful of any changes in Template __init__ to add extra
                        > arguments if I want all possibilities still reflected in
                        > derived class __init__. It would also be necessary to
                        > ensure I don't use a value for the setting which you then
                        > adopt for something else later on.

                        Actually, the __init__() method of Cheetah was coded to
                        make extending the keyword args in subclasses or in the
                        base class safe for both.


                        > When you open a multiline comment and don't close it,
                        > does that extend indefinitely or only to the end of the
                        > scope of the file being processed. Ie., if it is done in
                        > an included file, does that only mean the rest of that
                        > file is thrown away, or everything. I only ask because
                        > SSI auto closes open comments on end of file scope.

                        At the moment it extends indefinately. But will probably
                        change. There are two ways to implement #includes. The
                        first is to literally include the includeTxt in the
                        template definition and restart the processor. The second
                        is to wrap all the includeTxt up in a new Template object
                        and call its .respond() for each request. At the moment
                        Cheetah is using the first approach but everything is set
                        to change over to the second.

                        Have a look at
                        Cheetah.CodeGenerator.preProcessIncludeDirectives
                        You'll see what I mean.

                        How do you think the un-ending comments should be handled?
                        Cheers,
                        Tavis


                        _______________________________________________
                        Cheetahtemplate-discuss mailing list
                        Cheetahtemplate-discuss@...
                        http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                      • grahamd@dscpl.com.au
                        ... I am a bit wary of having it extend beyond the scope (file) it is used in. The reason is that if you forget to close a comment in an included file, you
                        Message 11 of 20 , Aug 7, 2001
                        • 0 Attachment
                          > How do you think the un-ending comments should be handled?

                          I am a bit wary of having it extend beyond the scope (file) it is used
                          in. The reason is that if you forget to close a comment in an included
                          file, you then will not see your page rendered correctly and might spend
                          some time tracking down why, especially if you have deeply nested includes.

                          My feeling is that a warning should really be spat out if a multiline
                          comment isn't closed by the end of its scope and for it to be closed
                          automatically. This does mean though that you can't use it as an equivalent
                          to #stop as I was talking about.

                          BTW, your reply and this message aren't to the list. Don't know if you
                          want to bounce it there or not.


                          _______________________________________________
                          Cheetahtemplate-discuss mailing list
                          Cheetahtemplate-discuss@...
                          http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                        • Tavis Rudd
                          ... Agreed. ... Oops, do you mind bouncing it. _______________________________________________ Cheetahtemplate-discuss mailing list
                          Message 12 of 20 , Aug 7, 2001
                          • 0 Attachment
                            On Tuesday 07 August 2001 17:34, you wrote:
                            > > How do you think the un-ending comments should be
                            > > handled?
                            >
                            > I am a bit wary of having it extend beyond the scope
                            > (file) it is used in. The reason is that if you forget to
                            > close a comment in an included file, you then will not
                            > see your page rendered correctly and might spend some
                            > time tracking down why, especially if you have deeply
                            > nested includes.
                            > My feeling is that a warning should really be spat out if
                            > a multiline comment isn't closed by the end of its scope
                            > and for it to be closed automatically. This does mean
                            > though that you can't use it as an equivalent to #stop as
                            > I was talking about.

                            Agreed.

                            > BTW, your reply and this message aren't to the list.
                            > Don't know if you want to bounce it there or not.
                            Oops, do you mind bouncing it.


                            _______________________________________________
                            Cheetahtemplate-discuss mailing list
                            Cheetahtemplate-discuss@...
                            http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                          • Chuck Esterbrook
                            ... More often that not, I think these will be mistakes and not intentional. And even when intentional, I think it indicates that the person is doing something
                            Message 13 of 20 , Aug 7, 2001
                            • 0 Attachment
                              At 05:25 PM 8/7/2001 -0700, Tavis Rudd wrote:
                              >How do you think the un-ending comments should be handled?

                              More often that not, I think these will be mistakes and not intentional.

                              And even when intentional, I think it indicates that the person is doing
                              something tricky that might be best done outside the template or with other
                              Cheetah features. Unless someone can show a compelling example otherwise.


                              On a related note, do #sets carry through after the #include? eg, if an
                              #include #sets a new $var, can that $var be seen in the main template?


                              -Chuck


                              _______________________________________________
                              Cheetahtemplate-discuss mailing list
                              Cheetahtemplate-discuss@...
                              http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                            • Tavis Rudd
                              ... I agree. Graham, would you mind if comments that aren t explicitly ended be treated as errors? ... No, because #set $x= 1234 translates to x=python in
                              Message 14 of 20 , Aug 7, 2001
                              • 0 Attachment
                                On Tuesday 07 August 2001 17:57, you wrote:
                                > At 05:25 PM 8/7/2001 -0700, Tavis Rudd wrote:
                                > >How do you think the un-ending comments should be
                                > > handled?
                                >
                                > More often that not, I think these will be mistakes and
                                > not intentional.
                                >
                                > And even when intentional, I think it indicates that the
                                > person is doing something tricky that might be best done
                                > outside the template or with other Cheetah features.
                                > Unless someone can show a compelling example otherwise.

                                I agree. Graham, would you mind if comments that aren't
                                explicitly ended be treated as errors?

                                > On a related note, do #sets carry through after the
                                > #include? eg, if an #include #sets a new $var, can that
                                > $var be seen in the main template?

                                No, because #set "$x= 1234" translates to "x=python" in the
                                generated code rather than going through the searchList.
                                Everything else in the searchList transfers over ...
                                nestedTemplate = Template.Template(
                                templateDef=includeString,
                                overwriteSettings=templateObj.settings(),
                                searchList=templateObj.searchList(),
                                cheetahBlocks=templateObj._cheetahBlocks,
                                macros=templateObj._macros)

                                Do you think that might cause problems? There's other ways
                                to implement it that would allow them to work between
                                #includes.

                                Tavis

                                _______________________________________________
                                Cheetahtemplate-discuss mailing list
                                Cheetahtemplate-discuss@...
                                http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                              • Chuck Esterbrook
                                ... I think it could be useful. #if someCondition #include vars1 #else #include vars2 #end if $useVars #useMacros And it fits my notion of what an #include
                                Message 15 of 20 , Aug 7, 2001
                                • 0 Attachment
                                  At 06:16 PM 8/7/2001 -0700, Tavis Rudd wrote:
                                  >No, because #set "$x= 1234" translates to "x=python" in the
                                  >generated code rather than going through the searchList.
                                  >Everything else in the searchList transfers over ...
                                  > nestedTemplate = Template.Template(
                                  > templateDef=includeString,
                                  > overwriteSettings=templateObj.settings(),
                                  > searchList=templateObj.searchList(),
                                  > cheetahBlocks=templateObj._cheetahBlocks,
                                  > macros=templateObj._macros)
                                  >
                                  >Do you think that might cause problems? There's other ways
                                  >to implement it that would allow them to work between
                                  >#includes.

                                  I think it could be useful.

                                  #if someCondition
                                  #include "vars1"
                                  #else
                                  #include "vars2"
                                  #end if
                                  $useVars
                                  #useMacros


                                  And it fits my notion of what an #include is (as opposed to an 'import' or
                                  'use').

                                  I'm not personally pressed on this issue. eg, none of my projects currently
                                  need this.


                                  Of course, as soon as you switch it, someone will complain that their
                                  #includes are interfering with the main file. :-)

                                  -Chuck


                                  _______________________________________________
                                  Cheetahtemplate-discuss mailing list
                                  Cheetahtemplate-discuss@...
                                  http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                                • grahamd@dscpl.com.au
                                  ... Don t think it is a question of whether I mind or not, I am not relying on it doing it one way or the other. Right now I haven t really written any Cheetah
                                  Message 16 of 20 , Aug 7, 2001
                                  • 0 Attachment
                                    On Aug 07 18:16, Tavis Rudd <tavis@...> wrote:
                                    >
                                    > Subject: Re: [Cheetahtemplate-discuss] Feedback, bugs, extensions (again)
                                    >
                                    > On Tuesday 07 August 2001 17:57, you wrote:
                                    > > At 05:25 PM 8/7/2001 -0700, Tavis Rudd wrote:
                                    > > >How do you think the un-ending comments should be
                                    > > > handled?
                                    > >
                                    > > More often that not, I think these will be mistakes and
                                    > > not intentional.
                                    > >
                                    > > And even when intentional, I think it indicates that the
                                    > > person is doing something tricky that might be best done
                                    > > outside the template or with other Cheetah features.
                                    > > Unless someone can show a compelling example otherwise.
                                    >
                                    > I agree. Graham, would you mind if comments that aren't
                                    > explicitly ended be treated as errors?

                                    Don't think it is a question of whether I mind or not, I am not relying
                                    on it doing it one way or the other. Right now I haven't really written
                                    any Cheetah templates but am just seeing how it can be integrated into
                                    an alternate HTTP servlet framework. I am therefore far from being any
                                    authority on it. :-)

                                    BTW, what does Cheetah currently do if any sort of start/end directive
                                    isn't closed?

                                    With regard to #stop and what started this thread. I have had a bit more
                                    of a think about why I thought I might need this. Taking the simplistic
                                    approach of stopping all further processing, probably ain't the best idea.
                                    It may be appropriate to leave it at present until real world cases call
                                    for it. When I have a good example besides that of debugging, will mail
                                    something else.

                                    _______________________________________________
                                    Cheetahtemplate-discuss mailing list
                                    Cheetahtemplate-discuss@...
                                    http://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
                                  Your message has been successfully submitted and would be delivered to recipients shortly.