Hello !
\n \n \n\nThis will greet a logged in user with his or her actual name.\n\nSuch a template-using page is a subclass of ``grokcore.view.View``::\n\n import grokcore.view\n import zope.interface\n\n class Hello(grokcore.view.View):\n grokcore.view.context(zope.interface.Interface)\n\n\nTo associate the template with the view, we have to put it in a\ncertain place. Let's say the ``Hello`` view class from above was in\nan ``app.py`` module. Then we create an ``app_templates`` directory\nnext to it and place the template file in there (the name of this\ndirectory can be customized with the ``templatedir`` directive, see\nbelow). The file name can be anything as long as the extension is\n``.pt``. However, we can again make use of a convention here. If we\nname the template like the class (except in lower case characters),\nthen the template and the class are associated automatically. If not,\nwe would have to use the ``template`` directive on the view class to\nspell out the name of the template file explicitly.\n\nTo cut a long story short, if we named it ``app_templates/hello.pt``,\nit would be found automatically.\n\nStatic resources\n----------------\n\nBrowser pages often need additional static resources like CSS and JavaScript\nfiles. These can be conveniently placed into a directory called ``static`` in\nthe package that contains the view code. When this directory exists it will\nautomatically be registered as a resource directory. It then is available as\nthe ``static`` variable in all views of this package and you can refer to files\ninside this directory like so::\n\n![](\"hello.png\")
\n\nDirectoryResource\n-----------------\n\nIn addition to the very convenient \"static resources\", one can use more\nexplicitly configured and flexible DirectoryResource components.\nDirectoryResource component allow for differentiating resources based on layers\nand names and provide a way to register resources in one package and make use\nof these resources in another package's views::\n\n class FooResource(grokcore.view.DirectoryResource):\n grokcore.view.path('foo')\n\nOr with an explicit name::\n\n class BarResource(grokcore.view.DirectoryResource):\n grokcore.view.name('bar')\n grokcore.view.path('bar')\n\nRegistered for a layer::\n\n class BazResource(grokcore.view.DirectoryResource):\n grokcore.view.layer(ISomeLayer)\n grokcore.view.path('baz/qux')\n\nLayers and skins\n----------------\n\nTo define a browser layer, simply extend the ``IBrowserRequest``\ninterface::\n\n class IGreenLayer(grokcore.view.IBrowserRequest):\n pass\n\nIf you then wanted to define a skin, simply inherit from all the layer\ninterfaces that should be in the skin and use the ``skin()`` directive\nto give the layer a name::\n\n class IGreenSkin(IGreenLayer, grokcore.view.IDefaultBrowserLayer):\n grokcore.view.skin('Green')\n\nTo place a view on a layer, simply use the ``layer`` directive::\n\n class Hello(grokcore.view.View):\n grokcore.view.context(zope.interface.Interface)\n grokcore.view.layer(IGreenLayer)\n\n ...\n\n\nAPI overview\n============\n\nBase classes\n------------\n\n``View``\n Base class for browser pages. Use the ``context`` directive to\n specify the view's context. Use the ``name`` directive to set the\n view's name; if not used, the view's name will be the class's name\n in lower case characters. You may also use the ``template``\n directive to specify the name of the template file that should be\n associated with the view as well as the ``layer`` directive to\n specify which layer it should be on if not the default layer.\n Implement the ``render`` method to forgo looking up a template\n and show the result of calling the render method instead.\n\nView API\n--------\n\n``grokcore.view.View`` is a regular Zope browser page, so it behaves\nexactly like a regular browser page from the outside. It provides a\nbit more to the developer using it as a base class, though:\n\n``context``\n The view's context object. This can be discriminated by using the\n ``context`` directive on the view class.\n\n``request``\n The request object, typically provides ``IBrowserRequest``.\n\n``response``\n The response object, typically provides ``IHTTPResponse``.\n\n``static``\n Directory resource representing the package's ``static`` directory or None\n if no such directory was found during grokking.\n\n``redirect(url)``\n Redirect to the given URL.\n\n``url(obj=None, name=None, data=None)``\n Constructs a URL:\n\n * If no arguments are given, the URL to the view itself is\n constructed.\n\n * If only the ``obj`` argument is given, the URL to that object is\n constructed.\n\n * If both ``obj`` and ``name`` arguments are supplied, construct\n the URL to the object and append ``name`` (presumably the name\n of a view).\n\n Optionally, ``data`` can be a dictionary whose contents is added to\n the URL as a query string.\n\nMethod for developers to implement:\n\n``update(**kw)``\n This method will be called before the view's associated template\n is rendered. If you therefore want to pre-compuate values for the\n template, implement this method. You can save the values on\n ``self`` (the view object) and later access them through the\n ``view`` variable from the template. The method can take\n arbitrary keyword parameters which are filled from request values.\n\n``render(**kw)`` \n Return either an encoded 8-bit string or a unicode string. The method can\n take arbitrary keyword parameters which are filled from request values.\n If not implemented, a template is looked up in the template dir instead.\n\n\nDirectives\n----------\n\n``templatedir(dirname)``\n Module-level directive that tells the template machinery which\n directory to look in for templates that should associated with\n views in a particular module. If not used, it defaults to\n ``hello
')\n\n This isn't exactly *officially* supported but enough people depend\n on it and have documented it so that we don't want to just break it.\n\n1.11 (2009-09-15)\n-----------------\n\n- The response attribute needs to be available in CodeView as well.\n\n1.10 (2009-09-14)\n-----------------\n\n- Up the version requirement for grokcore.security to 1.2.\n\n- Bring versions.cfg in line with current grok versions.cfg.\n\n\n1.9 (2009-07-04)\n----------------\n\n- Fix needed for grokcore.formlib: allow a base_method'ed render() on view.\n This allows grokcore.formlib to have a render() in addition to a template.\n\n- Reverted change to checkTemplates: for some formlib edge cases it detects\n the right templates again.\n\n\n1.8 (2009-07-04)\n----------------\n\n- Add validator to templatedir directive to disallow path separator.\n\n- Splitted CodeView out of View. View only uses templates, CodeView only uses\n a render() method. So views that have a render method must subclass from\n CodeView instead of View (that should be the only change needed).\n\n- Add grok.View permissions to functional tests (requires grokcore.security 1.1)\n\n\n1.7 (2009-05-19)\n----------------\n\n- Revert dependency from zope.container back to zope.app.container.\n\n\n1.6 (2009-04-28)\n----------------\n\n- Simplify the DirectoryResource and DirectoryResourceFactory\n implementations by making better use of the hook points provided by\n zope.app.publisher.browser.directoryresource.\n\n1.5 (2009-04-10)\n----------------\n\n- Don't register a 'static' resource directory if the 'static' directory does\n not exist.\n\n- Make it possible to instantiate an ungrokked view by being slightly more\n defensive in __init__. This makes it easier to write unit tests.\n\n1.4 (2009-04-08)\n----------------\n\n* Page template reloading now also works for macros. Fixes\n https://bugs.launchpad.net/grok/+bug/162261.\n\n* Use zope.container instead of zope.app.container.\n\n* Ignore '