Different `index.html` reference in preview and generate about grain HOT 8 CLOSED

I think you are mixing different concepts together. Why do you think that location is different for index.html during generation and preview phase? The property 'location' in the map of index.html resource will be the same no matter what phase is, it will be '/index.html'

from grain.

It is possible, since I don't understand what is the difference. For injecting resource I use not location but url (I think I just copied it from one of your examples). The url is definitely different. What is the difference between location and url? Also there is still problem with references. What should I write inside href tag to reference home page?

By the way, since injecting resources is fairly frequent task (at least it is one of the most important features of Grain that other static site generators do not have), there should be some helper methods to do so.

from grain.

http://sysgears.com/grain/docs/latest/#variables-on-a-page
According to Grain docs location is:
location - relative page location on the filesystem, for example /index.html or /contacts/index.markdow
url - URL of the page

http://sysgears.com/grain/docs/latest/#standard-tag-library
Grain provides standard tags for most vital tasks, additional tags are recommended to be added to custom theme tag lib.

The standard tags are:
r - looks up resource URL by resource location

from grain.

By the way, since injecting resources is fairly frequent task (at least it is one of the most important features of Grain that other static site generators do not have), there should be some helper methods to do so.

Not sure what do you mean here? Injecting resources by including them inside html? For that there is a model parameters:

${include 'tags.html', [modelVar: 'Some value']}

If you are referring to ResourceMapper, then please could you provide some example helpers and what stops you to use usual Groovy approaches to have them in for example your own separate class ?

from grain.

But to be really helpful, to be honest, I need to see what problem are you trying to solve with code examples...

Abstract discussion usually is not very helpful

from grain.

The problem I try to solve is rather simple: I need different types of resources loaded automatically (by type or by directory) and injected into specific page. Usually static site generators allow for single type of injected resources and does no include custom filtering. Grain allows not only to load custom resources, but also filter them and convert on the fly which is very important. But access to these features is rather obscure.

I don't know if it is the "right" way to do things, but I usually include resources via ResourceMapper in a following way:

    /**
     * This closure is used to transform page URLs and page data models.
     */
    def map = { resources ->

        def refinedResources = resources.findResults(filterPublished).collect { Map resource ->
            fillDates << resource
        }

        injectSomething(refinedResources)
        ...
        refinedResources
    }

    private def injectSomething(List resources) {
        Map locationPate = findResource('/location.html', resources)
        if (locationPate) {
            println "injecting something"
            def something= resources.findAll { it.content_type == 'type_of_something' }
            // order something by tag, date, etc.
            locationPate.put("something", something)
        } else {
            println "Location page not found"
        }
    }

    private def findResource(String name, List resources) {
        resources.find { it.url == name }
    }

from grain.

Yes, generally you do injection like this. Finding by URL can be non-optimal strategy in certain cases, you can find resource by it.location == location instead. Just try to println some original resource you receive and see what properties contained in its map.

The idea is simple, actually. Resource mapper is the first thing that is called on "raw" resources on the file system, Grain throws all the resources on it and expects the resource list to be rendered in return. Resource mapper is free to delete some resource from the original list, or make several copies of resource in original list or can even create new resources on the fly and add them to the map.

No means to work with resource lists are provided and I can't imagine yet how these means can look like. Resource mapper just gets list of maps and should return list of maps, usually transformed somehow, with using all the power of Groovy as it needs.

This simple and central idea is somehow hidden in the Grain, I agree.

from grain.

I usually just use IDEA debug to see what is inside resources objects instead of printing.

Well, I got the idea. I currently maintain three different sites using Grain (one is online, two are in development), so when I find any convenient way to add helpers to resource mapping, I will let you know.

from grain.