j1-template 2021.0.2 → 2021.0.7

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,236 +0,0 @@
----
-title:                                  Lunr
-tagline:                                full index search
-date:                                   2020-11-08 12:00:00
-description: >
-                                        Learn the search query language used by Lunr. The DSL used by Lunr
-                                        is quite close to Solr to support a powerful search experience
-                                        for better result. Using search expressions with wildcards, conditions
-                                        like and|or and fuzzy search algorithms are supported.
-
-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
-// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-== Searching
-
-After you have built an index of your documents, the next step is to
-perform a search.
-
-The simplest way to start is to pass the text on which you want to
-search into the search method:
-
-[source, javascript]
-----
-idx.search('foo')
-----
-
-The above will return details of all documents that match the term
-“foo”. Although it looks like a string, the `search` method parses the
-string into a search query. This supports special syntax for defining
-more complex queries.
-
-Searches for multiple terms 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.
-
-[source, javascript]
-----
-idx.search('foo bar')
-----
-
-The above example will match documents that contain either “foo” or
-“bar”. Documents that contain _both_ will score more highly and will be
-returned first.
-
-=== Scoring
-
-The score (also known as relevance) of a document is calculated by the
-https://en.wikipedia.org/wiki/Okapi_BM25[BM25] algorithm, along with
-other factors such as link:#Boosts[boosts]. 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.
-
-For example, let’s say you’re indexing a collection of documents about
-JavaScript testing libraries. The terms “JavaScript”, “library”, and
-“test” may occur very frequently throughout the entire collection, so
-finding a document that mentions one of these terms isn’t very
-significant. However, if you’re searching for “integration test”, only
-three documents in the collection have the term “integration” in them,
-and _one_ of them mentions “integration” many times, that will bring the
-score for that one document higher up.
-
-=== Wildcards
-
-Lunr 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 “foo”:
-
-[source, javascript]
-----
-idx.search('foo*')
-----
-
-This will match all documents that end with ‘oo’:
-
-[source, javascript]
-----
-idx.search('*oo')
-----
-
-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")
-----