Hi Yaron,
Well this definitely required some thought, and obviously it could use
improvement, but this is what I was thinking:
In-Form conditionals:
Form:Example ->
{{{info|add title=Example|edit title=Example}}}
{{{for template|Example|label=Example}}}
//Conditionals for an uploadable field (Expanded View):
{{{field
|image
|uploadable
|size=21
|autocomplete
|remote autocompletion
|conditional <<
filledin: show field[name];
multiple: gallery;
>>
}}}
//Conditional for a regular field (Unexpanded view):
{{{field|name|mandatory|size=50|autocomplete|remote autocompletion|
conditional <<filledin:set fieldname firstletter; toolong(50): show
tag[#id];>>}}}
//Conditional for a boolean (expanded):
{{{
field
|HasParent
|input type=checkbox
|conditional <<
true: show field[parent_name];
false: hide field[parent_name];
>>
}}}
{{{field|parent_name|size=50|remote autocompletion}}}
//Conditional for dropdown (expanded):
{{{
field
|country //drop down with a list of countries
|mandatory
|conditional <<
United States of America: show field[stateUS];
Canada: show field[stateCanada];
default: hide field[stateCanada,stateUS];
}}}
{{{field|stateUS}}} //dropdown with a list of us states
{{{field|stateUS}}} //dropdown with a list of canadian states
{{{end template}}}
Ok, so the idea is basically having inline keywords relate to some
functions (for instance, the show/hide keywords)... and the syntax
would be:
conditional <<
condition: actionkeyword affectswhat;
>>
condition - can be the value of the field (checked via javascript), or
any number of magic key words (such as filledin and true) - preferably
we would create a easy way to define new keywords in php or javascript
- or something like "default" which would mean, any value different
from those above...
actionkeyword - can be any number of magic keywords which signify an
action...
affectswhat - a field, html tag and so on...
---- End of In-Form Example ----
Template Conditionals:
Example page-
I am a page that uses the example template and the #conditionals
parser function...
{{example
|var1 = foo
|var2 = bar
|var3 = foobar
}}
{{#conditional:var1:=foo(set page[ategories[category:name]]; set
page[template[example[var4[false]]]])}}
//As you can see this really draws on Sergey's POM (though I don't
know if the syntax would is the same) but basically you would be able
to access different elements in a page based on their nesting or
type...
Well, that's my two cents worth..
-Chuwiey
On Sep 9, 4:22 pm, "Yaron Koren" <[EMAIL PROTECTED]> wrote:
> 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
