j1-template 2021.0.4 → 2021.0.9

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/documents/100_meet_and_greet_jekyll.asciidoc

@@ -1,31 +0,0 @@
-
-*Web in a Day* is the first in a series of tutorials to learn how to
-create modern websites using Jekyll. This Kickstarter focuses on the basics
-of Jekyll and the J1 Template, which all people needs to know for a successful
-way to a modern static website using Jekyll and J1 Template.
-
-It is highly recommended to read and work on this tutorial by everyone -
-independently from what level of knowledge they begin. Jekyll is from classic
-Content Management Systems (CMS) like Joomla, WordPress or Drupal.
-No surprise: Jekyll and J1 are different as well.
-
-It sounds much, spending a whole day to get Jekyll to know - yes, it is much.
-You'll find a lot of Blog articles like *Jekyll in 15 minutes*. But what can
-be *learned* in 15 minutes?
-
-To be fair, most of these blogs are intended to help *installing Jekyll* and
-get the very first steps managed out of the box. If you run Jekyll out of the
-box, the resulting website (from the build-in theme scaffold) might somewhat
-frustrating. You'll get an elementary site created based on Jekyll's theme
-*minima*.
-
-To not waste time, get through the tutorial and find out what is the
-*Jekyll Way*. And if this the way you want to go.
-
-Have a good time, a good day learning Jekyll.
-
-
-== Meet and greet Jekyll
-
-lorem:sentences[5] +
-lorem:sentences[3] +

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/documents/200_preparations.asciidoc

@@ -1,14 +0,0 @@
-lorem:sentences[5]
-
-To not waste time, get through the turorial and find out what is the *Jekyll Way*.
-And if this the way you want to go.
-
-Have a good time, a good day learning Jekyll.
-
-== Preparations
-
-lorem:sentences[5] +
-lorem:sentences[3] +
-
-
-

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/documents/300_first_awesome_web.asciidoc

@@ -1,11 +0,0 @@
-lorem:sentences[5]
-
-To not waste time, get through the turorial and find out what is the *Jekyll Way*.
-And if this the way you want to go.
-
-Have a good time, a good day learning Jekyll.
-
-== First awesome website
-
-lorem:sentences[5] +
-lorem:sentences[3] +

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/parts.asciidoc

