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 [[e-mail] Columbia Citizens], (>example) not as intended, ten.snezitiCaibmuloC|ofni#snezitiC aibmuloC. [[e-mail] 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 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 Projects site	Wikidot documentation