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 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>' );
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to