This is really cool stuff. Well done!
Cheers
Neill.
On Sep 6, 7:25 pm, Barry <[EMAIL PROTECTED]> wrote:
> 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. ',
> > >
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
