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
-~----------~----~----~----~------~----~------~--~---