@@ -1,193 +0,0 @@
-// ~/document_base_folder/000_includes
-//  Asciidoc part includes:                 parts.asciidoc
-// -----------------------------------------------------------------------------
-
-
-// Summarize
-// -----------------------------------------------------------------------------
-//  tag::summarize[]
-//
-A lot you've learned, time to summarize what is in behind. The last chapter 
-*Summarize!* should help on that. Summarize! offer some handy sections to
-remember what was presented this chapter, giving an outlook what could be
-done next, an overview on all chapters this tutorial and finally useful
-links to read more.
-
-See all *sections* below: +
-mdi:backup-restore[24px, md-grey ml-3]
-<<Recap>> -- What has been done, what's *explored in current section* +
-mdi:skip-next[24px, md-grey ml-3]
-<<Whats Next>> -- Find to go further, what's *planned next* +
-mdi:format-section[24px, md-grey ml-3]
-<<All Chapters>> -- The full chain, *all chapters* +
-// mdi:book-open[24px, md-grey ml-3]
-// <<Further Reading>> -- List of helpful links to *get more* +
-
-//
-//  end::summarize[]
-
-// End Summarize ---------------------------------------------------------------
-
-
-// Recap
-// -----------------------------------------------------------------------------
-//  tag::recap_100_meet_and_greet_jekyll[]
-//
-To manage controlled page access, a web is transformed into an application.
-Additional software is needed for that: the J1 *AuthManager*. Build on the 
-_Ruby_ software framework _Rack_.
-
-A middleware system based on Rack is not a *monolithic* block. It is a *stack*
-of *multiple* middleware components -- what the name *Rack* implies. What is 
-called *Middlewares* is the next great magic: _Ruby_ libraries (Gem)
-managing a *specific* job as *service* in such a *chain*.
-
-For now folks, keep in mind a *Jekyll Site* can be transformed into an 
-*Web Application* as a additional *mode* using *Rack*. Rack provides the 
-*magic* in the middle to add additional dynamic processes provided by
-J1 AuthManager: *Services*.
-//
-//  end::recap_100_meet_and_greet_jekyll[]
-
-//  tag::recap_200_preparations[]
-//
-Running a web as an app is not that hard, isn't it? The magic is under the 
-hood - the middlewares used by J1 AuthManager.
-
-lorem:sentences[5] +
-lorem:sentences[3] +
-
-Find here is a list of the basic Chocolatey commands used this section. 
-And some more related ones. If you'd like to explore the Chocolatey CLI a bit 
-*more*, give it a try before moving on.
-
-[cols="8a,4", options="header", role="rtable, full-width"]
-|===============================================================================
-|Command |Description
-
-|
-[source, bash]
-----
-docker build -t first-app .
-----
-|Create the `image` *friendlyname* using this directory's Dockerfile
-
-|
-[source, bash]
-----
-docker run -p 4000:80 first-app
-----
-|Run `container` *friendlyname* with a mapping of port 4000 to 80
-
-|
-[source, bash]
-----
-docker run -d -p 4000:80 first-app
-----
-|Run container *friendlyname* with mapping, but in `detached mode`
-
-|===============================================================================
-//
-//  end::recap_200_preparations[]
-
-//  tag::recap_300_first_awesome_web[]
-//
-OAuth2 is an authentication framework, a protocol suite that enables 
-applications to obtain (limited) access to user account data hosted at 
-service providers.
-
-The protocol suite introduces four roles, discussed in section <<OAuth Roles>>,
-that interacts each other in a sequence, a *flow*. In section <<Base OAuth Flow>>
-the sequence was discussed in more detail.
-
-// ifdef::backend-html5[]
-// .High Level OAuth Protocol Flow
-// lightbox::oauth-abstract-protocol-flow[ 800, {data-oauth-abstract-protocol-flow} ]
-// endif::[]
-
-Keep in mind the *roles* and the fact, the OAuth framework introduce a sequence,
-a *flow*. All this is theory - yes for sure, but good to know.
-//
-//  end::recap_300_first_awesome_web[]
-
-// End Recap -------------------------------------------------------------------
-
-
-// Whats Next
-// -----------------------------------------------------------------------------
-//  tag::whats_next_100_meet_and_greet_jekyll[]
-//
-Well done, folks. You learned all the basics, started an transformed web as
-an app. And you've seen what is basicly going on under the hood. Now, you're
-well prepared for going further, to have a more inside view.
-
-For the next, a bit more knowledge, some theory is needed what *service providers*
-are and how *authentication* works. You need to know what is *OAuth*, what
-is *authentication* using the OAuth *framework*.
-
-Welcome to the world of *OAuth2*, a leading technology for authentication, 
-for creating relationships (associations) across different providers for
-your new amazing site, for your new project.
-
-mdi:skip-next[24px, md-grey]
-Go for link:{j1-web-in-a-day-preparations}[Preparations] then!
-//
-//  end::whats_next_100_meet_and_greet_jekyll[]
-
-//  tag::whats_next_200_preparations[]
-//
-After some practise and theory, you got a picture of what the OAuth 
-framework is, a base understanding about the flow - what will happen. Now 
-it's the time to see in real world what was discsused sofar.
-
-The following chapter is focussing a web that is *protected*. The app is not
-longer passing all the content pages. The content will be under *control*.
-
-// mdi:skip-next[24px, md-grey] 
-// To make protected *J1 Webs* real, continue on link:{j1-web-apps-run-an-secured-app}[Run an Secured J1 App]
-// then!
-
-//
-//  end::whats_next_200_preparations[]
-
-//  tag::whats_next_300_first_awesome_web[]
-//
-After some practise and theory, you got a picture of what the OAuth 
-framework is, a base understanding about the flow - what will happen. Now 
-it's the time to see in real world what was discsused sofar.
-
-The following chapter is focussing a web that is *protected*. The app is not
-longer passing all the content pages. The content will be under *control*.
-
-// mdi:skip-next[24px, md-grey] 
-// To make protected *J1 Webs* real, continue on link:{j1-web-apps-run-an-secured-app}[Run an Secured J1 App]
-// then!
-
-//
-//  end::whats_next_300_first_awesome_web[]
-
-// End Whats Next --------------------------------------------------------------
-
-
-// Chapters
-// -----------------------------------------------------------------------------
-//  tag::chapters[]
-//
-Find here an overview on *all* chapters this tutorial. +
-//
-//  end::chapters[]
-
-//  tag::chapters_100_meet_and_greet_jekyll[]
-//
-mdi:format-section[24px, md-grey ml-3]
-link:#[You are here -- Meet & Greet Jekyll] +
-mdi:format-section[24px, md-indigo ml-3]
-link:{j1-web-in-a-day-preparations}[Preparations] +
-mdi:format-section[24px, md-indigo ml-3]
-link:{j1-web-in-a-day-first-awesome-web}[A first awesome Web]
-//
-//  end::chapters_100_meet_and_greet_jekyll[]
-
-
-// End Chapters ----------------------------------------------------------------
-

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/tables/debug_variables.asciidoc

