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
On Tue, Sep 9, 2008 at 2:31 PM, Chuwiey <[EMAIL PROTECTED]> wrote:
>
> 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" <[EMAIL PROTECTED]>
> wrote:
>> 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
>>
>> On Sat, Sep 6, 2008 at 2:08 PM, Barry <[EMAIL PROTECTED]> wrote:
>>
>> > 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" <[EMAIL PROTECTED]>
>> > 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
>>
>> > > On Fri, Aug 29, 2008 at 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
>>
>> ...
>>
>> 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
-~----------~----~----~----~------~----~------~--~---
