Tags:
create new tag
, view all tags

SID-02152: Form select field values defined using Spreadsheet GETLIST

Status: Asked Asked TWiki version: 6.0.0 Perl version:
Category: CategoryForms Server OS: ubuntu 14.04 Last update: 1 year ago

I want to use the select+multi+values field within the form and populate the list of possible values using spreadsheet functions.

%CALCULATE{ $SETLIST( list_var,  $LISTJOIN( $comma, one=1, two=2, three=3 ) ) }%

Name Type Size Values Tooltip message Attributes
attr1 select+multi+values 3 one=1, two=2, three=3    
attr2 select+multi+values 3
%CALC{ $GETLIST(list_var) }%
   
attr3 select+multi+values 3
%CALCULATE{ $GETLIST(list_var) }%
   
But when editing a topic associated with this form - the combobox of the art2 and art3 is empty. The art1 is working fine. I am missing something related to the evaluation time of the %CALC%. I thought this should work just like the variable that is working fine for the same purpose.

I would like to use the spreadsheet LISTS to define a list of options at one place and use them in the definitions of several different forms. Another intended usage is to define the field values using lists and cached hashes that were derived from a formatted search using the variable.

Many thanks for any hint.

-- Rostislav Chudoba - 2016-02-11

Discussion and Answer

TWiki variables in TWiki forms definition values are processed. That way you can use SEARCH, CALCULATE and other variables. The problem in you case is timing. CALCULATE lists only live for the page rendering time, not across pages. So you example would work if you define the list in every topic that has your form. That is not practical unless you do that in an NCLUDE. Look into using preferences variables defined in WebPreferences, or persistent variables in the SetGetPlugin.

-- Peter Thoeny - 2016-02-14

Thank you Peter, I tried all the options you mention but I am still not there. The SetGetPlugin works, but it does not update dynamically when the content of the variable depends on the content of other topics. The application is acrualy working already with the SEARCH; variable, but to manage the complexity I would like to make it more transparent by encapsulating the methods on objects into the topics related to the "class definition". Then, I don't have to think about "how should a particular object type be referenced from another object".

Let me very shortly explain what I have in mind. I am using machinery provided by Forms - Search - Calculate to get an object-oriented database interface within the twiki installation. My application provides an intranet publication management on research of engineered-folding structures.

I define a database class using the following topic files

  • DesignGoalForm defining the object attributes
  • DesignGoalTemplate - part of constructor
  • DesignGoalNew - part of a constructor as a html form that can be embedded somewhere to add new objects using AUTOINC
  • DesignGoalHeader - html view to an object
  • DesignGoalInc - generator of HASHES and LISTS using the SEARCH variable and CALCULATE
  • DesignGoalList - using the HASHES to produce nice tables.

The DesignGoalInc is used in INCLUDE and renders snippets of wiki or html strings that can be embedded in objects that refer to a DesignGoal object. An example of such snippets is a list providing the mapping between the DesignGoal object for use in the select+values form field:

%CALCULATE{ $GETLST(DesignGoalList_select_values) }%

rendering the values currently in the "database":

E1-production costs=EF.DesignGoal0013, E2-service costs=EF.DesignGoal0014, E3-service life=EF.DesignGoal0015, E4-recyclicng costs=EF.DesignGoal0016, MP1-stability=EF.DesignGoal0004, MP2-deformation=EF.DesignGoal0005

If I understand you right using INCLUDE It should be possible to define a Class object structure EngFoldPublication using the following form EngFoldPublicationForm