@@ -1,47 +0,0 @@
-ifeval::["{debug}" == "true"]
-.Liquid variables
-[cols="2,4,6a, options="header", role="table-responsive, full-width"]
-|===============================================================================
-|name |value |description
-
-|`page.path`
-|{{ page.path }}
-|The path to the raw post or page. Example usage: Linking back to the page
-or post's source on GitHub. This can be overridden in the `YAML Front Matter`.
-
-|`site.collections_dir`
-|{{ site.collections_dir }}
-|lorem:sentences[1]
-
-|`page.images.dir`
-|{{ page.images.dir }}
-|Image path set pagewise. See FRONTMATTER defaults in `_config.yml` for the
-images path specified by: `images.dir` for specific page *type*. See the
-example below for a page of type *pages*.
-[source, yaml]
-----
-defaults:
-  - scope:
-      path:          pages
-      type:          pages
-
-    values:
-      images:
-        dir:        /assets/images/pages
-----
-
-|`page-imagesdir`
-|{{ page-imagesdir }}
-| Images path set in the page by `:page-imagesdir:`.
-
-|`template`
-|{{ site.template.name }}
-|Name of the template used for rendering a page. Settings are taken from
-sitewide configuration defined by `_config.yml`.
-
-|`includedir`
-|{{ includedir }}
-|lorem:sentences[1]
-
-|===============================================================================
-endif::[]

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/tables/readme

@@ -1 +0,0 @@
-bla

data/lib/starter_web/pages/public/learn/roundtrip/600_lunr.adoc

@@ -1,335 +0,0 @@
----
-title:                                  Lunr
-tagline:                                full index search
-date:                                   2020-11-08 12:00:00
-description: >
-                                        The search engine Lunr is fully integrated with
-                                        J1 Template. Designed to be small, yet full featured,
-                                        to provide a great search experience without the
-                                        need for external, server-side, search services.
-
-tags:                                   [ Roundtrip, Introduction ]
-categories:                             [ Search ]
-
-toc:                                    true
-scrollbar:                              false
-
-permalink:                              /pages/public/learn/roundtrip/lunr/
-regenerate:                             true
-
-resources:                              [ lunr, rouge ]
-resource_options:
-  - attic:
-      padding_top:                      400
-      padding_bottom:                   50
-      opacity:                          0.5
-      slides:
-        - url:                          /assets/images/modules/attics/banner/lunr-banner-1280x800.jpg
-          alt:                          Lunr
----
-
-// Page Initializer
-// =============================================================================
-// Enable the Liquid Preprocessor
-:page-liquid:
-
-// Set page (local) attributes here
-// -----------------------------------------------------------------------------
-// :page--attr:                         <attr-value>
-
-//  Load Liquid procedures
-// -----------------------------------------------------------------------------
-{% capture load_attributes %}themes/{{site.template.name}}/procedures/global/attributes_loader.proc{%endcapture%}
-
-// Load page attributes
-// -----------------------------------------------------------------------------
-{% include {{load_attributes}} scope="all" %}
-
-
-// Page content
-// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The search engine Lunr is fully integrated with J1 Template. Designed to be
-small, yet full featured, to provide a great search experience without the
-need for external, server-side search services.
-
-Searching a website using Lunr a different in compare to search engines
-like Google or Microsoft Bing. These search platforms using complex algorithm
-to provide a simple interface to the public using a lot of artificial
-intelligence (AI) methods to make senseful results out of a handfull words
-given for a search.
-
-Nevertheless, a QuickSearch, the J1 implementation of Lunr, is simple like
-searching at Google, but offers additional features to do searches more
-specific. QuickSearch provides a easy to use query language for better results.
-
-== Core concepts
-
-Understanding some of the concepts and terminology that QuickSearch (based on
-Lunr) uses will allow you to provide powerful search functionality to get more
-relevant search results.
-
-=== Indexing documnents
-
-QuickSearch, the J1 implementation of Lunr, offers searches on *all* documents
-of website generated by J1, but only for this site. No internet access is done,
-or needed. Searches are based on a pre-build *local index* generated by the
-Jekyll plugin `lunr_index.rb` located in the `_plugins` folder.
-
-The index is generated at build-time:
-
-.Index creation at buildtime
-----
-Startup the site ..
-Configuration file: ...
-
- Incremental build: enabled
-      Generating...
-     J1 LunrSearch: creating search index ...
-     J1 LunrSearch: finished, index ready.
-     ....
-----
-
-Or, if you're running a website in development mode, the index gets refreshed
-for all files added or modified.
-
-.Index creation if files added, or modified
-----
-site:       Regenerating: n file(s) changed at ...
-site:       ...
-site:      J1 LunrSearch: creating search index ...
-site:      J1 LunrSearch: finished, index ready.
-           ...
-----
-
-=== Documents
-
-The searchable data in an index is organized as documents that contains the
-text that you want to be able to search. A document is a JSON object with one
-or more fields and an identifier that is returned in the results from a search.
-A document representing an article might look like this:
-
-[ source, json ]
-----
-{
-  "id": 0,
-  "title": "Web in a Day",
-  "tagline": "meet & greet jekyll",
-  "url": "/pages/public/learn/kickstarter/web_in_a_day/meet_and_greet/",
-  "date": "2018-05-01 00:00:00 +0000",
-  "tags": [
-    "Introduction"
-  ],
-  "categories": [
-    "Jekyll",
-    "Knowledge",
-    "Tutorial"
-  ],
-  "description": "Web in a Day is the first in a series of tutorials ... J1 Template\n",
-  "is_post": false
-}
-----
-
-In this document there are several fields, like `title`, `tagline`, or
-`description` that could be used for *full-text* searches. But additional
-fields are available, like `tags` or `categories` that can be used for
-more specific searches based on `identifiers`.
-
-To do a simple full-text search as well as more specific searches, QuickSearch
-offers a query language, a DSL (domain specific language). Find more about
-*QuickSearch DSL* queries below.
-
-=== Scoring
-
-The relevance (the `score`) of a document is calculated by an algorithm
-called BM25, along with other factors. You don’t need to worry too much about
-the details of how BM25 works. To summarize, the more a search term occurs in
-a single document, the more that term will increase that document’s score,
-but the more a search term occurs in the *overall collection* of documents,
-the less that term will increase a document’s score. In other words: seldom
-words count, increase the score.
-
-Scoring information, generated by the BM25 algorithm, is added to the (local)
-index. This allows a very fast calculation of the relevance of documents for
-a query.
-
-For example, imagine you’re website contains documents about Jekyll. The
-term `Jekyll` may occur very frequently throughout the entire website
-(used quite often for the content), so finding a document that mentions the
-term Jekyll isn’t very significant.
-
-However, if you’re searching for `Jekyll Generator`, only some documents of
-the website have the term `Generator` in them, and that will bring the score
-(relevance) for documents having both terms (words) in them at a higher score,
-bring them higher up in your search results.
-
-Matching and scoring is used by all search engines; the same to J1 QuickSearch.
-You'll see for QuickSearch a similiar behavior in *sorting* search results as
-you already know from internet search engines like Google. The top results
-are the more relevant ones.
-
-== Searching
-
-Search queries looks like simple text. But the search `engine` Lunr under the
-hood transforms the given search string (text) always into a search query.
-This supports special syntax, the DSL, for defining more complex queries.
-
-As always: start simple!
-
-=== Simple searches
-
-The simplest way to run a search is to pass the text (words) on which you
-want to search on:
-
-----
-  jekyll
-----
-
-The above will return details of all documents that match the term
-`jekyll`. Searches for *multiple* terms (words) are also supported. If
-a document matches *at least* one of the search terms, it will show in the
-results. The search terms are combined with `OR`.
-
-----
-  jekyll generator
-----
-
-The above example will match documents that contain either `jekyll` *or*
-`generator`. Documents that contain _both_ will score more highly and will
-be returned first.
-
-NOTE: In difference to a Google search (terms are combined at Google by
-`AND`) a Quicksearch combines the terms by `OR`.
-
-=== Wildcards
-
-QuickSearch supports wildcards when performing searches. A wildcard is
-represented as an asterisk (`*`) and can appear anywhere in a search
-term. For example, the following will match all documents with words
-beginning with `Jek`:
-
-----
-jek*
-----
-
-This will match all documents that end with `kyll`:
-
-----
-*kyll
-----
-
-Leading wildcards, as in the above example, should be used sparingly.
-They can have a negative impact on the performance of a search,
-especially in large indexes.
-
-Finally, a wildcard can be in the middle of a term. The following will
-match any documents that contain a term that begins with “f” and ends in
-“o”:
-
-[source, javascript]
-----
-idx.search('f*o')
-----
-
-It is also worth noting that, when a search term contains a wildcard, no
-stemming is performed on the search term.
-
-=== Fields
-
-By default, Lunr will search all fields in a document for the query
-term, and it is possible to restrict a term to a specific field. The
-following example searches for the term “foo” in the field title:
-
-[source, javascript]
-----
-idx.search('title:foo')
-----
-
-The search term is prefixed with the name of the field, followed by a
-colon (`:`). The field _must_ be one of the fields defined when building
-the index. Unrecognised fields will lead to an error.
-
-Field-based searches can be combined with all other term modifiers and
-wildcards, as well as other terms. For example, to search for words
-beginning with “foo” in the title or with “bar” in any field the
-following query can be used:
-
-[source, javascript]
-----
-idx.search('title:foo* bar')
-----
-
-=== Boosts
-
-In multi-term searches, a single term may be important than others. For
-these cases Lunr supports term level boosts. Any document that matches a
-boosted term will get a higher relevance score, and appear higher up in
-the results. A boost is applied by appending a caret (`^`) and then a
-positive integer to a term.
-
-[source, javascript]
-----
-idx.search('foo^10 bar')
-----
-
-The above example weights the term “foo” 10 times higher than the term
-“bar”. The boost value can be any positive integer, and different terms
-can have different boosts:
-
-[source, javascript]
-----
-idx.search('foo^10 bar^5 baz')
-----
-
-=== Fuzzy Matches
-
-Lunr supports fuzzy matching search terms in documents, which can be
-helpful if the spelling of a term is unclear, or to increase the number
-of search results that are returned. The amount of fuzziness to allow
-when searching can also be controlled. Fuzziness is applied by appending
-a tilde (`~`) and then a positive integer to a term. The following
-search matches all documents that have a word within 1 edit distance of
-“foo”:
-
-[source, javascript]
-----
-idx.search('foo~1')
-----
-
-An edit distance of 1 allows words to match if either adding, removing,
-changing or transposing a character in the word would lead to a match.
-For example “boo” requires a single edit (replacing “f” with “b”) and
-would match, but “boot” would not as it also requires an additional “t”
-at the end.
-
-=== Term Presence
-
-By default, Lunr combines multiple terms together in a search with a
-logical OR. That is, a search for “foo bar” will match documents that
-contain “foo” or contain “bar” or contain both. This behaviour is
-controllable at the term level, i.e. the presence of each term in
-matching documents can be specified. By default each term is optional in
-a matching document, though a document must have at least one matching
-term. It is possible to specify that a term must be present in matching
-documents, or that it must be absent in matching documents.
-
-To indicate that a term must be present in matching documents the term
-should be prefixed with a plus (`+`) and to indicate that a term must be
-absent the term should be prefixed with a minus (`-`). Without either
-prefix the term’s presence in matching documents is optional.
-
-The below example searches for documents that must contain “foo”, might
-contain “bar” and must not contain “baz”:
-
-[source, javascript]
-----
-idx.search("+foo bar -baz")
-----
-
-To simulate a logical AND search of “foo AND bar” mark both terms as
-required:
-
-[source, javascript]
-----
-idx.search("+foo +bar")
-----