> > >> 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. >
The best thing to look at for examples similar to what I'm doing would the Pyramid docs in the section on "Extending an Application". I wouldn't recommend using the ZCA that way for simple things, but in the case of our large framework, it works beautifully for separating client/domain apps from the guts, and allows for very easy overriding of only the components that need to be different. The book "Web Component Development with Zope 3" has good stuff too, as does this: http://www.muthukadan.net/docs/zca.html Personally, I'm now a fanatical fan of using the zope interfaces and the ZCA as the single central train station for plugging as much of the architectural bits into each other as possible. There is a bit a of a learning curve, but much like SQAlchemy, the thornier the issues and the bigger the apps, the more I wind up liking it. =) Iain -- 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.
