On Apr 22, 2011, at 10:58 PM, Iain Duncan wrote: > > Right, I didn't do a thorough job of explaining it, so I agree with the your > assessment of the monkey patch, but my pattern isn't quite what you described > ( because of my poor explanation! ). I'm using Pyramid and taking advantage > of the Zope Component Architecture quite a bit. So there is a an application > 'package' in ZCA speak, with it's own set of ZCA registrations, domain model > classes and their user interface classes are all registered using ZCA > interfaces. My client app includes packages from the base framework, with > their domain model registrations and mapper registrations. One of those > package is my base auth package, good enough as is for most client apps that > include that package. The whole framework is broken up into packaged by > functionality ( auth package, cms package, etc ). Part of what a package does > is register it's model components in the registry and register a utility for > mapping those. That way a domain app can use any of the components, or easily > override any of the components by registering it's own version of one of the > components under the same interface ( IUser or whatever). Mapper making > callables are one of the components. In this case, my client app needs a > different user model, so it registers a different class using the IUser > interface. I got stuck on how to override one mapper only. > > Reading your description, I can see why I wouldn't want to clobber an already > created mapper, though that would have been easiest from my client app > perspective. The solution I've come to that seems to be an okay compromise is > to replace the entire auth packages make_mappers callable with an override > from the client app, in which I replace the User mapper. As this callable is > registered as a ZCA utility named 'auth_mappers', if I register it through a > ZCA package that is included with <includeOverrides..> it just hides the > other auth mappers callable and we don't have the User mapper getting called > twice. > > Long winded, but might be useful to someone googling some day! Thanks for > your explanation, it no doubt saved me from trying some kind of surgical > mapper deletion that would bite me in the ass later. =)
I'll try to study this more carefully tomorrow though Im tempted to tweet something thoughtless... all of that registration and action at a distance sounds like what it was like back when I used EJB or Spring. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
