WuttaWeb 0.10.1__tar.gz → 0.11.0__tar.gz

{wuttaweb-0.10.1 → wuttaweb-0.11.0}/CHANGELOG.md

@@ -5,6 +5,20 @@ All notable changes to wuttaweb will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
 and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
 
+## v0.11.0 (2024-08-20)
+
+### Feat
+
+- split up base templates into more sections (def blocks)
+- simplify base/page/form template structure; add docs
+
+## v0.10.2 (2024-08-19)
+
+### Fix
+
+- add `render_vue_finalize()` methods for grids, forms
+- avoid error when checking model for column property
+
 ## v0.10.1 (2024-08-19)
 
 ### Fix

{wuttaweb-0.10.1 → wuttaweb-0.11.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: WuttaWeb
-Version: 0.10.1
+Version: 0.11.0
 Summary: Web App for Wutta Framework
 Project-URL: Homepage, https://wuttaproject.org/
 Project-URL: Repository, https://forgejo.wuttaproject.org/wutta/wuttaweb

wuttaweb-0.11.0/docs/narr/index.rst

@@ -0,0 +1,8 @@
+
+Documentation
+=============
+
+.. toctree::
+   :maxdepth: 2
+
+   templates/index

wuttaweb-0.11.0/docs/narr/templates/base.rst

@@ -0,0 +1,251 @@
+
+Base Templates
+==============
+
+This describes the base templates.  When creating a custom page
+template, you most often need to inherit from one of these:
+
+* :ref:`page_base_template`
+* :ref:`form_base_template`
+* :ref:`master_base_templates`
+
+.. note::
+
+   Any of these templates may be overridden; see
+   :ref:`mako-template-override`.
+
+
+Global Base
+~~~~~~~~~~~
+
+There is exactly one "true base template" for the web app, designated
+as: ``/base.mako``
+
+The default base template is ``wuttaweb:templates/base.mako`` and all
+page templates inherit from it.  However they inherit it by *name*
+only (``/base.mako``) - therefore if you override this via custom
+template search paths, effectively you have changed the **theme**.
+
+In addition to general layout/structure, this template is reponsible
+for creating the Vue app which encompasses the whole of every page.
+It also establishes the ``WholePage`` component which is the Vue app's
+one and only child component.
+
+(``WholePage`` in turn will have other children, for page content.)
+
+There is usually no need to define a template which inherits directly
+from ``/base.mako``, rather you should inherit from ``/page.mako``
+(see next section) or similar.
+
+As pertains to Vue component logic, there are 3 blocks which you may
+find a need to override.  These are defined by ``/base.mako`` so will
+apply to *all* templates:
+
+* ``render_vue_templates()``
+* ``modify_vue_vars()``
+* ``make_vue_components()``
+
+Most often it is necessary to customize ``modify_vue_vars()`` but keep
+reading for an example.
+
+
+.. _page_base_template:
+
+Page Base
+~~~~~~~~~
+
+The common base template for pages, designated as: ``/page.mako``
+
+This extends the Vue logic from ``/base.mako`` by establishing
+``ThisPage`` component, which wraps all content within the current
+page.
+
+The final structure then is conceptually like:
+
+.. code-block:: html
+
+   <div id="app">
+     <whole-page>
+       <!-- menu etc. -->
+       <this-page>
+         <!-- page contents -->
+       </this-page>
+     </whole-page>
+   </div>
+
+Simple usage is to create a template which inherits from
+``/page.mako`` and defines a ``page_content()`` block, e.g.:
+
+.. code-block:: mako
+
+   <%inherit file="/page.mako" />
+
+   <%def name="page_content()">
+     <p>hello world!</p>
+   </%def>
+
+The default ``/page.mako`` logic knows where to render the
+``page_content()`` block so that it fits properly into the
+component/layout structure.
+
+Often you may need to customize Vue component logic for a page; this
+is done by defining one of the blocks mentioned in previous section.
+
+Here is a simple example which shows how this works:
+
+.. code-block:: mako
+
+   <%inherit file="/page.mako" />
+
+   <%def name="page_content()">
+     <b-field label="Foo">
+       <b-input v-model="foo" />
+     </b-field>
+     <b-field>
+     <b-button @click="alertFoo()">
+       Alert
+     </b-button>
+     </b-field>
+   </%def>
+
+   <%def name="modify_vue_vars()">
+     ${parent.modify_vue_vars()}
+     <script>
+
+       // nb. this becomes ThisPage.data.foo
+       ThisPageData.foo = 'bar'
+
+       ThisPage.methods.alertFoo = function() {
+           alert("value of foo is: " + this.foo)
+       }
+
+     </script>
+   </%def>
+
+You can see that ``page_content()`` is able to reference things from
+``ThisPage`` component, while the ``modify_vue_vars()`` block is used
+to define those same things on the component.
+
+
+.. _form_base_template:
+
+Form Base
+~~~~~~~~~
+
+The common base template for pages with a form, designated as:
+``/form.mako``
+
+This expects the context dict to contain ``'form'`` which points to a
+:class:`~wuttaweb.forms.base.Form` instance.
+
+This template extends the Vue logic from ``/page.mako`` by
+establishing a Vue component specific to the form object.
+
+The final structure then is conceptually like:
+
+.. code-block:: html
+
+   <div id="app">
+     <whole-page>
+       <!-- menu etc. -->
+       <this-page>
+         <wutta-form>
+           <!-- fields etc. -->
+         </wutta-form>
+       </this-page>
+     </whole-page>
+   </div>
+
+A simple example which assumes one of the form fields exposes a button
+with click event that triggers ``alertFoo()`` method on the form
+component:
+
+.. code-block:: mako
+
+   <%inherit file="/form.mako" />
+
+   <%def name="modify_vue_vars()">
+     ${parent.modify_vue_vars()}
+     <script>
+
+       // nb. this becomes e.g. WuttaForm.foo when component is created
+       ${form.vue_component}Data.foo = 'bar'
+
+       ${form.vue_component}.methods.alertFoo = function() {
+           alert("value of foo is: " + this.foo)
+       }
+
+     </script>
+   </%def>
+
+.. note::
+
+   By default, ``${form.vue_compoment}`` is rendered as ``WuttaForm``
+   but that is not guaranteed.  You should resist the temptation to
+   hard-code that; always use ``${form.vue_component}`` and (where
+   applicable) ``${form.vue_tagname}``.
+
+   The reason for this is to allow multiple forms to exist on a single
+   page, each with a separate Vue component.  (Which is not shown in
+   the above example.)
+
+   See also :attr:`~wuttaweb.forms.base.Form.vue_component` and
+   :attr:`~wuttaweb.forms.base.Form.vue_tagname`.
+
+
+.. _master_base_templates:
+
+Master Base
+~~~~~~~~~~~
+
+These templates are for use with
+:class:`~wuttaweb.views.master.MasterView`.  Each is the default
+template used for the corresponding route/view, unless a more specific
+template is defined.
+
+The "index" template is unique in that it is (usually) for listing the
+model data:
+
+* ``/master/index.mako``
+
+The "form" template is just a base template, does not directly
+correspond to a route/view.  Other CRUD templates inherit from it.
+This inherits from ``/form.mako`` (see previous section).
+
+* ``/master/form.mako``
+
+These CRUD templates inherit from ``/master/form.mako`` and so
+require a ``'form'`` in the context dict.
+
+* ``/master/create.mako``
+* ``/master/view.mako``
+* ``/master/edit.mako``
+* ``/master/delete.mako``
+
+The "configure" template is for master views which have a
+configuration page.
+
+* ``/master/configure.mako``
+
+Usage for these is not significantly different from the ones shown
+above, in cases where you actually need to override the template.
+
+As an example let's say you have defined a ``WidgetMasterView`` class
+and want to override its "view" template.  You would then create a
+file as ``/widgets/view.mako`` (within your templates folder) and
+be sure to inherit from the correct base template:
+
+.. code-block:: mako
+
+   <%inherit file="/master/view.mako" />
+
+   <%def name="page_content()">
+
+     <p>THIS APPEARS FIRST!</p>
+
+     ## nb. the form will appear here
+     ${parent.page_content()}
+
+     <p>MADE IT TO THE END!</p>
+
+   </%def>

wuttaweb-0.11.0/docs/narr/templates/index.rst

@@ -0,0 +1,10 @@
+
+Templates
+=========
+
+.. toctree::
+   :maxdepth: 2
+
+   overview
+   base
+   lookup

wuttaweb-0.11.0/docs/narr/templates/lookup.rst

@@ -0,0 +1,69 @@
+
+Template Lookup
+===============
+
+The discovery of templates is handled by Mako, and is configurable.
+
+WuttaWeb comes with all templates it needs, in the path designated as
+``wuttaweb:templates``.
+
+When the app renders a page, it invokes the Mako lookup logic, which
+searches one or more folders and returns the first matching file it
+encounters.  By default ``wuttaweb:templates`` is the only place it
+looks.
+
+A template is searched for by "name" but it is more path-like, e.g.
+``/page.mako`` or ``/master/index.mako`` etc.  So for example the file
+at ``wuttaweb:templates/home.mako`` is used for home page (using
+lookup name ``/home.mako``) by default.
+
+
+.. _mako-template-override:
+
+Overriding the Search Paths
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The basic idea is to give it a list of paths it should search when
+trying to find a template.  The first template file found for a given
+search name is used and no further search is done for that name.
+
+You can define the Mako lookup sequence in your ``web.conf`` as
+follows:
+
+.. code-block:: ini
+
+   [app:main]
+   mako.directories =
+       /random/path/on/disk
+       poser.web:templates
+       wuttaweb:templates
+
+This setting is interpreted by ``pyramid_mako`` (`docs`_).
+
+.. _docs: https://docs.pylonsproject.org/projects/pyramid_mako/en/latest/index.html#mako-directories
+
+Here ``wuttaweb:templates/home.mako`` would still be used by default
+for home page, *unless* e.g. ``/random/path/on/disk/home.mako``
+existed in which case that would be used.
+
+Each path can have an arbitrary set of templates, they will
+effectively be combined to a single set by the app, with the
+definition order determining search priority.
+
+If you are already using a custom ``app.main()`` function for
+constructing the web app during startup, it may be a good idea to
+change the *default* search paths to include your package.
+
+Setup for custom ``app.main()`` is beyond the scope here, but assuming
+you *do* already have one, this is what it looks like::
+
+   from wuttaweb import app as base
+
+   def main(global_config, **settings):
+
+       # nb. set the *default* mako search paths; however config can
+       # still override with method shown above
+       settings.setdefault('mako.directories', ['poser.web:templates',
+                                                'wuttaweb:templates'])
+
+       return base.main(global_config, **settings)

wuttaweb-0.11.0/docs/narr/templates/overview.rst

@@ -0,0 +1,15 @@
+
+Overview
+========
+
+WuttaWeb uses the `Mako`_ template language for page rendering.
+
+.. _Mako: https://www.makotemplates.org/
+
+There is a "global" base template which effectively defines the
+"theme" (page layout, Vue component structure).  A few other base
+templates provide a starting point for any custom pages; see
+:doc:`base`.
+
+Templates are found via lookup which is handled by Mako.  This is
+configurable so you can override any or all; see :doc:`lookup`.

{wuttaweb-0.10.1 → wuttaweb-0.11.0}/pyproject.toml

@@ -6,7 +6,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "WuttaWeb"
-version = "0.10.1"
+version = "0.11.0"
 description = "Web App for Wutta Framework"
 readme = "README.md"
 authors = [{name = "Lance Edgar", email = "lance@edbob.org"}]

{wuttaweb-0.10.1 → wuttaweb-0.11.0}/src/wuttaweb/forms/base.py

@@ -918,19 +918,42 @@ class Form:
 
         return HTML.tag('b-field', c=[html], **attrs)
 
+    def render_vue_finalize(self):
+        """
+        Render the Vue "finalize" script for the form.
+
+        By default this simply returns:
+
+        .. code-block:: html
+
+           <script>
+             WuttaForm.data = function() { return WuttaFormData }
+             Vue.component('wutta-form', WuttaForm)
+           </script>
+
+        The actual output may depend on various form attributes, in
+        particular :attr:`vue_tagname`.
+        """
+        set_data = f"{self.vue_component}.data = function() {{ return {self.vue_component}Data }}"
+        make_component = f"Vue.component('{self.vue_tagname}', {self.vue_component})"
+        return HTML.tag('script', c=['\n',
+                                     HTML.literal(set_data),
+                                     '\n',
+                                     HTML.literal(make_component),
+                                     '\n'])
+
     def get_vue_model_data(self):
         """
         Returns a dict with form model data.  Values may be nested
         depending on the types of fields contained in the form.
 
-        Note that the values need not be "converted" (to be
-        JSON-compatible) at this stage, for instance ``colander.null``
-        is not a problem here.  The point is to collect the raw data.
+        This collects the ``cstruct`` values for all fields which are
+        present both in :attr:`fields` as well as the Deform schema.
 
-        The dict should have a key/value for each field in the form.
+        It also converts each as needed, to ensure it is
+        JSON-serializable.
 
-        This method is called by :meth:`render_vue_model_data()` which
-        is responsible for ensuring JSON compatibility.
+        :returns: Dict of field/value items.
         """
         dform = self.get_deform()
         model_data = {}

{wuttaweb-0.10.1 → wuttaweb-0.11.0}/src/wuttaweb/grids/base.py

@@ -578,7 +578,8 @@ class Grid:
                 if key in sorters:
                     continue
                 prop = getattr(self.model_class, key, None)
-                if prop and isinstance(prop.property, orm.ColumnProperty):
+                if (prop and hasattr(prop, 'property')
+                    and isinstance(prop.property, orm.ColumnProperty)):
                     sorters[prop.key] = self.make_sorter(prop)
 
         return sorters
@@ -1277,6 +1278,30 @@ class Grid:
         output = render(template, context)
         return HTML.literal(output)
 
+    def render_vue_finalize(self):
+        """
+        Render the Vue "finalize" script for the grid.
+
+        By default this simply returns:
+
+        .. code-block:: html
+
+           <script>
+             WuttaGrid.data = function() { return WuttaGridData }
+             Vue.component('wutta-grid', WuttaGrid)
+           </script>
+
+        The actual output may depend on various grid attributes, in
+        particular :attr:`vue_tagname`.
+        """
+        set_data = f"{self.vue_component}.data = function() {{ return {self.vue_component}Data }}"
+        make_component = f"Vue.component('{self.vue_tagname}', {self.vue_component})"
+        return HTML.tag('script', c=['\n',
+                                     HTML.literal(set_data),
+                                     '\n',
+                                     HTML.literal(make_component),
+                                     '\n'])
+
     def get_vue_columns(self):
         """
         Returns a list of Vue-compatible column definitions.

{wuttaweb-0.10.1 → wuttaweb-0.11.0}/src/wuttaweb/templates/appinfo/configure.mako

@@ -140,8 +140,8 @@
   </div>
 </%def>
 
-<%def name="modify_this_page_vars()">
-  ${parent.modify_this_page_vars()}
+<%def name="modify_vue_vars()">
+  ${parent.modify_vue_vars()}
   <script>
 
     ThisPageData.weblibs = ${json.dumps(weblibs or [])|n}

{wuttaweb-0.10.1 → wuttaweb-0.11.0}/src/wuttaweb/templates/appinfo/index.mako

@@ -48,8 +48,8 @@
 
 </%def>
 
-<%def name="modify_this_page_vars()">
-  ${parent.modify_this_page_vars()}
+<%def name="modify_vue_vars()">
+  ${parent.modify_vue_vars()}
   <script>
     ThisPageData.configFiles = ${json.dumps([dict(path=p, priority=i) for i, p in enumerate(config.get_prioritized_files(), 1)])|n}
   </script>

{wuttaweb-0.10.1 → wuttaweb-0.11.0}/src/wuttaweb/templates/auth/login.mako

@@ -19,7 +19,8 @@
   </div>
 </%def>
 
-<%def name="modify_this_page_vars()">
+<%def name="modify_vue_vars()">
+  ${parent.modify_vue_vars()}
   <script>
 
     ${form.vue_component}Data.usernameInput = null