Today we often copy/paste code between sites. This is inefficient for maintenance. I'd like to make a dynamic include function.
[[include :sitename:category:page-name{number} argument="value"... /]]
[[include :sitename:category:page-name/code/{number} argument="value"... /]]
Where sitename is either the name of the site (excluding '.wikidot.com') or a full wikidot subdomain name, or a custom domain.
The {number} selects a content section (similarly as for %%content{n}%%, allowing multiple sections in a page, included independently. The second form selects a code block, again numbered from 1 upwards.
We also use a new form for arguments, using a more standard 'var="value"' syntax. The value can contain quotes escaped as \". Arguments can also be specified within body of the include using the proposed consistent argument format:
[[include :sitename:category:page-name{number}]]
==== argument
value
[[/include]]
The included page can be in one of three formats:
The include page provides a templating mechanism using the same syntax as for _templates and ListPages. However the only symbols that is valid is: %%include{//name//}%% where 'name' is the name of the argument passed by the called.
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.
The include page can do conditional compile-time templating as follows:
[[if //condition//]] ... wiki text [[/if]]
The condition syntax is either of:
Where operator is one of '=', '<>', '<', '<=', '>', '>=', 'in', 'ex'. 'in' and 'ex' take a list of values separated by spaces or commas.
The [[include]] tool, when properly formatted (with a closure), does not produce empty paragraphs before and after, so can be used inline with this syntax:
some text \
[[include sitename\category:page /]] \
some more text
This design takes into account the following Community documents:
[[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]]
gerdami - Visit Handbook en Français - Rate this howto:import-simple-excel-tables-into-wikidot up!
Low and behold, we have another genius!
Thanks gerdami!
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
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
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.
Portfolio
OK. We can make ultimate reusable code blocks (URCB) later.
Piotr Gabryjeluk
visit my blog
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:
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?
Portfolio
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
Kanjo said:
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:
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.
Portfolio
I have to ask, why is the ListPages module in a div to begin with?
Historically 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.
Portfolio
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.
Portfolio
Oh sorry, I was talking about the current situation. prependLine and appendLine (acting as the header and footer) appear regardless of whether any pages match the ListPages criteria.
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.
Portfolio
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.
Portfolio
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)
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.
Portfolio
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 non-quote version came from wikimedia, apparently. Yes, we keep old syntax for compatibility.
Portfolio
The good thing about the current, non-quote-required, model is that you can use an include in a ListPages module's prependLine:
This allows the use of a table surrounding the module's content, as the table's page contains:
Which makes it possible to set attributes to the table.
You see, the following is not possible:
It's not possible because the first double-quote used within the prependLine is interpreted as the completing double quote of prependLine. That is, the prependLine is essentially [[table class=
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
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
and of course a one shot include:raw-list-table-header.
Balance sometimes weighs on the simplicity side…
Example taken from: http://themes.wikidot.com/start:plain
gerdami - Visit Handbook en Français - Rate this howto:import-simple-excel-tables-into-wikidot up!
Yeah that's much shorter — but like you said, not reusable.
BTW, That is such a simple, yet clean and sexy looking table! My jaw dropped it was so beautiful!
What is {number} for?
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
To select content sections or code blocks. I've clarified the text.
Portfolio