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
On Aug 29, 12:31 am, "Yaron Koren" <[EMAIL PROTECTED]> wrote:
> 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
>
> On Thu, Aug 28, 2008 at 8:15 PM, Barry <[EMAIL PROTECTED]> wrote:
>
> > 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 <[EMAIL PROTECTED]>',
> > '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...>
> > '
> > );
>
> > $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;
> > }
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Semantic Forms" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---
