# myapp/views/accounts.py
class AccountView(object):
def __init__(self, request):
self.request = request
def hello(self):
...
# myapp/views/__init__.py
def includeme(config):
import myapp.views.accounts
config.add_view(myapp.views.accounts.AccountView,
attr="hello", route_name="home")
# myapp/routes.py
def includeme(config):
config.add_route("hello", "/hello")
# myapp/__init__.py
def main(settings):
import myapp.routes
import myapp.views
...
config.include(myapp.routes)
config.include(myapp.views)
You can of course use absolute or relative imports, or string names.
config.add_view("myapp.views.accounts.AccountView", ...)
The imports are in functions to avoid complications when an init
module imports its own child. (If the import is at global level, the
bottom of the init module won't have executed yet, and if the child
also imports its parent, it creates a circular import, where the
bottom of the child's module isn't executed yet either, so any globals
below that point don't exist yet and can't be depended on).
On Fri, Nov 13, 2015 at 4:35 AM, kk <[email protected]> wrote:
>
>
> Thanks Mike for the clarification,
> So let's say I have a project and under it I create a folder called views/
> Now in the __init__.py file I must have the includeme function, is that
> correct?
> I am going to have a lot of modules in the views folder, so I thought this
> makes sence.
> If this is correct, then in my main project package I will have the
> routes.py is what I feel.
> I just don't understand if the views package must be imported somewhere or
> is it insignificant, given that routes.py has all the routes to any module?
> Let's say my views/ directory contains __init__.py, accounts.py and
> vouchers.py (the latter 2 being view classes )
> So I want to know where do I write the config.add_view function and and how
> routes will be associated with them?
> Could you make this clear with an example setup given my project views/
> package as I mentioned above?
> Of course i will have templates directory and all other things which a
> basic scaffold will provide.
> I think being explicit about the order and control over the imports sounds
> better to me than scann, although I might be wrong in my understanding.
> Happy hacking.
> Krishnakant,
> On Friday 13 November 2015 10:18 AM, Mike Orr wrote:
>>
>> With 'config.add_view', you write the method calls yourself, so it's
>> clear in the code exactly which views are being activated when, and if
>> an exception occurs it points to that specific line.
>>
>> With 'config.scan', it lists the modules internally and imports them
>> using a kind of hack, and you have to trust that the scanner will find
>> all the declarations and correctly add them, or else you have to trace
>> why it didn't. It also imports every module it scans, which can have
>> side effects if the module contains global initialization code. When
>> you import a module, you know exactly when it will be imported. When
>> scan imports a module, it just happens sometime during the scan. I
>> don't want to make a big deal out of it. 'config.scan' works; a lot of
>> people use it.
>>
>> You put the calls in your main function, or in something that your
>> main function calls or includes. If you have a pageful of routes and a
>> lot of views, you might have a routes.py and a views/__init__.py . My
>> current application has a lot of configuration (authorization,
>> sessions, custom Request methods, etc), so I put the miscellaneous
>> configuration modules in appname/app/, so I have
>> appname/app//routes.py and appname/app/views.py (separate from the
>> appname/views/ package where the views themselves are). You can put
>> the views in a regular function with a 'config' argument, or put them
>> in an 'includeme(config)' function and use
>> 'config.include(the_module)' -- they both do the same thing.
>>
>>
>> On Wed, Nov 11, 2015 at 12:35 PM, kk <[email protected]> wrote:
>>>
>>>
>>> Hi Mike,
>>> How is config.add_view less magical?
>>> And which is actually the place to write add_view?
>>> Do i put this decorator just above the view function just like
>>> view_config is put?
>>> Is the only difference in using or not using the scann command?
>>> Happy hacking.
>>> Krishnakant.
>>> On Thursday 12 November 2015 01:57 AM, Mike Orr wrote:
>>>>
>>>> On Wed, Nov 11, 2015 at 1:26 AM, Krishnakant Mane <[email protected]>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Monday, November 9, 2015 at 11:24:19 PM UTC+5:30, Jonathan Vanasco
>>>>> wrote:
>>>>>>
>>>>>> You can have views in multiple files, and even different packages.
>>>>>>
>>>>>> `views.py` is just a "scaffold" or reference implementation.
>>>>>>
>>>>>> IIRC, Pyramid will automatically scan either `views.py` or a `views/`
>>>>>> package directory and subdirectories by default. (ie, everything with
>>>>>> an
>>>>>> `__init__.py`)
>>>>>>
>>>>>> If you want to scan other packages/directories, you can even use
>>>>>> dotted
>>>>>> notation to explicitly scan them as well:
>>>>>>
>>>>>> config.scan("myapp.views_a")
>>>>>
>>>>> So should I do config.scann for the views package?
>>>>> Or is it that Pyramid will automatically see my package name?
>>>>> I am still confused how Pyramid will automatically know which files
>>>>> contain
>>>>> my view code?
>>>>
>>>> It doesn't automatically know. There are two ways to register views:
>>>>
>>>> 1) Use 'config.add_view()' for every view.
>>>>
>>>> 2) Decorate the views with '@view_config' and then run 'config.scan()'
>>>> over the module or package. The scanning does the add_view's for you.
>>>> You can specify which package to scan, and it will scan all modules
>>>> and subpackages under it.
>>>>
>>>> Some people prefer one way, and some the other. I used to use
>>>> '@view_config' but I'm currently using 'config.add_view()' because
>>>> it's less magical.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "pylons-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/pylons-discuss.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
