Mercurial Mercurial > pub > hg > cubicweb / changeset
summary | shortlog | changelog | graph | tags | bookmarks | branches | files | changeset | raw | zip | gz | bz2 | help
Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
[doc] uses :file:`name` everywhere + indicate file when it's not present 3.26
authorLaurent Peuch <cortex@worlddomination.be>
Tue, 26 Feb 2019 16:25:27 +0100
branch3.26
changeset 12472 4ae2b13017ef
parent 12471 0e0709fd4338
child 12473 4042795875b9
[doc] uses :file:`name` everywhere + indicate file when it's not present
doc/tutorials/advanced/part04_ui-base.rst file | annotate | diff | comparison | revisions
doc/tutorials/advanced/part05_ui-advanced.rst file | annotate | diff | comparison | revisions 
--- a/doc/tutorials/advanced/part04_ui-base.rst	Tue Feb 26 16:23:37 2019 +0100
+++ b/doc/tutorials/advanced/part04_ui-base.rst	Tue Feb 26 16:25:27 2019 +0100
@@ -169,7 +169,7 @@
 
 To fix this, we've to help the ORM. We'll do this in the method from the `ITree`
 folder's adapter, used in the folder's primary view to display the folder's
-content. Here's the code, that I've put in our cube's `entities.py` file, since
+content. Here's the code, that I've put in our cube's :file:`entities.py` file, since
 it's more logical stuff than view stuff:
 
 .. sourcecode:: python
@@ -211,7 +211,7 @@
 to see the previous / next image in the same folder. CubicWeb's provide a
 component that do exactly that. To make it appears, one have to be adaptable to
 the `IPrevNext` interface. Here is the related code sample, extracted from our
-cube's `views.py` file:
+cube's :file:`views.py` file:
 
 .. sourcecode:: python
 
@@ -338,7 +338,7 @@
 
 
 Once I've checked it's ok, I simply have to bump the version number in the
-`__pkginfo__` module to trigger a migration once I'll have updated the code on
+:file:`__pkginfo__` module to trigger a migration once I'll have updated the code on
 the production site. I can check then check the migration is also going fine, by
 first restoring a dump from the production site, then upgrading my test instance.
 
@@ -348,7 +348,7 @@
   pg_dump -Fc --username=syt --no-owner --file /home/syt/etc/cubicweb.d/sytweb/backup/tmpYIN0YI/system sytweb
   -> backup file /home/syt/etc/cubicweb.d/sytweb/backup/sytweb-2010-07-13_10-22-40.tar.gz
 
-I can now get back the dump file ('sytweb-2010-07-13_10-22-40.tar.gz') to my test
+I can now get back the dump file (:file:`sytweb-2010-07-13_10-22-40.tar.gz`) to my test
 machine (using `scp` for instance) to restore it and start migration: ::
 
   $ cubicweb-ctl db-restore sytweb sytweb-2010-07-13_10-22-40.tar.gz
--- a/doc/tutorials/advanced/part05_ui-advanced.rst	Tue Feb 26 16:23:37 2019 +0100
+++ b/doc/tutorials/advanced/part05_ui-advanced.rst	Tue Feb 26 16:25:27 2019 +0100
@@ -55,7 +55,7 @@
 :mod:`cubiweb.web.views.basetemplates` module, since I know that global page
 layouts sits there. I could also have grep the "body" tag in
 :mod:`cubicweb.web.views`... Finding this was the hardest part. Now all I need is
-to customize it to write that ``img`` tag, as below:
+to customize it to write that ``img`` tag, as below in :file:`views.py`:
 
 .. sourcecode:: python
 
@@ -175,7 +175,7 @@
 .. image:: ../../images/tutos-photowebsite_grey-box.png
 
 This is because CubicWeb's CSS include some variables which are
-expanded by values defined in uiprops file. In our case we controlled the
+expanded by values defined in :file:`uiprops.py` file. In our case we controlled the
 properties of the CSS `background` property of boxes with CSS class
 `contextualBoxTitleBg` and `incontextBoxTitleBg`.
cubicweb