What would be an example of one of the variables? Would height/width be in there? My impression is that this acts as a standard include and doesn't create a frame, so I think not.
So what would be worth controlling as a variable? =/
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Variables are exactly the same as currently used in [[include]], just properly formatted with quotes.
Ahh, I know what you mean. I'd never actually used them before, only seen glimpses of them with things that James and other guru's had created.
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?
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
The good thing about the current, non-quote-required, model is that you can use an include in a ListPages module's prependLine:
[[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.
In reference to James' post
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 CSIs1), 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
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
@James
I used to use your technique of the reusable included table.
However, for now I prefer shorter ListPages instructions
[[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
Kanjo said:
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.
I have to ask, why is the ListPages module in a div to begin with?
Header stuff
[[module ListPages …]]
list pages stuff
[[/module]]
Footer stuffHistorically all modules were in divs and acted as mini applications. This approach was used for ListPages. We don't really like it, and have been looking at making modules work in-line.
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.
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…
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.
Regarding table styling, what will work quite easily is prependLine="[[table]] appendLine="[[/table]]" and a CSS module in the page that provides styling for tables. I've tried this (not per-page CSS but per-site CSS) and it gives nice results.
Do you have a link we could look at ?
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
OK, here is a work in progress: http://forum.wikidot.com/system:page-manager
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.
One word. Wow.
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.
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
I think we need full multi-line parameters for CSIs (original include multi-line parameters can't contain "|" unless some tricks are applied).
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.
Piotr Gabryjeluk
visit my blog
I've made a generic design for multiline arguments that takes your ideas along with some that were proposed on the community, for named sections. See design:17. This would work, I think (we need to be sure that it is safe to use in code that itself sits within sections).
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?
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.
Piotr Gabryjeluk
visit my blog
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.
Piotr Gabryjeluk
visit my blog
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.
This might not always be desirable, but it might be handy if you could choose to specify the page title for the included page in the [[include]] statement.
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.
Sue
[[include :modules:include:2]] is fine but after some weeks … what's inside ?
Yes I could prepend a comment line but why not
[[include :modules:include:2 dummy-text-not-be-parsed]]
example
[[include :modules:include:2 … including modules quick reference]]