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

Re: [Cheetahtemplate-discuss] inverting name search order

Expand Messages
  • Alejandro Dubrovsky
    Thanks for the detailed explanation, Mike. Comments interspeded below. ... Cool, CHANGES file will do. ... The reason I needed them was due to bad template
    Message 1 of 6 , Nov 30, 2006
    • 0 Attachment
      Thanks for the detailed explanation, Mike. Comments interspeded below.

      On Thu, 2006-11-30 at 13:35 -0800, Mike Orr wrote:
      > On 11/29/06, Alejandro Dubrovsky <dubrovsky@...> wrote:
      > > On Wed, 2006-11-29 at 09:12 +0000, Brian Bird wrote:
      > > > I had a similar problem a while ago. Error Catchers can be used, but I
      > > > found some bugs in them at the time (I think they were fixed). However,
      > > > error catchers are relatively slow, and also only meant for debugging
      > > > (apparently).
      > > >
      > > > You can write $!foo in certain cases which is equivalent to
      > > > $getVar('foo','') which is what I ended up doing.
      > > >
      > > Hadn't seen $! anywhere. That should solve 90% of my cases. Thanks!
      >
      > The Cheetah documentation is way behind. What's there works but there
      > are many undocumented features since 1.0, listed in the CHANGES file.
      > Unfortunately it's a 160+ hour project to rewrite the Users Guide.

      Cool, CHANGES file will do.
      >
      > > > However, this syntax can't be used inside expressions, so I can't write:
      > > > $myFunction($!foo)
      > > > which is a shame. It might be nice if this worked because then $getVar
      > > > would only be needed if you wanted to explicitly specify a default value
      > > > other than ''. See this thread:
      > > > http://sourceforge.net/mailarchive/message.php?msg_id=15484950
      > > >
      > > And if that was deemed a bug and solved, it would be good if the meaning
      > > of the default substitute could be configurable (I'd prefer it to be
      > > None instead of '')
      >
      > Tavis never answered that thread so I don't know what he's thinking.
      > But the standard response to checking whether a $placeholder exist is,
      > "you have a bad template design". If Alejandro wishes to discuss why
      > he thinks he needs variables that sometimes exist, perhaps we can come
      > up with an alternative.

      The reason I needed them was due to bad template design. It comes from
      different expectations for templates as opposed to programs. I want to
      use templates in quick-and-dirty hack mode, with little need for
      thought, and applying very frequent changes, with no need to think about
      variable declaration, code structure. I want failures to trigger stop
      of execution in programs, but to gracefully degrade in templates. These,
      of course, are just my biases wrt templates. I don't expect the Chettah
      authors to have the same aims, but they must agree somewhat with the
      sentiments, otherwise why add the obviously hackish $!variable?

      I have "fixed" the need, if not the design, over the last day and a half
      by using $! and self.varExists/#set combos, and getting rid of my
      catchalls, but these last two changes just feel like painful boilerplate
      without any obvious benefits.

      > A few general ideas:
      >
      > 1) '#attr $foo = None' in a superclass template will provide a default value.
      >
      Yes, but added thought and diligence needed. For every variable added
      anywhere on the template, need to set a default.

      > 2) Have a companion boolean flag that says whether a feature is
      > present, then do '#if $feature_present'.
      >
      This one I don't like for an arguably good reason. It adds
      interdependence between the code and the display.

      > 3) Put the sometimes-values in a named dict and use the 'in' operator:
      > '#if $desired_key in $my_data'.
      >
      Not bad, but again added boilerplate and setup, with little benefit.

      [snippage]
      > - $var in an expression: a read-only lookup. No filter wrapper, no
      > try/except. $!var is equivalent to $var.
      >
      > - $var on the left side of an assignment ('#set $var = ...', '#for
      > $var in ...') merely drops the '$' and leaves the variable as-is in
      > Python. This modifies a local variable only (including $self). '#set
      > module' modifies a Python global variable. '#set global' modifies a
      > special "set global" variable that is visble in all parts of the
      > template and (I think) in #include'd templates.
      >
      > Given all this, I'm not sure '$!var' not working in expressions is a
      > bug. The correct answer seems to be, "rewrite the template so you
      > don't need it". I'm open to hearing use cases that argue for
      > different behavior. But should the result be None, "", or what? Can
      > we even argue that None is appropriate for most situations?

      Configurable through compiler settings seems like the correct answer,
      maybe defaulting to None.

      [snippage]
      >
      > As for Alejandro's #import problem...
      > Cheetah.NameMapper._namespaces() currently looks like this:
      >
      > def _namespaces(callerFrame, searchList=None):
      > yield callerFrame.f_locals
      > if searchList:
      > for namespace in searchList:
      > yield namespace
      > yield callerFrame.f_globals
      > yield __builtins__
      >
      > This yields several namespaces to search in. Local variables come
      > first, then the searchList, then module globals, then Python builtins.
      > Anything #import'd is a module global, so it will come after the
      > catchall object Alejandro is using. Them's the breaks.
      >

      Yes. Couple of maybe ugly compiler configurable settings: One
      namespaces_last, or more configurable, a list of namespace constants
      that would define order of search
      ([NAMESPACE_LOCALS,NAMESPACE_SEARCHLIST,NAMESPACE_GLOBALS,NAMESPACE_BUILTINS]) although I'd argue for builtins and globals to be combined.

      > By the way, 'searchList' at this point contains the "set globals"
      > dict, then the user-specified namespaces, then the template's "self".
      > This is done in the first twenty lines of
      > Cheetah.Template.Template._initCheetahInstance().
      >
      > So Alejandro will have to find another way to make his #import'd
      > varibles visible in spite of the catchall.
      >
      > As another aside, there is a catchall object distributed with Cheetah,
      > by the way. Cheetah.Tools.RecursiveNull. It returns "" for
      > everything including attributes, subscripts, and calling.
      >
      Thanks, didn't know about that one.
      alejandro



      -------------------------------------------------------------------------
      Take Surveys. Earn Cash. Influence the Future of IT
      Join SourceForge.net's Techsay panel and you'll get the chance to share your
      opinions on IT & business topics through brief surveys - and earn cash
      http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
      _______________________________________________
      Cheetahtemplate-discuss mailing list
      Cheetahtemplate-discuss@...
      https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
    • Mike Orr
      ... I myself sometimes wanted it in the past because I came to Cheetah from PHP where this is standard. But I never actually did end up using it. A few
      Message 2 of 6 , Nov 30, 2006
      • 0 Attachment
        On 11/30/06, Alejandro Dubrovsky <dubrovsky@...> wrote:
        > The reason I needed them was due to bad template design. It comes from
        > different expectations for templates as opposed to programs. I want to
        > use templates in quick-and-dirty hack mode, with little need for
        > thought, and applying very frequent changes, with no need to think about
        > variable declaration, code structure. I want failures to trigger stop
        > of execution in programs, but to gracefully degrade in templates. These,
        > of course, are just my biases wrt templates. I don't expect the Chettah
        > authors to have the same aims, but they must agree somewhat with the
        > sentiments, otherwise why add the obviously hackish $!variable?

        I myself sometimes wanted it in the past because I came to Cheetah
        from PHP where this is standard. But I never actually did end up
        using it. A few people requested the shorter syntax so it got added.
        $getVar("var", None) is not self-documenting; you'd have to know why
        somebody used it.

        The features we've added to Cheetah have generally been things people
        need in production situations. A missing variable in a production
        situation usually means something very bad has happened, and just
        displaying the template anyway is the wrong thing. Tavis may add the
        compiler settings anyway; he seems pretty willing to add settings
        people request. But changing the search order sounds like a good way
        to confuse other template maintainers.

        --
        Mike Orr <sluggoster@...>

        -------------------------------------------------------------------------
        Take Surveys. Earn Cash. Influence the Future of IT
        Join SourceForge.net's Techsay panel and you'll get the chance to share your
        opinions on IT & business topics through brief surveys - and earn cash
        http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
        _______________________________________________
        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.