%INCLUDE{DesignGoalInc}%
| Name |   Type |    Size  |   Values  |   Tooltip message  |   Attributes |
| title |    text |  3 |           | title of the publication  | M |
| design_goals_search |  select+multi+values |     3 | %SEARCH{ %SEARCH{ "form.name='DesignGoalForm'"  type="query" excludetopic="*Template" nonoise="on"  format="$formfield(name)=%WEB%.$topic" separator=", "}% | | |    
| design_goals_calc |  select+multi+values |     3 | %CALCULATE{ $GETLIST(DesignGoal_select_values) % | | |    

The Values field of both design_goal_search and design_goal_calc render the same contents with a comma separated pairs of "name=$topic" values in the view of the form. However, if I create an object/topic of a class/Form - EngFoldPublicationForm is edited - the design_goal_search offers the right list and the design_goals_calc is empty.

So I could stick with (what I am doing now), but since the class diagram is relatively complex, it would be nice to encapsulate the whole class specific derivations of code snippets within the files related purely to the class implementation itself.

Based on your suggestion to use the SetGetPlugin with the remember or store option I've used the and variables in the DesignGoalInc file like this:

%SET{ "DesignGoal_select_values" value="%CALCULATE{ $GETLIST( DesignGoal_select_values ) }%" remember="1" }%

and used it to define the multi-value selection field as follows

| Name |   Type |    Size  |   Values  |   Tooltip message  |   Attributes |
| title |    text |  3 |           | title of the publication  | M |
| design_goals_setget |  select+multi+values |     3 | %GET{ "DesignGoal_select_values" }% | | |    

This almost works. However, it does not seem to update the list once I add a new DesignGoal object. The selection box does not include it. So I have to manually update the Form - open it in the editor and save it anew.

I admit I do not really grasp the dependency on variable values and rendering times. And I really hope I could explain the point in an understandable way. The possibility to use twiki in the way of OODB seems rather cool to me. I thought with the hashing, also the efficiency should be fine even for a relatively large number of objects. But maybe the limits are more severe than I can guess. If you have some comment on this or a hint to someone trying a similar thing I would be thankful.

-- Rostislav Chudoba - 2016-02-14

Your code will work if you define the list in every topic that has your form. That is, INCLUDE the DesignGoalInc either directly in those topics, or nested in the included header.

If you consider the rendering, when a user looks at a topic that has the DesignGoalForm attached, TWiki's form handler reads the form definition, and expands the variables in the context of the current topic, not the DesignGoalForm topic.

-- Peter Thoeny - 2016-02-15

It must be something simple but I cannot get it running. Following your instructions, I made an example in the twiki.org Sandbox Web. There are three files:

If I get your explanation right, this should actually work. The Inc file is included in the topic. Still, I do not get the option list in the form field when opening the RCHMultiValueFieldTopic in edit mode. I am really sorry for bothering you with this again, I probably do not see the obvious. Many thanks for your help!

-- Rostislav Chudoba - 2016-02-15

Ok, I think I get it! When using the Edit button or directly invoking the edit script using SCRIPTURL ... - RCHMultiValueFieldInc file is not included, right? It is not enough to include it in the view mode I suspect. So I have to somehow overload the standard Edit procedure to get the list_var variable into its context, right. Probably, this is described somewhere. I will have look into it. If you have any link to a related piece of documentation in mind, that would be great.

-- Rostislav Chudoba - 2016-02-15

Correct, in edit the RCHMultiValueFieldInc is not included. What you can do is define a WebPreferences setting that does the INCLUDE. Then use that setting; preferences settings take effect in view and edit.

-- Peter Thoeny - 2016-02-15

Ok thanks again!

-- Rostislav Chudoba - 2016-02-15

I understand now that I have two options

* include the customized html editform within a view to the topic and accept that the edit script would not provide the dynamically evaluated selection list.

* provide a WebPreferences setting -- that would include the calculations formulas also within the edit mode of a topic. But here I am blocked. I thought I would somehow find out what is meant with the WebPreferences setting but I did not after trying hard.

I sorry coming back here again and asking to release this mental block of mine.

In fact can already achieve the functionality I want. But it is not nice solution ;-( I "misuse" forms - to introduce a dynamically extensible object-oriented database within twiki. But having to define the SEARCH in the form specification is lengthy and results in redundant code of a "class object". As I have about 20 classes, a more implementation locality would be great to manage implementation more easily. Unfortunately, I do not know much perl so that figuring out the principles directly from the code is difficult for me. Thank you again.

-- Rostislav Chudoba - 2016-02-26

      Change status to:
ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.
SupportForm
Status Asked
Title Form select field values defined using Spreadsheet GETLIST
SupportCategory CategoryForms
TWiki version 6.0.0
Server OS ubuntu 14.04
Web server apache 2.0
Perl version

Browser & version Firefox 44.0.1
Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r9 - 2016-02-26 - RostislavChudoba
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.