from the documentation: <div class="snippet-clipboard-content notranslate position

Sure. You have two options here: {% include %} and <c

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

how is your library better compared to <a href="https://github.com/sourru

passing variable to a template about ginger HOT 13 CLOSED

GildedHonour commented on August 27, 2024

passing variable to a template

from ginger.

Comments (13)

tdammers commented on August 27, 2024 1

This is a library that I maintain and publish for free; you can use it in any way you see fit, or you can choose not to use it. I am also very open to suggestions, constructive criticism, and so on; I do not, however, respond to rants, demands, or vague unconstructive bashing. If you feel that Ginger lacks in certain areas, which by the way is totally possible, if not expected, then you have a few options at your disposal: 1. Fix the problem yourself, send patches, and I will be happy to merge them (or else explain patiently why not) 2. Don't use Ginger. I'm fine with that, and nobody is putting any pressure on you. If Karver works better for you, then use that, no hard feelings whatsoever. 3. Pay me, or someone else, to fix things. I'm providing Ginger as-is, and I'm willing to put some effort into making it easier and better for everyone, but if you want me to do requests, then the amount of pro bono work I will do is limited. 4. Make more concrete and constructive suggestions. If you can show me what you think an example program should look like, I will be more than happy to discuss the possibilities. Likewise, if you can suggest what the documentation on ginger.tobiasdammers.nl should look like, I will be happy to make adjustments. Btw., the guide section on that website comes directly from yhe ginger repo itself, so you can even issue pull requests. Whatever you do, however, I kindly ask you to refrain from accusations and between-the-lines insults ("painful"). Please do not raise issues just to vent your frustration, it's just not constructive. All that said: Ginger is a lot more generic than Karver, making it suitable for a wider range of applications. This flexibility comes at a cost, in the form of a more complex interface and pretty wild type signatures. I tried to make things as palatable as possible, and I certainly haven't achieved an optimum yet, and since I don't have infinite amounts of time, any help is welcome. Either way though, if Karver meets your use case, then Ginger is most likely overkill. It's up to you to judge that. Hope that helps.

…

On May 3, 2017 5:45 PM, "Alex Maslakov" ***@***.***> wrote: that's not a library, but a pain. part of code here, part there, setup this, adjust that. how to run it after all? in the documentation -- nothing. in https://github.com/sourrust/karver everything is comprehensible. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABXjx9uFbAOWsu-Ljq_ycLCl634ukdR0ks5r2KEsgaJpZM4Mie0o> .

from ginger.

tdammers commented on August 27, 2024

This happens on the Haskell side of things; you need to pass context variables in when calling runGinger. http://hackage.haskell.org/package/ginger-0.5.1.2/docs/Text-Ginger-Run.html explains things in some more detail; however, essentially what you need to do is write a context lookup function which returns a suitable GVal value for each variable name, then you use one of the makeContext functions to turn it into a GingerContext, and then you pass that to the runGinger(M) function. E.g.:

let contextLookup varName =
           case varName of
               "username" -> toGVal username
               "imageURL" -> toGVal imageURL
               _ -> def -- def for GVal is equivalent to a NULL value
    context = makeContext contextLookup
htmlSource $ runGinger context template

Alternatively, you can write your context object as any dictionary-like data type that has a ToGVal instance, and use the easyRender(M) API.

from ginger.

tdammers commented on August 27, 2024

This should probably be fixed in the documentation.

from ginger.

GildedHonour commented on August 27, 2024

Is there any way to create a parent/child template?

from ginger.

tdammers commented on August 27, 2024

Sure. You have two options here: {% include %} and {% extend %}/{% block %}.

{% include %} is just a dumb inclusion mechanism; it picks up the file you reference and injects it at the current position, similar to how #include works in C.

{% extends %} and {% block %} implement "template inheritance". It works as follows:

First, you write a parent template. This is just a regular template, but you can wrap blocks that you want to be able to override in {% block block_name %} / {% endblock %}.
Then you write the child template; this is not a regular template, it starts with an {% extends %} statement, and after that, only {% block %} statements are allowed, which override blocks of the same name from the parent template.

For example, you might write a parent template like so:

<!DOCTYPE html>
<html>
    <head>
        <title>{% block title %}My Super Fun Site{% endblock %}</title>
    </head>
    <body>
        <header>My Super Fun Site</header>
        <main>
            <h1>{% block main_header %}Hello!{% endblock %}</h1>
            {% block content %}
            {% endblock %}
        </main>
        <footer>
            Copyright (c) 2017 myself. All Rights Reserved.
        </footer>
    </body>
</html>

And then you can have a child template that overrides some of these blocks:

{% extends 'master.html' %}

{%- block title %}This is a different title.{% endblock -%}

