Tim,
Thanks for the response. What I'm trying to do is build a flexible UI
that let's administrators create any 'sieve' script they want while at
the same time being able to present the script to the user in some kind
of real world representation. The reason for this, is that we don't
think many admins would want users to have the ability to write their
own scripts, but we don't want to restrict administrators to only
providing the scripts we come up with.
So, what I've done is use the comments to hide certain 'key' information
that makes it possible for the parsing engine that presents this
flexible UI to figure out where user selectable fields would go. I
can't think of another way of offering such a UI without requiring an
admin to write their own code for each of the scripts.
In a typical example this is what an administrator would create as a
template for the UI:
disclaimer: This is just an idea that I came up with, and is not
necessarily the easiest or best way to implement it, but this shows what
I think to be a fairly simple way to implement flexible UI.
---- template1.txt ----
# $Rule Info: Template="File To Folder"
if header :is <Q1> <Q2>
{
fileinto <Q3>;
}
#PRE: This rule files messages to a folder
#PRE: Choose the header field like "Sender" to search on
#PRE: And specify the value you wish to search for
#Q1:$header:Header field you wish to search on
#Q2:$value:Value to search for
#Q3:$folder: Folder to file to
#POST: Be sure to adjust the order of this rule
---- end template1.txt ----
The UI javascript or possibly the httpd server's cgi (we are trying to
make this html based) would parse this out and create a page that looks
like:
+---------------------------------------------------------------+
| Template: File To Folder Name: _________________ |
+---------------------------------------------------------------+
| This rule files messages to a folder |
| Choose the header field like "Sender" to search on |
| And specify the value you wish to search for |
| |
| Header field you wish to search on: [o ] |
| Value to search for: _____________________________ |
| Folder to file to: [o ] |
| |
| Be sure to adjust the order of this rule |
+---------------------------------------------------------------+
[o ] are pull down menus with the appropriate items
________________ is an editable entry box
From this, the UI (server or client) creates the finished sieve code:
---- sieveRuleSource value ----
#$Rule Info: Order=1 Template="File To Folder" Name="Sam's Spam Rule"
if header :is /* Q1 */ "Subject" /* /Q1 */ /* Q2 */ "SPAM" /* /Q2 */
{
fileinto /* Q3 */ "spamfolder" /* /Q3 */;
}
#PRE: This rule files messages to a folder
#PRE: Choose the header field like "Sender" to search on
#PRE: And specify the value you wish to search for
#Q1:$header:Header field you wish to search on
#Q2:$value:Value to search for
#Q3:$folder: Folder to file to
#POST: Be sure to adjust the order of this rule
---- sieveRuleSource value ----
Now, this code would work if /* */ were ignored by all sieve parsers,
otherwise we would have to translate this code in some kind of
pre-processor for it to be transportable between implementations.
Anyway, you asked for what I'm thinking about, and so you got it. If
you have some other ideas in mind, I'm very interested in hearing them.
Sam
Tim Showalter wrote:
samr(_at_)Netscape(_dot_)COM (Sam Robertson) writes:
Anyone else have any thoughts on this? Is this something we might be
able to add to the next version of the draft?
I'm sorry I put off responding to this.
I'm not fond of it, but other than feature creep, I have no objection
to it. I would like to know, though, what you're hiding in comments.
If it's important enough to have in the script, it would seem to be
important enough to represent in the syntax.
Thanks...
Tim