Changing an SF field by clicking a link...

[Barry]

Okay, I have to go back to my day job, but I did hang one more bag on
the side of Semantic Forms, so I guess I'll float it up and see if
anyone else has a use for it.

(Daniel, you should cover your eyes now...)

I was looking for a way to change a field in an SF generated page with
a single click.

My SF Form generates pages whose wiki code looks like this:

{{Purpose
|Purpose Type=Objective
|Planning Cycle=FY09
|Status=Draft
|Priority=High
|Business Unit=Operations
|Start Date=1-Jan-2009
|End Date=31-Dec-2009
|Added on=2008-08-27T14:58:56
|Added by=David Towne
}}
Department Objective: Reduce Wait time for Outpatient Registration to
< 4 minutes


As you'll notice the "Status" of this "Purpose" (third parameter) is
"Draft".

After my users have created dozens of objectives, I wanted to present
the ones in "Draft" status in a list so that the user could easily
change their Status to "Submitted" and ultimately strategic planners
and business unit heads would see see a list of "Submitted" entries
and change the Status to "Active", "Rejected", "Deferred", etc.

So I wrote a Special Page called TemplateCallUpdate (see code body
below)

It expects to be called with a URL that looks like this:

...index.php?
title=Special:TemplateCallUpdate&page=Page_Name&template=Purpose&field=Status&value=Submitted

If the page "Page_Name" exists and it contains a template call of
"Purpose" and that call contains a field of "Status", it changes the
value of Status to "Submitted". If the "Status" field doesn't exist,
TemplateCallUpdate adds it with a value of "Submitted".

Pretty simple concept, but it does change the Wiki text directly. I'm
new to Wiki coding, so I don't know if I broke any written or
unwritten rules or guidelines about what Special Pages should and
shouldn't do, but c'est la vie.

In fact the reason I have been trying to use embedded parser function
calls in #arraymap was to dynamically build the list of strategic
planning elements with their associated links to TemplateCallUpdate
whose semantic properties matched the Stakeholder characteristics of
the current user.

The "UI" I'm shooting for is a list like this, where the page name is
the first item in each row, the current status is in parentheses and
the available options follow as links to the TemplateCallUpdate:

Improve Patient Satisfaction (Active) Reject Defer

Improve patient safety (Submitted) Approve Reject Defer

Convert imaging system to digital (Draft) Submit

Open new surgical theater in Hampton (Draft) Submit


Anyway, if there's a better way to do this, I wasn't able to find it.
So here's the source for TemplateCallUpdate.php:

<?php
# Alert the user that this is not a valid entry point to MediaWiki if
they try to access the special pages file directly.
if (!defined('MEDIAWIKI')) {
echo <<<EOT
To install my extension, put the following line in LocalSettings.php:
require_once( "\$IP/extensions/TemplateCallUpdate/
TemplateCallUpdate.php" );
EOT;
exit( 1 );
}

$wgExtensionCredits['specialpage'][] = array(
'name' => 'Template Call Update',
'version' => 0.1,
'author' => 'Barry Welch <barry...@ps.net>',
'description' => 'This MediaWiki extension replaces template
parameter values in the specified page. ',
'url' => 'http://www.pscwiki.com/wiki/index.php?
title=Extension:Template_Call_Update'
);


$dir = dirname(__FILE__) . '/';

$wgAutoloadClasses['TemplateCallUpdate'] = $dir .
'TemplateCallUpdate_body.php'; # Tell MediaWiki to load the extension
body.
$wgExtensionMessagesFiles['TemplateCallUpdate'] = $dir .
'TemplateCallUpdate.i18n.php';
$wgSpecialPages['TemplateCallUpdate'] = 'TemplateCallUpdate'; # Let
MediaWiki know about your new special page.



Here's the source for TemplateCallUpdate_body.php:

<?php
function efRunTemplateCallUpdate( $par ) {
TemplateCallUpdate::execute( $par );
}

class TemplateCallUpdate extends SpecialPage {
function TemplateCallUpdate() {
SpecialPage::SpecialPage("TemplateCallUpdate", '',
true, 'efRunTemplateCallUpdate');
wfLoadExtensionMessages('TemplateCallUpdate');
}

function execute($par = '') {
global $wgUser, $wgOut, $wgRequest, $wgParser ;

$this->setHeaders();

$page_name = $wgRequest->getVal('page');
$template_name = $wgRequest->getVal('template');
$field_name = $wgRequest->getVal('field');
$field_value = $wgRequest->getVal('value');

$wgOut->setPageTitle(wfMsg('templatecallupdate_title', $field_name,
$field_value, $page_name));

if ( ! $page_name || ! $template_name || ! $field_name ) {
// print an error message
$wgOut->addHTML( "<p class='error'>" .
wfMsg('templatecallupdate_errbadparam', $page_name, $template_name,
$field_name) . '</p>');

$wgOut->addHTML( '<p>' . wfMsg('templatecallupdate_page' ,
$page_name ) . '</p>'
. '<p>' . wfMsg('templatecallupdate_template',
$template_name) . '</p>'
. '<p>' . wfMsg('templatecallupdate_field' ,
$field_name ) . '</p>'
. '<p>' . wfMsg('templatecallupdate_value' ,
$field_value ) . '</p>' );

return;
}

$wgOut->addHTML( '<p>' . wfMsg('templatecallupdate_page' ,
$page_name ) . '<br />'
. wfMsg('templatecallupdate_template',
$template_name) . '<br />'
. wfMsg('templatecallupdate_field' ,
$field_name ) . '<br />'
. wfMsg('templatecallupdate_value' ,
$field_value ) . '</p>' );


$page_title = Title::newFromText($page_name);

if (! isset($page_title)) {
$wgOut->addHTML( '<p class="error">' .
wfMsg('templatecallupdate_errnotitleobj', $page_name) . '</p>');

return;
}

if( ! $page_title->exists() ) {
$wgOut->addHTML( '<p class="error">' .
wfMsg('templatecallupdate_errnopage', $page_name) . '</p>');

return;
}

$page_article = new Article($page_title);
$page_content = $page_article->fetchContent(0);

if (! $page_content) {
$wgOut->addHTML( '<p class="error">' .
wfMsg('templatecallupdate_errnocontent', $page_name) . '</p>');

return;
}

$out = $page_content; // Default to the original page content

if (preg_match("/^(.*\\{\\{" . $template_name . "\\s*(?:\\|.+)*\\|\
\s*)(" . $field_name . ")(\\s*=\\s*)([^\\}\\|\\n\\r]*)(.+)$/ms",
$page_content, $matches )) {

$out = $matches[1];
$out .= $matches[2];
$out .= '=';
$out .= $field_value;
$out .= $matches[5];

$summary = wfMsg( 'templatecallupdate_chgresult', $template_name,
$field_name, $matches[4], $field_value );

$page_article->doEdit( $out, $summary );

$wgOut->addHTML( '<p>' . $summary . '</p>' );

}
elseif (preg_match("/^(.*\\{\\{" . $template_name . "\\s*)([|}].+)$/
ms", $page_content, $matches )) {

$out = $matches[1];
$out .= '|' . $field_name . '=' . $field_value . "\n";
$out .= $matches[2];

$summary = wfMsg( 'templatecallupdate_addresult', $template_name,
$field_name, $field_value );

$page_article->doEdit( $out, $summary );

$wgOut->addHTML('<p>' . $summary . '</p>');

}
else
{
$wgOut->addHTML('<p class="error">' .
wfMsg('templatecallupdate_errresult', $template_name, $field_name,
$page_name) . '<br /><i>' . wfMsg('templatecallupdate_errresult2') .
'</i></p>');

return;
}

// Now, grab the latest revision and update the Semantic Mediawiki
Properties
$options = new ParserOptions();

if ( smwfIsSemanticsProcessed($page_title->getNamespace()) ) {
$revision = Revision::newFromTitle( $page_title );
if ( $revision === NULL ) continue;
$wgParser->parse($revision->getText(), $page_title, $options,
true, true, $revision->getID());
SMWFactbox::storeData(true);
$wgOut->addHTML('<p>' . wfMsg('templatecallupdate_updated') . '</
p>');
} else {
smwfGetStore()->deleteSubject($page_title);
$wgOut->addHTML(wfMsg('<p>' . 'templatecallupdate_cleared') . '</
p>');
}

$skin = $wgUser->getSkin();
$pageLink = $skin->makeKnownLinkObj( $page_title );
$wgOut->addHTML( '<p>' . wfMsg('templatecallupdate_viewpage') .
$pageLink . '</p>' );
}
}


Here's the source for TemplateCallUpdate.i18n.php:

<?php
$messages = array();
$messages['en'] = array(
'templatecallupdate' => 'Template Call Update',
'templatecallupdate_title' => 'Setting $1 to $2 in $3',
'templatecallupdate_errnotitleobj' => 'Error: Title Object not
returned for Page "$1".',
'templatecallupdate_errnopage' => 'Error: Page "$1" does not
exist',
'templatecallupdate_errnocontent' => 'Error: Page "$1" has no
content',
'templatecallupdate_errbadparam' => 'Error: Page ("$1"), template
("$2") or field name ("$3") is empty',
'templatecallupdate_chgresult' => 'Changed the value of $1:$2
from "$3" to "$4".',
'templatecallupdate_addresult' => 'Added $1:$2 with a value of
"$3".',
'templatecallupdate_errresult' => 'Unable to find field: $1:$2
on page: $3.',
'templatecallupdate_errresult2' => 'Please write down what you
were attempting to do, copy or save this message, and contact the site
administrator.',
'templatecallupdate_updated' => 'Properties updated',
'templatecallupdate_cleared' => 'Properties cleared',
'templatecallupdate_page' => 'Page name = $1',
'templatecallupdate_template' => 'Template name = $1',
'templatecallupdate_field' => 'Field name = $1',
'templatecallupdate_value' => 'Field value = $1',
'templatecallupdate_viewpage' => 'View updated page: ',
);

[Yaron Koren]

Wow, this is amazing. It's not often that you get a whole new extension by email. :) The concept of being able to update data in pages from a single interface is a very powerful one, and if/when it's implemented I think it'll be a big step forward for the whole SMW system. Yes, it's somewhat unorthodox for a MediaWiki interface to allow making a set of changes to other pages, but it's not unprecedented: if nothing else, my own Replace Text extension (http://www.mediawiki.org/wiki/Extension:Replace_Text) does the same thing, and I haven't heard any complaints about that. The bigger questions, I think, are about the "wrapper" for this functionality, i.e. the special page or other interface that would let users choose which pages to make changes to: would access to that page be restricted to some kind of administrative group, or would there be a more complex system of access control, letting users in different groups make different changes? And how would the set of fields and allowed values be defined, especially if there was only a specific allowed workflow for certain fields, like that 'draft' could be turned into 'published' but not the other way around?

I actually had a conversation a while ago with a few people from Creative Commons, who are also on this list, about such functionality - I hope it's okay to mention that. :) The idea was to be able to define an "action", which would most likely be the changing of one or more template fields on a page - such an action could show up as a new tab on a page, or (in the case of this code) in some sort of external interface. I don't remember how much of this came up during our conversation, and how much I thought up later, but my thought was that one could have a new namespace, called "Action:", where a page in the namespace could look like this (to conform to your example, let's imagine it's called "Action:Approve"):

[[Modifies template:Purpose]]
[[Modifies template field:Status]]
[[Requires value:Submitted]]
[[Sets new value:Approved]]

...and it could even have calls like:
[[Allowed for user group:Sysops]]
[[Notify user::TheBoss]]

Then, the page "Category:Purposes" would have declarations like:

[[Has allowed action::Action:Submit]]
[[Has allowed action::Action:Approve]]
etc.

Then, this "wrapper" page would let the user choose from among all the categories, and, for each one, let the user perform whatever allowed actions there were for each page in that category. That might consist of some tricky, but doable, on-the-fly page parsing, and then of course links to the Template Call Update code to perform the actual action.

What do you think? This set of code you've created could be the beginning of some true workflow functionality, which I think would be a really worthwhile addition to the whole system; but there are probably lots of different ways to go about it.

-Yaron

[Sergey Chernyshev]

This actually sounds very close to what Page Object Model (POM) extension/library was created for - to be able to simplify editing parts of the page, concentrating template parameter values. I successfully wrote extensions for editing one field within the template in one click which took just a few lines of code (and include of POM). Also POM has actually MW extension part in it that extends MediaWiki API which can be used in AJAX calls or remote script calls (that what I use in some data processing scripts on backend).

Check it out here: http://www.mediawiki.org/wiki/Extension:Page_Object_Model
Page itself describes more functionality then is actually available so it's better to look at the code:
http://mediawiki-page-object-model.googlecode.com/svn/trunk/

Does it sound like something that can help you?

            Sergey

--
Sergey Chernyshev
http://www.sergeychernyshev.com/

[Barry]

I just took a look at Sergey's Page Object Model. I like it. It's
parsing model
is certainly an improvement over my RegEx lookup. I'm going to
rewrite
my TemplateCallUpdate extension to use it. It should solve my problem
with
duplicate parameter names across different templates.

I think I'll also adopt the #formlink query string parameter value
setting
syntax "template-name[field-name]=field-value" in place of
TemplateCallUpdate's
"template=template-name&field=field-name&value=field-value" format.

I just started looking through the POM code. (Nice object model by
the way...)
I do have a few questions. Although I don't think this will be an
issue for its use
within Semantic Forms pages, can POM handle the ambiguous brace
parsing
that occurs with combined two-brace and three-brace symbols?

Here's an example:

Template:Test1 accepts a parameter "pagename"

Could I use POM to parse the page Template:Test1 and
manipulate templates that contain embedded parameters.


Let's say Template:Test1 contains:

==TEST1==
{{Test2|abc=3|xyz={{{pagename|{{PAGENAME}}}}}}}

Can POM parse the parameter xyz?

I guess this may be a dumb question, because I'm not
aware of an example that actually impacts the parsing
of normal pages with embedded template calls. My mind
just jumps automatically to the boundary conditions and
I've been impressed with the MediaWiki parsing challenge
of mixed two and three brace expressions.

Thanks Sergey. Great stuff.

- Barry


On Sep 4, 1:19 pm, "Sergey Chernyshev" <sergey.chernys...@gmail.com>
wrote:

> This actually sounds very close to what Page Object Model (POM)
> extension/library was created for - to be able to simplify editing parts of
> the page, concentrating template parameter values. I successfully wrote
> extensions for editing one field within the template in one click which took
> just a few lines of code (and include of POM). Also POM has actually MW
> extension part in it that extends MediaWiki API which can be used in AJAX
> calls or remote script calls (that what I use in some data processing
> scripts on backend).
>
> Check it out here:http://www.mediawiki.org/wiki/Extension:Page_Object_Model
> Page itself describes more functionality then is actually available so it's
> better to look at the code:http://mediawiki-page-object-model.googlecode.com/svn/trunk/
>
> Does it sound like something that can help you?
>
>             Sergey
>

> >>        'author' => 'Barry Welch <barry.we...@ps.net>',

> >>        'description' => 'This MediaWiki extension replaces template
> >> parameter values in the specified page. ',
> >>        'url' => 'http://www.pscwiki.com/wiki/index.php?

> >> title=Extension:Template_Call_Update<http://www.pscwiki.com/wiki/index.php?title=Extension:Template_Call_U...>
> >> '

> ...
>
> read more »

[Barry]

Yaron,

I think that's a great idea. I've been trying to tackle the problem
in a similar manner, except that I've been looking at it from an
application focus.

TemplateCallUpdate is a very low-level tool, with no intelligence
around why or whether a field should be changed or inserted. By the
way, this one has a number of limitations in the actual replacement
technique. It can be flummoxed by something as simple as two
templates with the same optional field name.

{{template1
|f1=5
|f2=5
}}

{{template2
|f3=8
}}

A call to set template1’s “f3” field value would probably change
template2’s field instead.

Hopefully, switching to Sergey's Page Object Model (POM) will
eliminate that problem.

Now from an application-level, what I’ve setup is a structure that
looks like this:

Pages in the [[Category:Stakeholder]] represent users of the
application.

Each Stakeholder page contains the following properties:
[[Stakeholder User::wiki user 1]]
[[Stakeholder User::wiki user 2]]
[[Stakeholder User::wiki user 3]]

(Normally, there is only one Stakeholder per wiki user, but I have to
support admin staff...)

[[Approves Page Type::Goal]]
[[Approves Page Type::Objective]]

[[Approves Department::Operations]]
[[Approves Department::Security]]

The various pages in the system contain properties like these:
[[Page Type:: Goal]] or [[Page Type::Objective]] or [[Page
Type::Task]], etc.
[[Department::Customer Service]] or [[Department::Operations]], etc.

The [[XXXX::]] properties and their corresponding [[Approves XXXX]]
properties share common sets of values. The concept is that an
[[Approves XXXX::]] property is a “subscription” to the
“published” [[XXXX::]] page property.

Once a set of pages have been entered, a user can bring up a list of
all the Stakeholders he/she supports.

I use an {{#ask: }} query to pass the list of Page Types and the list
of Departments that each Stakeholder supports to a transcluded
template.

The template uses embedded #arraymaps to execute #ask queries for
each Page Type/Department combination producing a list of page names,
current page status and the transclusion of another template that
contains a #switch-based mapping of page statuses to approved
actions. The actions are implemented as links to the
TemplateCallUpdate page.

So, in a nutshell, I use Pub/Sub techniques for the identification of
responsibilities and a hardcoded switch statement to manage the state
transitions of the workflow. There are lots of security holes. The
system is not flexible. And, changing the workflow requires a
“programming” change. But, it seems to be working well enough to
pilot for a few clients.

If someone comes up with a more flexible approach, I would definitely
consider moving to it. I may also consider trying to implement a more
configurable version of my approach employing some of the techniques
you suggested.

Ah, with just a little more time and a little more talent, what
wonderful things I could accomplish. ;-)

- Barry

> >        'author' => 'Barry Welch <barry.we...@ps.net>',

> >        'description' => 'This MediaWiki extension replaces template
> > parameter values in the specified page. ',
> >        'url' => 'http://www.pscwiki.com/wiki/index.php?

> > title=Extension:Template_Call_Update<http://www.pscwiki.com/wiki/index.php?title=Extension:Template_Call_U...>
> > '

> ...
>
> read more »

[mitchelln]

This is really cool stuff. Well done!

Cheers
Neill.

> ...
>
> read more »

[Chuwiey]

Barry,
This is great stuff... thank you...

If I may suggest... I think we are at that point where we need to have
a proper discussion about conditionals in forms.. especially now, when
you've introduced workflow options for a field... The user interface
portion of it would definitely be something important to figure
out...

-Chuwiey

> ...
>
> read more »

[Yaron Koren]

What do you mean by that - what's an example of a conditional in a form?

[Sergey Chernyshev]

What can I say - POM was created to shield you against this kind of issues - I don't think it handles all of the cases, but it definitely handles parameters with variables/template calls within them.

But at this point POM doesn't treat parameters as nested object model, just as strings - you can definitely use another POM instance to parse parameters, I presume, but it doesn't do that now. Ideally it should parse them into a children tree and know how to work with them, but it's for the future development.

BTW, there are a few tests in a test folder so you can take a look at what's being tested for right now. To run the tests you'll need PHPUnit and just run

          make test

in the root of the project.

          Sergey

[Chuwiey]

Yaron -
Well, a basic conditional in a form is a request that has been around
for a long time but has no relevance to these "new" features - i.e you
choose option x in field y and field z appears... (for instance, you
choose US for country and the state field appears)
but now that fields have different approved values, a workflow and can
be changed on the fly, you could also have conditionals based on
those... ie. you change a template field called status from "Needs
Approval" to "Approved" and now you want a different form to edit the
page with.. or for instance, you might want to add a template to the
page based on that change (though that's less connected to SF)...

Sergey -
Was what you wrote directed at what I said? Because it definitely
seems like what you wrote is relevant to making "smart" page
models...

-Chuwiey

On Sep 9, 1:52 pm, "Sergey Chernyshev" <sergey.chernys...@gmail.com>

> ...
>
> read more »

[Yaron Koren]

Well, it looks like this thread has split up into at least three
separate discussions. On the subject of conditionals, I've thought
about allowing for conditional elements of the type you describe, and
I think the hard part is actually defining that set of conditions
through the wiki. But if you have any thoughts about that, I'd like to
hear them.

-Yaron

[Chuwiey]

Hi Yaron,

Well this definitely required some thought, and obviously it could use
improvement, but this is what I was thinking:

In-Form conditionals:

Form:Example ->

{{{info|add title=Example|edit title=Example}}}
{{{for template|Example|label=Example}}}

//Conditionals for an uploadable field (Expanded View):
{{{field
|image
|uploadable
|size=21
|autocomplete
|remote autocompletion
|conditional <<
filledin: show field[name];
multiple: gallery;
>>
}}}

//Conditional for a regular field (Unexpanded view):
{{{field|name|mandatory|size=50|autocomplete|remote autocompletion|
conditional <<filledin:set fieldname firstletter; toolong(50): show
tag[#id];>>}}}

//Conditional for a boolean (expanded):
{{{
field
|HasParent
|input type=checkbox
|conditional <<
true: show field[parent_name];
false: hide field[parent_name];
>>
}}}
{{{field|parent_name|size=50|remote autocompletion}}}

//Conditional for dropdown (expanded):
{{{
field
|country //drop down with a list of countries
|mandatory
|conditional <<
United States of America: show field[stateUS];
Canada: show field[stateCanada];
default: hide field[stateCanada,stateUS];
}}}
{{{field|stateUS}}} //dropdown with a list of us states
{{{field|stateUS}}} //dropdown with a list of canadian states

{{{end template}}}


Ok, so the idea is basically having inline keywords relate to some
functions (for instance, the show/hide keywords)... and the syntax
would be:
conditional <<
condition: actionkeyword affectswhat;
>>
condition - can be the value of the field (checked via javascript), or
any number of magic key words (such as filledin and true) - preferably
we would create a easy way to define new keywords in php or javascript
- or something like "default" which would mean, any value different
from those above...

actionkeyword - can be any number of magic keywords which signify an
action...

affectswhat - a field, html tag and so on...

---- End of In-Form Example ----

Template Conditionals:

Example page-

I am a page that uses the example template and the #conditionals
parser function...

{{example
|var1 = foo
|var2 = bar
|var3 = foobar
}}

{{#conditional:var1:=foo(set page[ategories[category:name]]; set
page[template[example[var4[false]]]])}}

//As you can see this really draws on Sergey's POM (though I don't
know if the syntax would is the same) but basically you would be able
to access different elements in a page based on their nesting or
type...

Well, that's my two cents worth..

-Chuwiey

On Sep 9, 4:22 pm, "Yaron Koren" <yaro...@gmail.com> wrote:
> Well, it looks like this thread has split up into at least three
> separate discussions. On the subject of conditionals, I've thought
> about allowing for conditional elements of the type you describe, and
> I think the hard part is actually defining that set of conditions
> through the wiki. But if you have any thoughts about that, I'd like to
> hear them.
>
> -Yaron
>

> ...
>
> read more »

[Chuwiey]

Two more comments on In-Form conditionals... it might even be possible
to change the template the form will publish to based on a
conditional.. or even redirect you to a different form based on
something like that... (just a thought)

Also, we might want to consider allowing sysops or bureaucrats to
define magic keywords in a wiki page...

-Chuwiey

> ...
>
> read more »

[Sergey Chernyshev]

No, I was actually replying to Barry ;)

As for conditionals, I agree with Yaron - it's not that easy to define conditionals based on wiki data. If forms go beyond just plain declarations, it probably requires real scripting language like JavaScript to control that, but implementing such functionality is a significant challenge by itself ;)

                 Sergey

[Chuwiey]

Hey Sergey,

Yeah, there was no question in my head about it requiring a scripting
language for control... I was just offering a possible method for
defining these conditions inside the forms... :)

-Chuwiey


On Sep 11, 10:24 am, "Sergey Chernyshev" <sergey.chernys...@gmail.com>
wrote:

> No, I was actually replying to Barry ;)
>
> As for conditionals, I agree with Yaron - it's not that easy to define
> conditionals based on wiki data. If forms go beyond just plain declarations,
> it probably requires real scripting language like JavaScript to control
> that, but implementing such functionality is a significant challenge by
> itself ;)
>
>                  Sergey
>

> ...
>
> read more »