Okay, wow - your hack looks interesting, though I confess that I don't understand it in the slightest. :)

Here's documentation on the existing "unique number" feature:


By "anonymized", do you mean that you're generating a random number? If so, is there a reason for doing that, as opposed to going with the lowest unique number, i.e. incrementing the number every time?

By the way, I just realized that this whole discussion has taken place on the SMW-users mailing list. For future discussions, it would be better to have them on the SF list.


On Thu, Mar 26, 2009 at 6:21 AM, Samuel Lampa <samuel.lampa.l@rilnet.com> wrote:
Thanks for your reply! Comments follow.

Yaron Koren skrev:

Samuel - thanks a lot; this looks good - it'll probably go into the next version of SF.

Nice, thanks!

This code doesn't allow for setting the filename based on the values of other fields in the form, as you first suggested; which isn't that surprising: as you probably discovered while writing the code, getting those values is very difficult, since they haven't been submitted via form yet.

Yes, very true.

You'd probably have to use some strange combination of Javascript and PHP, and I don't know if it's even possible. I certainly don't know if it's desirable, either, since you're basing the name on values that the user may not have even entered yet.

For now, I actually managed to create a hack that accomplishes what I want, though it's not optimal. A description of it follow:

I have a template with a "submit job" button (that links to a form). In this same template a GUID is created (via a custom extension), stored in a variable. When the button is clicked, it is sent to the form both in the page name parameter and as a custom parameter "sfDestFile", which I managed to pass with it by simply appending it to another parameter that is sent to the form, together with an "&" (quite hacky as you can see...).

 {{#formlink:Job|New Job|button|Job[Auto title]={{#var:GUID}}&sfDestFile={{#var:GUID}} }}

Then in the form, I'm using a placeholder 'destination_filename' for the "destination filename" parameter, in the defenition of the uploadable field, like so:

 {{{field|Job data|uploadable|destination filename=destination_filename|default= }}}

This placeholder is then replaced by the extra parameter "sfDestFile" that was sent to the form. This is done through the following hack in SF_FormPrinter.inc (diffcode):

Replacecode in SF_FormPrinter.inc, as diff:

Index: includes/SF_FormPrinter.inc
--- includes/SF_FormPrinter.inc (revision 47204)
+++ includes/SF_FormPrinter.inc (working copy)
@@ -164,6 +164,13 @@
     $form_def = $wgParser->parse($form_def, $this->mPageTitle,
+    // A general replacer for placeholder of destination filename // SHL
+    if ( $wgRequest->getVal('sfDestFile') != "" ||
$wgRequest->getVal('sfDestFile') != null ) {
+    $destination_filename_placeholder = '/destination_filename/';
+    $destination_filename = $wgRequest->getVal('sfDestFile') . ".txt";
+    $form_def =
+    }

   // turn form definition file into an array of sections, one for each
   // template definition (plus the first section)

Maybe it would be possible to add a more general ability to specify, from the submit "button", the parameters of fields in the form defenition, so that one could e.g. create a submitbutton like this (here, "destination filename" is a parameter of the field "Job data"):

 {{#formlink:Job|New Job|button|Job[Auto title]={{#var:GUID}}|Job[Job data][destination filename]={{#var:GUID}} }}

Just a though... Any ideas about a better solution to my problem, than my hack above are very welcome.

Thinking about it now, I can only think of two variables that it might make sense to add handling for: "<page name>" and "<unique number>". And I'm not sure if that first one is worth supporting either, since the page name might not have been set yet, if you're using the "one-step" form creation. The second one probably makes sense, though, and could probably use similar code to the handling in the "{{{info|page name=" field.


Ok, "<unique number>" is that revision id, no? Or is it an SMW concept?
Sounds a bit interesting since generating unique Id's is what I'm doing (though I also want them anonymized, so I'm using GUID:s)

// Samuel