That sounds great. Once you're done I will jump in and make some updates to reflect the changes in v3.0.0.
Thanks!

from stacey.

Thank you for the help !
I just make the jump with the twig template and have a prob with the content editing doc.
In the page.path section can you give an example of use ?

Try plenty of markup and stacey don't want to output the path.

![](@path/image.jpg)
![](@page.path/image.jpg)
![](./image.jpg)
![](image.jpg)
...

In version <3.0 it was the @path variable.

from stacey.

Try {{ page.path }}

from stacey.

Thx kolber but doesn't work ...
I've in my page.txt, inside the 'content:' section:

![]({{ page.path }}/file.jpg)
![]( {{ page.path }}/file.jpg)
{{ page.path }}
<p>{{ page.path }}</p>

the {{ page.path }} is not render jus appear as it.
Can you give me some examples ?

from stacey.

Ah, sorry, my mistake.
It is actually {{ path }}.

Hopefully I will have the documentation updated soon, so you will have a central resource to refer to.

from stacey.

Thanks Anthony, it's working ^_^

do you plan to expose other vars (like permalink, root_path ...) ? because my site is in a subfolder so the path variable don't take the subfolder name inside.

domain/subfolder/path_to_file

indeed I have

domain/path_to_file

So need to write the subfolder name inside url.
Not very cool when you write in local and not directly on the web server ;)

from stacey.

Sorry about this guys. I've been on vacations.

On Feb 10, 2012, at 4:07 AM, "F."[email protected] wrote:

Thanks Anthony, it's working ^_^

do you plan to expose other vars ? because my site is in a subfolder so the path variable don't take the subfolder name inside.

domain/subfolder/path_to_file

indeed I have

domain/path_to_file

So need to write the domain inside url.
Not very cool when you write in local and not directly on the web server ;)

---

Reply to this email directly or view it on GitHub:
#33 (comment)

from stacey.

Looking very much forward to updated docs, especially the "get" language constructs...

get "/url" do

do stuff

end

from stacey.

I've made a start. :)
https://github.com/kolber/stacey/wiki/3.1-Templating-Language

from stacey.

Alrighty. Now all pages from 2.0.3 are now on the wiki. While you make the proper editions I thought it would be better to have the Installation page on "1." and let "Overview" be the homepage.

This homepage will have the official listing of "okay" pages that are 100% accurate.

Do you agree?

from stacey.

I wish to help contribute to the documentation, I was thinking of re-writing the familiar template examples, stacey-template2 and 3.

Any suggestions, or should I just jump in?

from stacey.

@rnmp that sounds perfect.

@darrylhebbes perfect! I think just jump in and see how it goes.

from stacey.

I also look forward to chipping in on the docs. In the meantime it's possible to figure out how the new syntax maps to the old by looking into page-data.inc.php. There a several functions there that define them starting ~ line 92.

Something that's been harder for me to determine is what the text-file variables story will be. Although only @bypass_cache and @path were documented for use inside the content/.txt file in Stacey 2.x, many vars seemed to "just work" :-). Not sure if that will still be true. Maybe stricter now?

from stacey.

Thought I should give an example of how I've used @vars in the text files. I've done this a lot in the text files: title: @page_name. This gets the title by parsing the folder names. Very handy!

Now in 3.0, I'm using title: {{ page.page_name }} in the project text file. It works as expected when rendering the project page. But on the the index page (where the title value is pulled from inside a partial (category-lists.html) using {{ child.title }}) the title renders the actual twig expression "{{ page.page_name }}". Which makes, sense, the partial is expecting a value, not another expression to evaluate. But somehow it "just worked" in Stacey 2.3 ...

from stacey.

The running order of the original parser was designed to allow this sort of use.
While handy, it did however cause a number of other issues within the parser itself. So, the switch to the new system is generally for the best.

That being said, I am looking into switching from .txt files to yaml files, which whilst maintaining a very similar syntax, does allow this sort of thing to be done through aliases and anchors.

from stacey.

Alright, folks. The Wiki base is complete. Now let's edit and update it. :)

from stacey.