{%- block content %}
Lorem ipsum dolor sit amet adipiscing elit. And so on.
{% endblock -%}

This will render a page using the same structure as the master template, but overriding the title and content blocks.

In order for this to work correctly, you need to tell the template loader how to load the parent template; the CLI contained in the main repo demonstrates this; you need to pass an IncludeResolver to parseGinger (or parseGingerFile), which is essentially a function that takes a file name and monadically return source code. The actual type is SourceName -> m (Maybe Source), with Monad m; however both Source and SourceName are aliases for String, and m is usually IO or something similar.

Hope that clears things up.

from ginger.

GildedHonour commented on August 27, 2024

thanks, I'll try.

from ginger.

GildedHonour commented on August 27, 2024

how is your library better compared to https://github.com/sourrust/karver ?

from ginger.

GildedHonour commented on August 27, 2024

@tdammers up

from ginger.

tdammers commented on August 27, 2024

how is your library better compared to https://github.com/sourrust/karver ?

Well, the most important differences should be obvious (ish) from the API and its types; anyway, from what I can gather from Karver's documentation, here's a (probably incomplete) list of what Ginger does differently (though whether that is necessarily better is debatable and depends on priorities and context):

Effectful templates. This was a big one for me, because I want template to be able to trigger effects such as loading additional data from the backend, getting the current time, etc. At the same time, I still wanted to keep things sandboxable, so Ginger doesn't just come with a truckload of I/O primitives, instead it allows you to parametrize your template loaders and runners over arbitrary monads, and then you can pass your effectful functions in as context variables.
Multi-tagged unitype context variables. For lack of a better word. Karver's context object is a hashmap of Text to Text; Ginger has a more sophisticated unitype that can express functions, lists, hashmaps, numbers, booleans, null, strings, and encoded HTML. The last one is especially important, because being able to tag HTML as "already encoded" means you hardly ever have to worry about XSS anymore. It also allows us to do things like write a |markdown filter that takes a raw string, interprets it as markdown, and spits out pre-encoded HTML - without the tag-level distinction between text and HTML, the template engine would HTML-encode the markdown output, which is not what you want.
Separate parsing and running steps. This is important for two reasons; one, you can cache parsed templates, avoiding a re-parse on future usages (and you can precompile all your templates at startup, reducing per-request overhead further, and catching template syntax errors early); and two, you can control effects for the parsing and running stages individually, that is, you can have effectful parses (for loading external templates, e.g. using {% include %}) but keep the running stage pure, or you can hook extra effects into the running stage that you don't need for parsing, or you can use an alternative loader mechanism (such as an in-memory hashmap of template names to template sources) for the parser while keeping the interpreter in plain IO.
More complete implementation of the Jinja2 language. Ginger implements most of the core Jinja2 syntax; I deviated only with features that don't make sense in a language like Haskell (the "blatant Pythonisms" mentioned elsewhere), or where I truly believe that making things simpler would be better (this is why filters, functions, and tests are all the same thing in Ginger - {{ foo|bar }} and {{ bar(foo) }} compile to exactly the same thing).
More programming features in the template language. Ginger is, in fact, a full-blown dynamic programming language; you can define your own functions, there's variables with scopes and all, there's a complete expression sublanguage (and it's used in every place you'd expect to put a variable, so you can, for example, loop over the output of a function that you call on a sublist of a context variable filtered through a function returned from another function call, if you want), you can even drop into "script mode" and write a Ginger flavor that's similar to a Python/JavaScript hybrid.

The only real problem I see with Karver is that it uses unsafePerformIO to load included templates from disk - IMO this is really really really not what you should use unsafePerformIO for.

Hope that clears things up a little.

from ginger.

GildedHonour commented on August 27, 2024

thanks.

from ginger.

GildedHonour commented on August 27, 2024

Is there a MVP of returning an html file to a client?

in this code, how is "index.html", assuming that's the name of an html file, supposed to be passed to it?

loadFile fn = openFile fn ReadMode >>= hGetContents

loadFileMay fn =
    tryIOError (loadFile fn) >>= \e ->
         case e of
            Right contents ->
                return (Just contents)
            Left err -> do
                print err -- remove this line if you want to fail silently
                return Nothing

from ginger.

GildedHonour commented on August 27, 2024

that's not a library, but a pain. part of code here, part there, setup this, adjust that. how to run it after all? in the documentation -- nothing.

in https://github.com/sourrust/karver everything is comprehensible.

from ginger.

tdammers commented on August 27, 2024

Also, this has long gone beyond the scope of "how am I supposed to pass these variables -- title, naviagation, body -- to this template?", so I'm closing this.

from ginger.

passing variable to a template about ginger HOT 13 CLOSED

Comments (13)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent