What do you mean by that - what's an example of a conditional in a form?
On Tue, Sep 9, 2008 at 11:07 AM, Chuwiey <[EMAIL PROTECTED]> wrote:
>
> 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 semantic-forms@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
