Ah, that's true, I didn't think about the "edit with form" case. Well, for that, you could use #show, assuming the value is being stored semantically - and you could have an #ifexists call to tie the whole thing together, so that #urlget is called for new pages, and #show is called for existing pages. It's a hack, but it wouldn't require any custom development.

As for "parameters may not be defined from the beginning" - that's the central issue. New development would be required only if (a) they're not, and (b) there's more than one of them - since a single editable parameter can be handled by the "values dependent on" feature. So is that definitely the case, or are you just guessing that you might require this feature in the future?

-Yaron

On Mon, Oct 1, 2012 at 11:36 AM, Yury Katkov <katkov.juriy@gmail.com> wrote:
I need the first one. There are some problems with this
UrlGetParameters approach: it seems that it will work for article
creation using the #formlink but it will not work for article edition
using 'Edit with Form' button. Another problem is that the parameters
for allowed value set restrictions may not be defined from the
beginning.

Linking together pages inside the website section is typical example
of such feature. Am I right that the most frighting thing here is
making ask-queries in AJAX code?
-----
Yury Katkov



On Mon, Oct 1, 2012 at 7:16 PM, Yaron Koren <yaron@wikiworks.com> wrote:
> Hi,
>
> No, the two examples are different - the "silly" one involves two
> "substitions", based on editable fields, while the "real" one involves one
> substitution, directly from the query string. Can you clarify the
> discrepancy? What is the form that you actually need?
>
> -Yaron
>
>
> On Mon, Oct 1, 2012 at 11:11 AM, Yury Katkov <katkov.juriy@gmail.com> wrote:
>>
>> Hi Yaron!
>>
>> No, these two examples (the synthetic and silly flower example and the
>> real-world brainstorming example) are really the same.
>> What I need is to use the data that user put in the field1 as the
>> parameter of the query that defines the allowed values set in the
>> field2.
>>
>> Anyway, I'll try to clarify:
>> So the user edits the Flower Rose. He entered the Genus of Rose :
>> Rosa. He entered the color of Rose - for example Red. The field
>> 'related flowers' will be the listbox of all red flowers with genus
>> Rosa:
>>
>> {{field|related flowers|values from
>>
>> query=[[Category:$1]][[Color::$2]][[Owner::+]]|substitute=Flowers[Genus],Flowers[Color]|input
>> type=listbox}}
>>
>> -----
>> Yury Katkov
>>
>>
>>
>> On Mon, Oct 1, 2012 at 6:35 PM, Yaron Koren <yaron@wikiworks.com> wrote:
>> > Hi Yury,
>> >
>> > I don't understand - are your data needs more complex than what you put
>> > in
>> > that sample form definition code earlier? If so, can you revise that
>> > sample
>> > code to more accurately reflect what you want your form to look like?
>> >
>> > -Yaron
>> >
>> >
>> > On Mon, Oct 1, 2012 at 2:53 AM, Yury Katkov <katkov.juriy@gmail.com>
>> > wrote:
>> >>
>> >> Hi Yaron!
>> >>
>> >> There is no problem in passing the Session parameter I can use either
>> >> 'query string' parameter of the formlink or the urlget function.
>> >> In this Trend form my main problem is to restrict the set of possible
>> >> values which will be displayed in the "Related events" listboxes:
>> >> 1) All these values are pagenames for pages in Events category
>> >> 2) All these pages belongs to the same Session as the Trend, that I'm
>> >> currently looking at
>> >>
>> >> The same is for related Technologies: I want to link objects only
>> >> inside the session, so that the participants of the session "The
>> >> Future of Food" don't try to link there Trends and possible events
>> >> with objects from the Session "The future of titan manufacturing ".
>> >>
>> >> The two restrictions to possible values in the listbox I'have just
>> >> noted can be three or four; and all of them can be dependent on what
>> >> is currently entered in the form.
>> >> -----
>> >> Yury Katkov
>> >>
>> >>
>> >>
>> >> On Mon, Oct 1, 2012 at 4:26 AM, Yaron Koren <yaron@wikiworks.com>
>> >> wrote:
>> >> > Hi Yury,
>> >> >
>> >> > This sounds like a very different example - here the original,
>> >> > "source"
>> >> > field is just a hidden field that gets its value from the query
>> >> > string.
>> >> > In
>> >> > that case, I would think the ideal solution would be to use the
>> >> > UrlGetParameters extension, to directly use the query string value:
>> >> >
>> >> > https://www.mediawiki.org/wiki/Extension:UrlGetParameters
>> >> >
>> >> > I'm not entirely sure that this would work, because I don't remember
>> >> > which
>> >> > parts of the form syntax let you embed a parser function within them
>> >> > -
>> >> > but
>> >> > if it doesn't work, then getting it to work would seem like the
>> >> > simpler,
>> >> > and
>> >> > better, solution.
>> >> >
>> >> > -Yaron
>> >> >
>> >> >
>> >> > On Sun, Sep 30, 2012 at 3:41 PM, Yury Katkov <katkov.juriy@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Yaron!
>> >> >>
>> >> >> My example is surely very silly and synthetic so let's just forget
>> >> >> about the flowers
>> >> >> I'll try to explain the real problem I faced with in a Foresight
>> >> >> wiki.
>> >> >>
>> >> >> Here is my problem domain. There are several brainstorming sessions
>> >> >> about the forecasts on a distant future, all of them have different
>> >> >> topics. Each of those sessions has various objects as the results of
>> >> >> the brainstorming: future trends, possible technologies that may
>> >> >> appear in the future, possible important events. All these data are
>> >> >> loaded to the wiki using the semantic forms. After the brainstorming
>> >> >> ends, the participants can improve the objects, categorize them and
>> >> >> link them together.
>> >> >>
>> >> >> Here for example I have the Trend objects. I want to connect Trends
>> >> >> to
>> >> >> the Events and to Technologies but only inside the current
>> >> >> brainstorming session.
>> >> >>
>> >> >> The semantic form for Trend will look like that:
>> >> >> <FORM>...
>> >> >> {{{field|session name|hidden|required}}} // the only valid way to
>> >> >> create a trend is using the #formlink on a Session's page. Formlink
>> >> >> will fill this value with the name of the session
>> >> >>
>> >> >> {{{field|related events|values from
>> >> >> query=[[Category::Event]][[session::$1]]|substitute=Trend[session
>> >> >> name] | input type=two listboxes}}}
>> >> >>
>> >> >> {{{field|related technologies|values from
>> >> >>
>> >> >> query=[[Category::Technology]][[session::$1]]|substitute=Trend[session
>> >> >> name] | input type=two listboxes}}}
>> >> >> ...
>> >> >> <END OF FORM>
>> >> >>
>> >> >> I can use values from concept but it's a very bad workaround if I
>> >> >> have
>> >> >> many sessions.
>> >> >>
>> >> >> I hope now the case is more clear.
>> >> >> -----
>> >> >> Yury Katkov
>> >> >>
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > WikiWorks MediaWiki Consulting http://wikiworks.com
>
>
>
>
> --
> WikiWorks MediaWiki Consulting http://wikiworks.com



--
WikiWorks MediaWiki Consulting http://wikiworks.com