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
On Sep 9, 7:35 am, mitchelln <[EMAIL PROTECTED]> wrote:
> 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
