Hey Sergey,

Yeah, there was no question in my head about it requiring a scripting
language for control... I was just offering a possible method for
defining these conditions inside the forms...  :)

-Chuwiey


On Sep 11, 10:24 am, "Sergey Chernyshev" <[EMAIL PROTECTED]>
wrote:
> No, I was actually replying to Barry ;)
>
> As for conditionals, I agree with Yaron - it's not that easy to define
> conditionals based on wiki data. If forms go beyond just plain declarations,
> it probably requires real scripting language like JavaScript to control
> that, but implementing such functionality is a significant challenge by
> itself ;)
>
>                  Sergey
>
> 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
>
> ...
>
> 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