why not
[[include :modules:include:2 dummy-text-not-be-parsed]]

Low and behold, we have another genius!

Thanks gerdami!

If you have designed a whole page to be included somewhere, it may be desirable that the page title is inherited along with the code on the page. Otherwise, you would have to manually add a title to all sites that included the page if you wanted the title to be consistent across sites. Of course there would be other situations when you didn't want this behaviour, so you should be able to switch it on/off.

I suggest %%arg{name}|default%% (consistent with tags_linked).

Please read http://blog.wikidot.com/design:12. The use of ? for default values is established there, and | is already used for formatting. You should be able to mix the two, so %%name?default|format%%.

You say "multi-line defaults and defaults containing '%%' (which can be really useful for ListPages wrappers).", please give an example. I do not see any requirement today for either of these.

And I'm trying to avoid making an "ultimate" include here. The original goal was CSI, not "fix every possible problem with include", so please let's stay within what is needed and possible. Stretching designs to cover every single possible idea just guarantees they will never be implemented.

For allowing code to be generated by one tool and formated by a second, can you provide a concrete example or use case?

[[include includes/block:blog-listing category="blog"]] ==== post-format [[include includes/format:tech-blog-post /]] ==== calendar-format [[include includes/format:red-calendar /]] [[/include]]

We would have repository of reusable blocks (includes/block:) and a repository for reusable formats (includes/format:). This allows us to use the same formats in different blocks (in case, you want to have one format of "item" in each different listing). This is one of possible uses for nested includes. I think there will be more. But as we already have include-open and include-close tags in the design, this can come later.

All arguments can be given default values by using this syntax: %%arg{name}?default%%. This matches the proposed syntax for default values in ListPages and _templates.

I suggest %%arg{name}|default%% (consistent with tags_linked).

But. There is a problem with multi-line defaults and defaults containing '%%' (which can be really useful for ListPages wrappers).

I would say, we need to make include'able blocks more aware of their role. First list possible arguments with their defaults, then goes the include code (similarly to function definition and body). Such blocks are made to be included.

Currently the use of two syntaxes makes this distinction. If you merge the two syntaxes, how do you do it? my mistake: you already explained how to do this.

For allowing code to be generated by one tool and formated by a second, can you provide a concrete example or use case?

I think we need includes to be nestable in a way, that include output can be passed as include parameter (this would allow having repository of not only code that does thing, but also repository of formatting code).

I think we need to name variables consistently, so we should use %%something%% just like in _template and ListPages and not {$something}. This also will ease creation of unified templating code in Wikidot.

I would love to do something like this:

[[include includes.wikidot.com/blog-listing category="blog"]] [[include formats.wikidot.com/tech-blog-post /]] ==== [[include formats.wikidot.com/red-calendar /]] [[/include]]

The outside include would generate blog post listing for me taking a format for blog post as first multi-line parameter and format for calendar for second multi-line parameter. Formats would be able to be included from other site.

Almost forgot I was meant to be looking at the table styling, not the page manager itself :)

What is the column after "Edits" and before "Tags" ? It has no title.

edit: Nevermind, it is the edit column. Titles aren't lined up properly.

It's a concept for a page manager, still needs a bunch of changes to ListPages to work properly.

But you can see how it does table styling. It would work even better with a CSS module but in fact the table styling is pretty elegant for table layouts used elsewhere in the site as well.

But this is not true! The header/footer appears regardless of the content within! It's a bit annoying, actually…

I'm not sure what you mean by this since the header/footer idea is a design proposal, not implemented yet. The idea is that if the list is empty (zero items), these do not show.

Actually, there should be two further blocks, page-header and page-footer.

The header/footer need to be controlled by the List module because they only appear when there is at least one item.

But this is not true! The header/footer appears regardless of the content within! It's a bit annoying, actually…

The header/footer need to be controlled by the List module because they only appear when there is at least one item. Empty lists should show as empty, in most cases. Also, you often want to add things into the footer like counts, totals, etc.

You see, the following is not possible:
{{[[module ListPages prependLine="[[table class="food" style="background-color: red;"]]" appendLine="[[/row]][[/table]]"]]}}

Indeed. Yet that is what we want to do - creating an include to get around the lack of a quote escape is costly. All arguments should allow quote escaping. But I don't like the prependLine and appendLine design at all (and would have vetoed it if I was watching when it was built).

The correct design for ListPages should be something like:

[[module ListPages ...]] [[header]] Put stuff that appears before the first item. [[/header]] [[footer]] Put stuff that appears after the last item. [[/footer]] [[else]] Put stuff that appears if there are zero items. [[/else]] [[/module]]

And 'separate' should always be false, since we can put [[div]]s around items if we want to. This is the design I'll be pushing when we start to make other List modules.

What is {number} for?

To select content sections or code blocks. I've clarified the text.

BTW, That is such a simple, yet clean and sexy looking table! My jaw dropped it was so beautiful!

[[module ListPages separate="false"_ prependLine="[[include include:raw-list-table-header]]" appendLine="[[/table]]" ]] [[row style="vertical-align:top; "]] [[cell]]%%linked_title%%[[/cell]] [[cell]]%%created_by_linked%%[[/cell]] [[/row]] [[/module]]

Example taken from: http://themes.wikidot.com/start:plain

pieterh wrote:
The non-quote version came from wikimedia, apparently. Yes, we keep old syntax for compatibility.

This is all well and good, but following in James' line of thought, I suppose that any new attributes added to the [[include ...]] documentation will not support the unquoted version?

Continued support for both quoted and un-quoted versions of variables for [[include ...]] would be useful for the reason outlined by James, above.
i.e. With any new attributes that are introduced (including those that are for CSIs¹), the unquoted version should also be supported.

edit: that wasn't exactly as clear as I'd like it to be, but it's better than my original post. let me know if you want me to re-explain what I meant here

[[module ListPages prependLine="[[include table class=food |style=background-color: red;]]" appendLine="[[/row]][[/table]]"]]

[[table class="{$class}" style="{$style}"]][[row]]

You see, the following is not possible:

[[module ListPages prependLine="[[table class="food" style="background-color: red;"]]" appendLine="[[/row]][[/table]]"]]

If you made includes require double quotes for variables, then we would be approached with the above problem, and thus unable to create custom tables within the ListPages module.

Having begun using them in one of my own websites yesterday, I've learnt quite a bit about them already. I agree, quotes would be more consistent.

I assume the non-quote version will be supported for backwards-compatibility?

So what would be worth controlling as a variable? =/