Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

User-space Functional Logic Renderings with Globalization Capabilities #2087

Closed
jafskot opened this Issue · 3 comments

4 participants

Jaf Skot Koffeingeladen Parker Moore jaybe@jekyll
Jaf Skot

User-space Functional Logic Renderings with Globalization Capabilities

Provide globalization capabilities for dynamic logical outcomes for reuse within subsequently-built design, rendering, and output

Overview of Idea, Concept

Provide core Jekyll functionality allowing the end-user designer to create, have access to, and take advantage of initialization-style logic (Liquid, Variables, Functions) of which outcome would then be globally available throughout the build and render phases without redundant reiteration.

Overview of Purpose, Example, Implementation

  • User-designer wishes to "initialize" a build, in advance and prior to, via custom Liquid-based functions and eventually-assigned variables, for subsequent use within layouts, templates, and further logic during the build process.

  • Such initialization could be accomplished "first", at the beginning of build execution, and before layout, page, and post renderings occur.

    • "init", "run once", "initialize", "pre", "setup"
  • A key aspect of the outcome from such initializations are that variables assigned would become global, persistent, and available for reuse outside of the initial context.

  • This would allow a user-designer to use upfront logic to produce globally-reusable outcomes, prior to the reiterate, redundant page/post-building processes.

    • Such logical outcomes would not need to be figured and reproduced for every page/post render iteration.

Value Examples, Concepts

  • User-designer wishes to establish, upfront- and once-only, a number of variables produced by arbritrary Liquid logic and variable assignment.

    • User then wishes to reuse such now-globally-available variables throughout the subsequent typical layout, build, and render activities.
  • Example: Establish an array/hash containing key elements for reusable navigation elements throughout the build process, dynamically and pragmatically, without redundantly refiguring.

    • ./_init/1.nav.liquid
      • Contains Liquid logic to produce an array such as the following:
        • {{ site.init.nav. ... }} => "home1"=>{"link"=>"/home", "title"=>"Home Sweet Home", ...
    • ./_data/myconfig.yml

      • {{ site.data.myconfig.nav.top }} = home3
    • Pros/Points/Arguments/Presumption:

      • Instead of rebuilding figurative output of {{ site.pages }} into a navigation approach every single post/page render when it could be done once, initially, upfront, and included/referenced throughout?
        • Proactive rebuttal:
          • But I would prefer to not write/use a ./_plugin.
          • But I would prefer to only init and run my logic *once*
      • Vastly improve (large|any) site regeneration times through use of user-spaced globals making eventual incremental regenerations, once upon a Jekyll, even more valuable!

References

  • #jekyll IRC:
    • jaybe, kaffeebohne
Koffeingeladen

I have 3 use cases which would benefit from this. (One, at a certain point wouldn't even work without this.)

  1. I want to get the exact number of my post in the post loop but because I use pagination I have to create a loop which somehow creates a hash that contains a post identifier (e.g. title) and the number (e.g. 41). At the moment I have 46 posts which is ok for speed, and with 10 posts per site I only have 5 pages where this loop has to run. But what if I wanted this information on every posts site? That would take a really long time.

  2. I have a counter for total posts (easy), total words (goes fast) and total categories (takes the longest). For the words I have to loop through every post, for the categories through each post and its categories. At the moment I use it without pagination but it takes about 0.5s for every page included (I tried it with several pages, it ads about 0.5 seconds for every page. Displaying this count on every page on the blog would take more than 25 seconds for my 46 posts. Compare that to 0.5 or even 1 second which would be possible if a way to make it available globally would be provided.)

  3. A Twitter Widget showing the latest tweet of a user using Twitters API. (I know, that is quite dynamic for jekyll, but possible, one could easylie use a cronjob to udpate jekyll ;) ). With the api limit and displaying the widget on every page you run into troubles if you generate your blog in short amount of times (I actually wrote that plugin, a liquid filter, which is working except I'd hit the API limit way to often).

Edit:

Another scenario that would benefit from this:

Showing 2 widgets on a site, both with the latest 5 posts from different categories. Again it would be a huge benefit in speed if it only had to be generated once.

Parker Moore parkr added the Feature label
Parker Moore
Owner

Jekyll 3's hook-based architecture will allow for this quite easily! Just render what you need to just once at the beginning of the build process and ask for it where needed.

Parker Moore parkr closed this
jaybe@jekyll

Excellence!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.