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

[Cheetahtemplate-discuss] NameMapper issues with Google App Engine db.Model objects

Expand Messages
  • Chad George
    In AppEngine, db.Model objects unfortunately implement a has_key() method that checks if a model instance has had a key assigned to it yet. This causes
    Message 1 of 3 , Aug 14, 2010
      In AppEngine, db.Model objects unfortunately implement a "has_key()"
      method that checks if a model instance has had a key assigned to it
      yet.

      This causes NameMapper.py to determine that it should use dictionary
      style access instead of getattr().

      I think there are two possible solutions:
      1. use hasattr(obj, "keys") instead of hasattr(obj, "has_key")
      2. try to use hasattr()/getattr() ... before trying dictionary access

      I tested #1 and it seems to work...but I'm too new to Cheetah to know
      if there are unintended consequences

      For #2 the biggest issue I see is in _valueForName() ... you
      definitely don't want to hit the exception on every access to a
      dictionary, so you'd need another call to hasattr() ... which
      presumably was just done before getting to _valueForName() in the
      first place.

      Probably not a big deal either way. I'm not sure if there was a
      pre-existing design decision to try dictionary access before attribute
      access.

      - Chad

      ------------------------------------------------------------------------------
      This SF.net email is sponsored by

      Make an app they can't live without
      Enter the BlackBerry Developer Challenge
      http://p.sf.net/sfu/RIM-dev2dev
      _______________________________________________
      Cheetahtemplate-discuss mailing list
      Cheetahtemplate-discuss@...
      https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
    • R. Tyler Ballance
      ... I /think/ you can circumvent this functionality by disabling autocalling, I ve not used AppEngine, but you might try that:
      Message 2 of 3 , Aug 14, 2010
        On Sat, 14 Aug 2010, Chad George wrote:

        > In AppEngine, db.Model objects unfortunately implement a "has_key()"
        > method that checks if a model instance has had a key assigned to it
        > yet.
        >
        > This causes NameMapper.py to determine that it should use dictionary
        > style access instead of getattr().


        I /think/ you can circumvent this functionality by disabling autocalling, I've
        not used AppEngine, but you might try that:

        http://cheetahtemplate.org/docs/users_guide_html_multipage/language.namemapper.autocalling.html




        >
        > I think there are two possible solutions:
        > 1. use hasattr(obj, "keys") instead of hasattr(obj, "has_key")
        > 2. try to use hasattr()/getattr() ... before trying dictionary access
        >
        > I tested #1 and it seems to work...but I'm too new to Cheetah to know
        > if there are unintended consequences
        >
        > For #2 the biggest issue I see is in _valueForName() ... you
        > definitely don't want to hit the exception on every access to a
        > dictionary, so you'd need another call to hasattr() ... which
        > presumably was just done before getting to _valueForName() in the
        > first place.
        >
        > Probably not a big deal either way. I'm not sure if there was a
        > pre-existing design decision to try dictionary access before attribute
        > access.
        >
        > - Chad
        >
        > ------------------------------------------------------------------------------
        > This SF.net email is sponsored by
        >
        > Make an app they can't live without
        > Enter the BlackBerry Developer Challenge
        > http://p.sf.net/sfu/RIM-dev2dev
        > _______________________________________________
        > Cheetahtemplate-discuss mailing list
        > Cheetahtemplate-discuss@...
        > https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
        Cheers,
        -R. Tyler Ballance
        --------------------------------------
        GitHub: http://github.com/rtyler
        Twitter: http://twitter.com/agentdero
      • Tavis Rudd
        Unfortunately, I don t think that will work. Disabling NameMapper itself will. This has been a long standing issue with NameMapper that, fortunately, people
        Message 3 of 3 , Aug 14, 2010
          Unfortunately, I don't think that will work. Disabling NameMapper itself
          will.

          This has been a long standing issue with NameMapper that, fortunately,
          people rarely experience as most library designers don't add `has_key`
          without also implementing the rest of the mapping/dict protocol.

          The problem with checking for `keys` is the same as checking for
          `has_key`: someone will have classes that aren't dicts but have `keys`.
          Maybe we could test for both or some other combination that is likely to
          have less false positives.

          On Sat, 14 Aug 2010, R. Tyler Ballance wrote:

          >
          > On Sat, 14 Aug 2010, Chad George wrote:
          >
          >> In AppEngine, db.Model objects unfortunately implement a "has_key()"
          >> method that checks if a model instance has had a key assigned to it
          >> yet.
          >>
          >> This causes NameMapper.py to determine that it should use dictionary
          >> style access instead of getattr().
          >
          >
          > I /think/ you can circumvent this functionality by disabling autocalling, I've
          > not used AppEngine, but you might try that:
          >
          > http://cheetahtemplate.org/docs/users_guide_html_multipage/language.namemapper.autocalling.html
          >
          >
          >
          >
          >>
          >> I think there are two possible solutions:
          >> 1. use hasattr(obj, "keys") instead of hasattr(obj, "has_key")
          >> 2. try to use hasattr()/getattr() ... before trying dictionary access
          >>
          >> I tested #1 and it seems to work...but I'm too new to Cheetah to know
          >> if there are unintended consequences
          >>
          >> For #2 the biggest issue I see is in _valueForName() ... you
          >> definitely don't want to hit the exception on every access to a
          >> dictionary, so you'd need another call to hasattr() ... which
          >> presumably was just done before getting to _valueForName() in the
          >> first place.
          >>
          >> Probably not a big deal either way. I'm not sure if there was a
          >> pre-existing design decision to try dictionary access before attribute
          >> access.
          >>
          >> - Chad
          >>
          >> ------------------------------------------------------------------------------
          >> This SF.net email is sponsored by
          >>
          >> Make an app they can't live without
          >> Enter the BlackBerry Developer Challenge
          >> http://p.sf.net/sfu/RIM-dev2dev
          >> _______________________________________________
          >> Cheetahtemplate-discuss mailing list
          >> Cheetahtemplate-discuss@...
          >> https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
          > Cheers,
          > -R. Tyler Ballance
          > --------------------------------------
          > GitHub: http://github.com/rtyler
          > Twitter: http://twitter.com/agentdero
          >
          >

          ------------------------------------------------------------------------------
          This SF.net email is sponsored by

          Make an app they can't live without
          Enter the BlackBerry Developer Challenge
          http://p.sf.net/sfu/RIM-dev2dev
          _______________________________________________
          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.