On Mon, Apr 13, 2009 at 03:01:01PM -0400, Jeff Hammel wrote: > On Mon, Apr 13, 2009 at 02:53:56PM -0400, Luke Tucker wrote: > > > > I'm shopping around a bit for component frameworks for melkjug's plugins > > ( http://oss.openplans.org/melkjug/wiki/PluginPoints ) and I'd like to > > hear your input if you have a sec. > > > > I feel like Trac's component model is all I really want at the moment, > > but I haven't used it extensively in practice. I really like the > > straightforwardness of it, the digestibility of the overall concept and > > the limited scope -- drawback is afaict it is not packaged separately > > (although it looks like the code is very orthogonal to the rest of trac > > and it wouldn't be hard to take) Jeff, I think you might have the most > > to say about what you like/dislike about Trac's model and/or it's re-use. > > See http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture > > I would say that if you want a simple component architecture, then Trac is a > very good model. Extension points are defined, plugins implement an > interface which is plugged into extension points. It works very well for > Trac.
I haven't really used the trac model, so I can't speak to the differences. > > As Josh reminded me, we also have a ton of internal ZCA knowledge, so I > > figured I should do a little due diligence on that front too... Melkjug > > already uses a smattering of ZCA to document interfaces in the model. > > Personally, I find ZCA to be a bit zany and overwrought for what I'm > > intending -- the documentation makes my eyes want to glaze over even > > though I already understand it... That said, it's cruft is grown from > > battle worn use cases and it's clearly got some momentum and backing as > > an independent framework. > > What Trac misses is adaptation, mostly. Also, you can't have composite > interfaces, though this is an implementation detail. ExtensionPoints get > turned into lists of components, which is a bit sloppy if you want to asser > that exactly one gets used. But this is probably okay as you can always > throw in assert statements. Again, I'd say adaptation is the main missing > thing. If you can live without it, you're probably good. There's a conversation about application configuration going on in the pypes project too: http://www.openplans.org/projects/pypefitters/lists/pypefitters-discussion/archive/2009/04/1239260482813/forum_view#1239509309917 > > Maybe all I want to do is paper over the foul details of ZCA that I > > don't care about with something that behaves conceptually like Trac's > > model for the 99% case (use ZCA as a meta-meta-framework) but let the > > machinery hang out ... juuust in case. > > > > Anything else I should be looking at? Thoughts? > > > > - Luke I'd say to use the simplest thing that works. If you do go with the zca, I think you're right to just paper over the details that you don't care about. If you want to use xml as the configuration language, it may be a little bit of work to reuse the xml parsing of zope.configuration. I believe that the repoze guys created a new package, repoze.zcml, because zope.configuration expects zope.security, which I think pulls in a lot more packages. But if you don't want xml configuration, then the provideAdapter and provideUtility calls should work for you if you use the zca. > Just to throw a zany idea I've been thinking about, implicit interfaces vs > explicit. Instead of marking things as implementing other things, you give > rules by which a component is said to implement an interface. But since you > want something simple, probably doing something experimental like this might > not be the best. > > Jeff Interesting idea. Would this happen at startup time with something like martian? Robert -- Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/04/1239652913061 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
