Forms vs Content Blocks
Form-generated fields _Template-generated fields
Label %%form_data{name}%% %%content{n}%%
Field specificity Fields are named, form is malleable. Admin can adjust the organization of the form, and variables have clearer identities. Fields specified by their position in the data sheet (content blocks). Not intuitive, and not flexible.
Compile Form data compiled last?

[%%form_data{email}%% %%form_data{name}%%] rendered as

  • [ Columbia Citizens], (>example)
  • not as intended, ten.snezitiCaibmuloC|ofni#snezitiC aibmuloC.

[ Columbia Citizens] entered in a text-type field also doesn't render (>example)

Wiki-type field renders correctly, but only if the user knows to bracket [email name], and the wiki field seems to force a newline (>example).

Steven HeynderickxSteven Heynderickx took a stab at this too, with this example, but apparently it's also compromised by the newline bug?

This works fine with content blocks
  • %%content{3}%% — name
  • %%content{4}%% — email
  • [%%content{4}%% %%content{3}%%] renders correctly (>example).
Defaults Defaults are explicit in the data form (not hidden, >example)
  • @@ or @< are confusing to user and aren't compiled as intended (>example). This does work when user populates the field & points to an offsite image (>example).

Defaults hide hints (not optimal, in this case).

Defaults also explicit, though they are compiled (>example).

See passthrough includes, below.

Passthrough includes Assume the user provides no data for the email or image fields. I want the layout to revert to (hidden) defaults — %%author%%, and an uploaded image (if any). In other contexts, Erich's "tricky" passthrough includes can almost do this (>example).

When the user leaves the data field blank, then the passthrough include appears to take on the blank, rather than moving on to the desired default (>example)

  • email = {$email} | email = @@
  • image={$image} | image= :first
For blank content blocks, the result is similar. The passthrough include appears to take on the blank, rather than moving on to the desired default (>example).

When the [!-- comments --] are left in the content blocks, they're also passed, which breaks the tricky includes. There might be a solution, but it feels like overkill.

Fields that update includes Erich had a method for passing include parameters to _templates via %%content{n}%%. It doesn't work anymore. It's not at all user-intuitive anyway, unless it could somehow be passed invisibly. A change in the compiling hierarchy means this doesn't work anymore. In this case, given all the other constraints, I'm not sure if it's useful.
Reorganizing Possible to reorder data fields with no impact. Adding fields shouldn't break existing pages, depending on the _template.

If the form changes to delete a field, what happens to that field in existing pages? The remnant data stays there, until someone reopens and saves the page. Then the deleted field is removed. Does that matter? Not sure — (>example)

Fairly easy to add new fields, but difficult to remove or rearrange existing fields.
Hints Hints are elegant — don't affect compiling Hints are [!-- comments --], and break wiki-code when inserted in [[image %%content{5}%%]] or in tricky includes.
Matching Matching seems to work well, but effectively makes a field required I learned something!. Useful primarily for email field (assuming we can compile [%%form_data{email}%% %%form_data{name}%%]) as ten.snezitiCaibmuloC|ofni#snezitiCaibmuloC. Matching not available
Optional / required Not currently available, except regex matching might achieve the same result. Not too critical right now. N/A
Page tags Possible to assign these through NewPage module Possible to assign these through NewPage module
Resources Wikidot documentation
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License