On Tue, 2009-04-28 at 15:09 -0700, Ben Bangert wrote: > On Apr 28, 2009, at 2:43 PM, Wichert Akkerman wrote: > > > If you decide to use zope.component a controller could be a named > > utility. You could then register it like so: > > > > class BaseController(object): > > """This is the standard Pylons base controller class.""" > > implements(IPylonsController) > > > > > > class MyController(BaseController): > > """My very own controller.""" > > > > registerUtility(MyController, name="my_controller") > > Yikes! :) > > I was trying to only include interfaces enough such that an end user > would never have to see them but they'd be helpful to allow/encourage > plug-ins. The second a Pylons developer has to start knowing > interfaces, utilities, registering things *just* to get the basic app > working, Pylons has lost something I think is very important. I was > aiming for any potential use of the zope stuff purely for use with > plug-ins, or changing core aspects of Pylons that are currently > difficult to tweak. > > Though its definitely true that even making a small basic app might > involve an extra step to allow for pluggability.
If I may pipe in from the peanut gallery, I think it is also critical for these decisions to think from a marketing perspective about *who* a Pylons target user really is. And it's definitely not the same person as a target Django user. While it is great to keep pylons simple in a simple-is-elegant context, I do not personally think Pylons should forgo power for end-user simplicity. IMHO, people who are going to be turned off by having to understand some extra concepts like zope interfaces and having to make a call to a registry really aren't likely to be choosing Pylons, those are Django's good-fit. On the other hand, I think a lot of people ( me included! ) have gravitated to pylons when they realized that they were going to be doing a lot of complex stuff with a big app, and didn't want the framework limiting them. Those people are the type who are going to be attracted to the possibility of using more from the ZCA world and are not going to mind a bit of extra boilerplate to have a truly flexible system with greater code reuse potential in the long run. my two cents from a recent Pylons and ZCA convert! Iain --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
