Tags:
create new tag
, view all tags
I forked this discussion from MakeCategoryAndTopicDropdowns. Discussion at MakeCategoryAndTopicDropdowns was about skins and templates, and I would like to talk about new Twiki Variable.

Clearly there is somewhere in TWiki function capable of generating drop-down list for a form category, but I did not found it in TWikiVariables. Can it be make public? I am hoping for something like GETCATEGORYLIST{"formname", "categoryname"}.

I am working on TWiki for our group (Yet Another Bug Tracking system), using ideas from Know web. And have problems generating all proper searches. BugReport by bug categories are static, so it is only pain to type all needed SEARCH parameters.

But BugReport by person assigned are worse: person list may change, and after each change in form (or in my case, in topic AssignedTo, defining drop-down option list), I need to remember to go to search topic, and add new search option.

I was hoping to create a HTML FORM, use new GETCATEGORYLIST to generate dropdown (list of developers) dynamically, as is defined in form topic, and submit form to topic BugReportByDevelopers.

Then, I a looking for another feature. At this point, it will be nice to have TWiki variable able to access CGI query parameter, so I can extract value of category submitted, and issue a SEARCH query.

If this were implemented, even after I added one more developer in form topic, no changes are needed in search page, because list of developers would be generated dynamically via GETCATEGORYLIST, and search would display results based on submitted CGI parameter. Like magic! Look, mom, no hands!

Is it possible? Feasible? Any better ways to do it? Workarounds? Links what to read more?

Am I pushing TWiki too close to own mini-language? Is mini-language like this a symptom of featuritis to be avoided?

Sorry if I did not expressed myself clearly enough first time, but this is what I was hoping for.

-- PeterMasiar - 08 Jan 2002

This might be a useful extension even if it raises the complexity. The good news is that it would be a "hidden" feature, e.g. not in the way if not needed.

Already now you can extract form field values from a form definition topic using the $pattern() in FormattedSearch. This allows you to extract parts of a topic "as is", so it does only half of what you want.

Example: The following is the TopicClassification list, extracted out of the WebForm topic:

  • You type: %SEARCH{"WebForm" scope="topic" nosearch="on" noheader="on" nototal="on" format="$pattern(.*?Select one[^\,]*\,([^\|]*).*)"}%
  • You get:

Brainstorming here, what you need is either a specific command like you suggest, or some sort of post processing of a search result to change the list into a HTML option list. Hmm, sounds too complicated. Ideas?

-- PeterThoeny - 08 Jan 2002

Thank you for your response.

If I understand you properly, you propose to expand dynamically all options using your magical SEARCH format (generating dynamically links to each topic), and each topic generate formatted search output.

I am still thinking of topics as text (data), and you are using them as programs. I need time to adjust to TWiki way of interfacing. smile

  • I am not completely sure why your magic works, how it knows you want list of options for TopicClassification, and not others? What if I have multiple drop-downs in my form, and each has "Select one" as first (default) option? Will it break?
  • magic SEARCH saves half of the work, but for the price of having cut/paste and then maintain formatted search in each topic. Fast to create, nightmare to maintain/change. But has a bonus, too: You may enter topic-specific info, like links to related topics. Big plus!

Maybe we can get best of both approachaes if we can improve INCLUDE variable so it will be able to accept parameters. Then, I would be able to have topic BugFormSearchByTopicClassification, which will define common part of the search, and then in each topic I can include it, with parameters. It looks like might be generaly usefull idea, facilitating development of TWiki-based applications. Was it discussed before? Deserves own topic?

Also, when entering magic search patterns like yours, it will be nice to have ability to enter comments (hints), visible for person editing topic (fancy SEARCH), but not for person viewing i.e. search results. Again, it will facilitate development of TWiki-based applications. But I am not sure you want to go down this road... smile

How to write more sophisticated SEARCH queries, like "high priority bugs assigned to somebody, sorted by client"? I told you, do not go down this road...

Thinking of it, I might be able to accomplish what I want right now using your magic, INCLUDE and BASETOPIC. I'll try and let you know.

-- PeterMasiar - 10 Jan 2002

