XPath axis selectors are actually a relatively nice model

[git.ikiwiki.info.git] / doc / plugins / contrib / field / discussion.mdwn

diff --git a/doc/plugins/contrib/field/discussion.mdwn b/doc/plugins/contrib/field/discussion.mdwn
index cd479263a147f717db4a240caa96240a25cb4861..6161f80dfc1a19c2d1c5c88fe48945d64624fbcc 100644 (file)
--- a/doc/plugins/contrib/field/discussion.mdwn
+++ b/doc/plugins/contrib/field/discussion.mdwn
@@ -376,10 +376,28 @@ scrub, html fields, safeurl()ify url fields, etc.)
    * what form do we expect the "secured" output to be in? (raw HTML, scrubbed HTML, escaped HTML, URL)
 
 > Only if we know both these things will we know what sort of security processing needs to be done.
    * what form do we expect the "secured" output to be in? (raw HTML, scrubbed HTML, escaped HTML, URL)
 
 > Only if we know both these things will we know what sort of security processing needs to be done.

+
+>> Fieldsets are orthogonal to the security issue in the sense that you can use
+>> them without worrying about the field security issue, but they happen to be
+>> a rather clean way of answering those two questions, by allowing you to
+>> attach preprocessing attributes to a field in a way that the user
+>> (supposedly) cannot mingle with.
+

 > There is also a difference between field values that are used inside pagetemplate, and field values which are used as part of a page's content (e.g. with ftemplate).  If you have a TITLE, you want it to be HTML-escaped if you're using it inside pagetemplate, but you don't want it to be HTML-escaped if you're using it inside a page's content.  On the other hand, if you have, say, FEEDLINKS used inside pagetemplate, you don't wish it to be HTML-escaped at all, or your page content will be completely stuffed.
 
 > There is also a difference between field values that are used inside pagetemplate, and field values which are used as part of a page's content (e.g. with ftemplate).  If you have a TITLE, you want it to be HTML-escaped if you're using it inside pagetemplate, but you don't want it to be HTML-escaped if you're using it inside a page's content.  On the other hand, if you have, say, FEEDLINKS used inside pagetemplate, you don't wish it to be HTML-escaped at all, or your page content will be completely stuffed.
 

+>> Not to talk about the many different ways date-like fields might be need
+>> processing. It has already been proposed to solve this problem by exposing
+>> the field values under different names depending on the kind or amout of
+>> postprocessing they had (e.g. RAW_SOMEFIELD, SOMEFIELD, to which we could add
+>> HTML_SOMEFIELD, URL_SOMEFIELD or whatever). Again, fieldsets offer a simple way
+>> of letting Ikiwiki know what kind of postprocessing should be offered for
+>> that particular field.
+

 > So, somehow, we have to know the meaning of a field before we can use it properly, which kind of goes against the idea of having something generic.
 
 > So, somehow, we have to know the meaning of a field before we can use it properly, which kind of goes against the idea of having something generic.
 

+>> We could have a default field type (text, for example), and a way to set a
+>> different field type (which is what my fieldset proposal was about).
+

 > --[[KathrynAndersen]]
 
 -----
 > --[[KathrynAndersen]]
 
 -----