Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1276 (closed defect: invalid)

Opened 12 years ago

Last modified 11 years ago

TurboGears not Buffet-compliant

Reported by: cwells Owned by: anonymous
Priority: high Milestone:
Component: TurboGears Version: 1.0.1
Severity: minor Keywords:


The Buffet API defines the signature for a Buffet adapter's init method to accept a *dictionary* as the config parameter. TurboGears instead passes a CherryPy? config object which, while addressable via hash values, lacks several important attributes which would qualify it as a dictionary-like object (no keys(), items(), etc).

Change History

comment:1 follow-up: ↓ 2 Changed 12 years ago by jorge.vargas

umm is this affecting any code or just a "violation" to the std? I believe TG applied the "if it quacks like a duck" philosophy here.

comment:2 in reply to: ↑ 1 Changed 12 years ago by cwells

Replying to jorge.vargas:

umm is this affecting any code or just a "violation" to the std? I believe TG applied the "if it quacks like a duck" philosophy here.

Yes, it makes it impossible to write generic adapters that work for both TurboGears and Pylons. My adapter for Breve is full of bits of special case code for dealing with the different ways both frameworks pass data into the adapter. This is one place where TurboGears gets it wrong.

And putting feathers on a donkey doesn't make it quack like a duck ;-) A data structure that *only* allows direct access via explicit key values isn't a dictionary by any stretch. If the CherryPy? config object also had .items(), .keys(), and .values() then I'd have no complaint.

comment:3 Changed 12 years ago by jorge.vargas

  • Priority changed from normal to high
  • Owner changed from jorge.vargas to anonymous
  • Component changed from unassigned to CherryPy
  • Severity changed from normal to minor
  • Milestone changed from 1.0.2 to 1.1

ok a quick look at  http://www.cherrypy.org/browser/tags/cherrypy-2.2.1/cherrypy/config.py show me what found. Now looking at CP3.0 code this is implemented properly  http://www.cherrypy.org/browser/tags/cherrypy-3.0.0/cherrypy/_cpconfig.py#L194 so I believe the upgrade to 3.0 will fix this.

comment:4 Changed 12 years ago by cwells

Yep, it looks like CP3 is deriving from dict, so that should solve the problem. Of course, if we can address #1277, then it could be solved at that point as well.

comment:5 Changed 12 years ago by alberto

  • Milestone changed from 1.1 to __unclassified__

Batch moved into unclassified from 1.1 to properly track progress on the later

comment:6 Changed 11 years ago by Chris Arndt

  • Status changed from new to closed
  • Component changed from CherryPy to TurboGears
  • Version changed from trunk to 1.0.1
  • Resolution set to invalid
  • Milestone __unclassified__ deleted

I don't quite get this. load_engines (previously called _load_engines) has passed a normal dictionary filled with values from the config object since this function was created. In no revision do I see the config object passed directly.

Closing this ticket as invalid now. If you were refering to another place in the code than turbogears.view.base.load_engines, please reopen the ticket and specify the location of the error.

Note: See TracTickets for help on using tickets.