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

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

Expand Messages
  • Tavis Rudd
    ... Apparently that s exactly what #stop does in Velocity. It stops not only parsing, but also output. _______________________________________________
    Message 1 of 20 , Aug 7, 2001
      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 2 of 20 , Aug 7, 2001
        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 3 of 20 , Aug 7, 2001
          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 4 of 20 , Aug 7, 2001
            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 5 of 20 , Aug 7, 2001
              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 6 of 20 , Aug 7, 2001
                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 7 of 20 , Aug 7, 2001
                  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 8 of 20 , Aug 7, 2001
                    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 9 of 20 , Aug 7, 2001
                      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 10 of 20 , Aug 7, 2001
                        > 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 11 of 20 , Aug 7, 2001
                          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 12 of 20 , Aug 7, 2001
                            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 13 of 20 , Aug 7, 2001
                              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 14 of 20 , Aug 7, 2001
                                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 15 of 20 , Aug 7, 2001
                                  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.