How to write more sophisticated SEARCH queries, like "high priority bugs assigned to somebody, sorted by client"? I told you, do not go down this road.

This can be done right now. We have such a system in place and use twiki formatted searches combined with URLPARAM to filter priority, client and staff member (and about 30 other fields).

It means you can have one topic with an embedded search query and then simply pass urlparameters to it to alter the content of the page.

%SEARCH{ "JobPriority.*value=\".*%URLPARAM{"pri"}%.*\";StaffList.*value=\".*%URLPARAM{"staff"}%.*\"" web="Jobs" casesensitive="off" regex="on" nosearch="on" nototal="on" header="| Number | Pri | Client Code | Description |" format="| [[$topic]] | $formfield(JobPriority) | $formfield(ClientCode) | $formfield(Description) |" }%

The link to this would simply have ?pri=P1&staff=AdrianLynch I have attached a screenshot of how the results are displayed (the screen shot is of jobs assigned to our print department) which is controlled in a similar manner to the above code.

Is this what you had in mind? Or have I missed the point? smile

-- AdrianLynch - 10 Jan 2002

I created a plugin that displays a drop down list of form field values from a topic of your choosing. The syntax is:

%KEYWORDLIST{formtopic="JobTicketTemplate" formfield="CurrentDepartment"}%

All it does at the moment is display a drop down list of the values. Nothing more (I was just seeing if it was possible). It could be used as the basis of a custom search form quite easily I imagine or simply to generate a link to the page (ie. select the value from the drop down and hit a go button).

I have attached it for review, but seriously I would not install it on a production machine. I am a complete novice so it's purely for discussion purposes at the moment.I would be happy to take suggestions on what to do with it (even scrap it!). smile

-- AdrianLynch - 11 Jan 2002

Thank you, Adrian. URLPARAM is what I was looking for! I somehow missed it... frown You are right, together with your KEYWORDLIST, it is possible to create HTML form with sophisticated queries (dynamically generated from TWikiForms fields).

If/when TWiki elders will approve/improve plugin for KEYWORDLIST, I believe I'll be all set (for now smile ).

-- PeterMasiar - 11 Jan 2002

Since JohnTalintyre has decided to look at this as part of the BeijingRelease, here are my suggestions! smile

It would be great if there was a generic interface to utilise the META form data, along the lines of what is evoloving with the search format options.

Would a syntax such as the following work?

We already have the =%META% variable which displays all the meta form data.

If you could pass arguments to this such as:

  • topic Specify a topic to get the META form data from. Default would be current topic.
  • field Specify a field to get the META form data from. Default would be all fields.
  • format As per formatted search results.
  • sourceistable Specify the source is a table (ie FormTemplate) rather than from META field.

%META{topic="name" field="name" tablesource="on" format="$item"}%

So with the above format you could:

Render a META field within the body of the page.

%META{field="TopicStatus" format="---+++ $item"}%

ie.

ActiveTopic

Display the fields of a particular webform.

%META{topic="WebForm" field="TopicStatus" sourceistable="on" format="$select"}%

ie.

-- AdrianLynch - 15 Jan 2002

Yes -- what he (Adrian) said!

-- RandyKramer - 15 Jan 2002

I like proposal of AdrianLynch, too. In it's first example, with format="---+++ $item", it will allow to grab values from the form (displayed way down on the end of the page) and render them close to the beginning of the page where they are in better context. And if form is changed, new values will be rendered - like magic. I definitely like it even more than feature I asked for in TwoFormsPerTopic.

-- PeterMasiar - 16 Jan 2002

Was this feature ever finished?

-- MartinCleaver - 10 Aug 2003

DUnno - But I'm about to want it for work - so If I end up liking it enough I will get it in - though I may reject it later as I know more.

-- SvenDowideit - 11 May 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Perl source code filepm JobTicketPlugin.pm r1 manage 5.7 K 2002-01-11 - 11:54 AdrianLynch Sample code for a job ticket form field value menu
GIFgif intranet_screen.gif r1 manage 38.7 K 2002-01-11 - 07:18 AdrianLynch Screenshot: Job tracking using urlparam & search
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2005-02-16 - CrawfordCurrie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2016 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.