On 3/20/11 16:12 PM, Wichert Akkerman wrote:
Both Grok and Pyramid (or martian and venusian really) do a scan of the code to find the registration hints.
Pyramid only does so if you tell it to do so by using config.scan(). You are not obliged to do that, and I have several pyramid projects which do not do any scanning. Not doing scanning has the advantage of making configuration more explicit, and it speeds application startup immensely.
Just to get this clear for me: if you're not scanning, the information left by the class decorators would be "inert"? So, you'd have to do the registrations "yourself", right?
Let me try to argue this better. Downsides of scanning are:
- it scans your tests, which can result in unexpected behaviour you may not expect (at least for venusian, not sure if this is true for martian).
Martian skips tests by default. You can tell it, at least to a certain extend, what to scan and what not to scan.
- you may have some draft files in your tree that are not ready for use and never referenced anywhere, but a scan will still process them.
This is true.
- scanning can take a long time, making application (re)start slow for non-trivial projects
At what point is an application not trivial anymore? In applications I build so far, startup time has not been an issue at all. But maybe my applications are still on the trivial-end of the spectrum ;)
- problems in the scanning process tend to be very hard debug. If a view is not processed during scanning figuring out why can be painful, and there are little to no tools to help you. This is especially true for more complex scanning environments such as the plone/dexterity/z3cform stack; as an example I spent over an hour yesterday trying to figure out why a form was not picked up while other views in the same python file worked fine.
I think this can be true. In my experience not relying on implicitly or "guessed configuration parameters helps a little here. What in this specific example was the reason for the view not being picked up? regards, jw