Version 0.5.3 - new 'sf_inputform' parser function, etc.

[Yaron Koren]

Hi all,

Version 0.5.3 of Semantic Forms is now released. This version has a number of changes and bug fixes; most importantly, there's a new parser function that allows for a more flexible interface for adding data. Instead of having to rely on the 'AddPage' page, you can now add a page-entry input anywhere, by adding the tag {{#sf_forminput:}} to any page. If you're familiar with the MediaWiki "InputBox" extension, this function works in a similar way, by outputting an HTML form that allows the user to enter a page name (though this one is a parser function, as opposed to an HTML-style tag like InputBox). When the user enters the page name, they are redirected to an actual form at either 'AddData' or 'EditData', depending on whether or not the page already exists.

The general function call looks like this:

{{#sf_forminput|form_name|size|value|button_text|query_string}}

All arguments are optional. form_name is the name of the SF form to be used; if it is left empty, a dropdown will appear, letting the user chose among all existing forms. size represents the size of the text input (default is 25), and value is the starting value of the input (default is blank). button_text is the text that will appear on the "submit" button, and query_string is the set of values that you want passed in through the query string to the form.

You can see examples of this parser function at work here:

http://discoursedb.org/wiki/Forminput_parser_function_demo

The third example is interesting: it's a usage suggested by Sergey that uses an inline query to set the preload value to be the last author on the site alphabetically - currently, that's Zbigniew Brzezinski. It shows that this function can take in input from inline queries, other parser functions, etc. How much potential usage there is for this dynamic stuff I don't know, but the capability is there.

This new function should solve a few problems: it allows for placing many inputs on a single page, and it allows administrators to specify the text around the input to be whatever they want, instead of being stuck with the random few sentences I put on "AddPage".

This version also contains a number of other changes and bug fixes:

- The "Special:Forms" page was listing form pages that were just redirects; now it ignores them.
- The "AddPage" page now allows you to not specify a form; if you don't, a dropdown for selecting the form appears, just as with the sf_forminput function.
- There was a bug where, when un-logged-in users tried to save a page directly from a form, they got a warning reading "loss of session data". Since most of your wikis, I believe, require a login for editing, I don't think many people saw the bug; but it's fixed now.
- Sandra's discovered bug for the "edit with form" tab is now fixed; if a page doesn't exist, the tab links to "AddData" instead of "EditData".

-Yaron

[Wheresmytab]

The parser function triggers the following php "Notices" when used
along with DPL

<b>Notice</b>: Undefined offset: 1 in <b>/disk/wiki/sandbox/
extensions/SemanticForms/includes/SF_ParserFunctions.php</b> on line
<b>58</b><br />
<br />
<b>Notice</b>: Use of undefined constant noparse - assumed 'noparse'
in <b>/disk/wiki/sandbox/extensions/SemanticForms/includes/
SF_ParserFunctions.php</b> on line <b>66</b><br />

Perhaps not everyones server has Notice warnings turned on? I'll try
and track these down too.

~wheresmytab

[Yaron Koren]

That's interesting - I'm guessing the relevant part of that line should read

'noparse' => 'true'

instead of what it is now, which is

noparse => true

I saw different variations in the different online examples I looked at; and for me they all worked so I didn't know which to go with. Let me know if that improves the situation. Thanks very much also for your help n the FormEditTab class; I'll look more at that later.

-Yaron

[Yaron Koren]

One small correction: I realized I mistyped the general function call in the original email. It should actually be called like this:

{{#sf_forminput:form_name|size|value|button_text|query_string}}

The first pipe should have been a colon.

-Yaron

[Wheresmytab]

'noparse' => 'true' did eliminate one of the Notices.
The second is more tricky.
The parser function has this loop that extracts the query string
variables.

foreach ($query_components as $component) {
list($key, $val) = explode('=', $component);
$str .= ' <input type="hidden"
name="' . $key . '" value="' . $val . '">' . "\n";
}
The second line is line 58 which makes the error:
Undefined offset: 1 in /disk/wiki/sandbox/extensions/SemanticForms/
includes/SF_ParserFunctions.php on line 58

It must be in the list assignment function, but I dont see how.
Thoughts?
~wheresmytab

On Aug 21, 5:31 pm, "Yaron Koren" <yaro...@gmail.com> wrote:
> That's interesting - I'm guessing the relevant part of that line should read
>
> 'noparse' => 'true'
>
> instead of what it is now, which is
>
> noparse => true
>
> I saw different variations in the different online examples I looked at; and
> for me they all worked so I didn't know which to go with. Let me know if
> that improves the situation. Thanks very much also for your help n the
> FormEditTab class; I'll look more at that later.
>
> -Yaron
>

[Yaron Koren]

Oh, I didn't even notice that first error message. That's poor coding on my part - it's complaining because "$component" might not have an equals sign. There should be an easy fix, but I'll test it out myself first and then let you know.

-Yaron

On 8/21/07, Wheresmytab <where...@gmail.com> wrote:

[Wheresmytab]

I put an @ on the line to silence the Notice for now.

Does the parser function support passing variable names through the
CreatePage, like we talked about before?

I tried it on your wiki but couldnt make it work.
http://discoursedb.org/w/index.php?title=Talk:Forminput_parser_function_demo

~wheresmytab

On Aug 21, 7:30 pm, "Yaron Koren" <yaro...@gmail.com> wrote:
> Oh, I didn't even notice that first error message. That's poor coding on my
> part - it's complaining because "$component" might not have an equals sign.
> There should be an easy fix, but I'll test it out myself first and then let
> you know.
>
> -Yaron
>

[Sergey Chernyshev]

Great news! I'll start eliminating inputbox extensions on TechPresentations.

On 8/21/07, Wheresmytab < where...@gmail.com> wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Semantic Forms" group.
To post to this group, send email to semanti...@googlegroups.com
To unsubscribe from this group, send email to semantic-form...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~--

[Yaron Koren]

No, unfortunately you still can't pass in those variable names - I should have mentioned that. The only values you can pass in at the moment, through either the AddPage page or this function, are "namespace" and "preload". The problem is that, if you just send over every query value to 'AddData', the URL will get cluttered with a lot of hidden variables that will probably just confuse users. There should be a way to get around this, but I haven't figured it out yet.

-Yaron

On 8/21/07, Wheresmytab <where...@gmail.com> wrote:

[Sergey Chernyshev]

I hit another problem - looks like your code conflicts with some patches to MediaWiki I made some time ago. I know it's bad practice to apply patches to core, but still... I'll try to figure out what's going on with it.