addedValues Plugin

...Powerful Free! Database Expansion for Manila

(1 or more words)

Get tropes here!
Click to see internals
Report bug

Hawaiian Hardwoods Direct

Viewable with Any Browser

Join Now


Form Flavours

Forms are the medium through which the end user interacts with your website. addedvalues forms come in 4 flavours. all flavours share a common page to create, delete, modify and test forms.

Creating a Form

pic_Forms Add: pic_Forms Clone:

The Forms menu

pic_forms Display1: pic_forms Display2:

pic_Forms DisplayFilter1: pic_Forms DisplayFilter2:

Deleting a form

Testing a form

b153 - shadow pseudomacro for search form layouts. This allows values from one form field to be used to search several variable indices and the results to ORed together. Syntax is [[xxx shadows("yyyy")]] which indicates that the value entered for YYY will be used to search YYY and XXX; in query terms (YYY = value) OR (XXX = value) Any number of variables an shadow a single variable. The only restriction is that it must appear in the form.

b156 - make AV aware it is in MLAC (manilafixer) environment where message access is controlled (a) preference to enable disable (b) after a search, message hit lists are pruned of inaccessible references, according to users access privileges - preliminary work to limit ability to update variables according to MLAC cohorts

b159 - when a search is performed, the form that produced it is cached

b182 - In forms, generic menus (dropboxes, radio menus and checkbox menus) are cached. The cache is normally self maintaining and needs no attention, but in a development environment can sometimes get out of synchronisation with the real values. If the developers debug flag is set, a checkbox to flush any caches is appears next to the "3. Set rendering" button .

b183 - the metadata plugin notion of custom scripts; by which was meant custom rendering scripts, has been revived with a few changes. The scripts that are available to a site must be at the first level of the customFormatScripts sub table of the addedValues storage area - there is no UI to install or manipulate this table - and the table may contain other entries such as tables and wpText entries. The difference is that the returned html should contain only the tags required to build the form element not tr and td tags as in Metadata. Also, addedValues expects the name of the item to be the value made available as dispname. Once a script is installed, it will be an available rendering for all string values variables, it must be selected in the usual way on the form detail page.

b185 if a variable is indexed by word, one can enter a space delimeted set of words in a search form and the response is a the UNION of searches for each individual word. This was broken and is now fixed. - a new preference was added to each search forms, which takes effect if and only if the search macro call specified a sortedBy variable of type date and flReverseSort is false. In this case , when set the first hit presented is the earliest one from todays date. a link to any earlier entries is retained.

b186 default forms are now built with label tags around form element labels, if the form element has a value for the id property. This can b assigned manually by the form creator, or can be generated by addedValues if the appropriate form preference is set.

b190 forms whose usage is user transactions do not have a submit button named Test appended to them unconditionally. This allows such forms to terminate a user transaction with a javascript enabled button. Others must still include a submit button. searching for a date variable within a range is now possible. In a search form for date variables 2 new renderings called christianRange and datefreeFormRange are now available,. - the test form button now allows you to displays results of a search with a calendar report provided that the search results are sorted by any date variable.

b192 - searching for a values of a numeric variable within a range is now possible. - update forms are forms that simply change values of variables in existing messages/gems/member records or shortcuts; without dealing with the complexities of working with Manila subject and body fields. The custominputForm macro was inherited from the Metadata plugin and needs top be adapted to its new environment. Now this has been updated to the "current state of the art" and 2 new macros custominputFormLink and customInputFormPopup have been added. This work is in the initial stages.

b194 in search forms, dropboxes, multi-boxes and other renderings of indexed variables showed all predefined values; now only variables actually in the index are offered. This behavior has been made optional; for each individual form element.

b195 - it is now always allowed to add a submit button to a form.

b195 - A new date rendering in forms; uses DOM techniques to add a clickable control, next to a date field, which allows date entry from a client side javascript calendar. In search forms, there is an additional rendering available which offers 2 such fields to set the low and high bound of the search.

b198 support for the refeshafterpost form field has been added. When set, submitting a form with an explicit value for the field should cause addedValues to enter edit mode again with the same story. If the first form changes the variable which is used to decide which form to use, the second form may appear different to the first, which can be a useful way of guiding your users through a complex data entry process. More work is needed to finalise this feature.

b204 - ETP forms with dropboxes, multiboxes, checkbox menus and radio menus are supposed to select current values, even if a disabled default exists for the rendering - however, in some case this was not done. Now its is consistently done.

b205 if the form table of a Manila ETP form, contain a script called newEntityPreload, when the form is built for a new story or new message, the script will be called and passed the address of the formtable and a message table. The script can pre-load values of addedValues message variables, which can then be used in the form building process. This is an advanced option, meant to be used together with custom renderings. One context recently found useful is in sites which use both the addedValues and the linguist plugins.

b227 the default layout for forms now declares a table with values for cellpadding, cellspacing and border.

b227 It is now possible to rank hits from a search form. To do this, select the form in the multibox on the form master page;the set Ordered by to "Computed". In the response, a button will appear next to the Ordered By menu which allows defining the Ranking Formula - the expression that computes the score of the hit. More work is needed here to make the search terms to be to be visible to the ranking formula.

b227 if a form has javascript validation enabled but no required fields or types that can be checked client side, the protection against double submits was not built. Now it is.

b237 - search forms can now intermix variables from different groups or no group at all, provided they still all have the same values of applies To (messages, etc). Although this can be useful, bear in mind that a sortedBy variable really needs to have values across objects (messages, etc) from all groups, to be useful. If there is no value for the sortedBy variable, the default value is used, but this may lead to reports sorted in odd-seeming ways.

b275 - user transactions can now redirect the user to a specified url as a way of ending a transaction. On the forms page, in the last form of the transaction, set the On submit option to "redirect to" and supply a valid http or https URI. To clear a redirect action, set the url field to blank.

b281 - Frontiers HTML engine is able to render pages in non latin alphabets, such as Chinese, Japanese and Cyrillic if the data is entered with modern standard compliant browsers; the value of the HTML engine ioFilter is false when the page is rendered and if macros contributing to the page content do not isoencode their output. addedValues obeys the isoFilter setting, but some form elements are built once and cached and might be built with isoFilter true and used with isoFilter off. There is now a checkbox on for each rendering - Disable ISO Filter - which enables full control of this situation.

b283 - a multiply valued row place holder variable is a way of declaring a table with an unknown number of rows consisting of values for 1 or more variables, in effect a sparse matrix. (An Excel spreadsheet is an everyday exampel of sparse matrix). The foreach loop in reports allows building pages with such variables relatively easily, but there has been no way to define an input form to manage such tables without knowing how many entries in advance. Now, a new type of form Row Update solves this dilemma. Row update forms are called in the context of one entity (message, gem, etc.) and with a specific row number to edit. New rows can be created by calling the form with the next free row number. The customInputForm, customInputFormLink and customInputFormLinkPopup macros have been modified to accept an optional rowIndex parameter , the number of the row to edit in a table. The links generated by addedValueMacros.customInputFormLink and addedValueMacros.customInputFormLinkPopup are of necessity ephemeral and contain a validity field so they cannot be used after the table has changed. Attempting to call up a form with an outdated link generates an error. The intended use of these macros is in an item detail report. for example the report that displays a message might contain an HTML representation of each row, together with a link to edit that row.

b284 - A new form option allows the Managing Editor to restrict the use of a custom input form (Usage Update or Row Update) to the members of a membership cohort. (Manila ETP forms have form element control by variable, and the hit Lists generated by search reports are subject to "trimming", so this is complementary feature rather a totally new capability.)

- manila websites may be static rendered, see Userland documentation, for example and Web pages served by a static server cannot be interactive, i.e. have forms , unless the submissions are passed to a dynamic server. Appropriate addedValues forms can now work this way , their submissions are directed back via Frontier to addedValues and the response pages are generated dynamically but links on those pages generally point back into the static site. Appropriate means search forms and user transaction forms, but not edit this page or message/gem update forms. Because static sites are by default, public, Manila must render static pages as they would be seen by non logged in visitors; for addedValues forms that means the forms are rendered in their public form also.

b307 - A framework was added to allow addedValues to do more at a form submission time. In the validation phase, form fields are checked for errors such as required fields are present, values destined for string fields satisfy the value must be of the variable and so on. Now its possible to compare new values to current values, and add more checking. This is is an internal change, but it opens the way for some new features.

b307 </p- if values of indexed, case insensitive, non text indexed, single valued variables with the Must be Unique property set, are set by a form, the form validation script is able to reject submission that would duplicate the variable in the index BEFORE the entity (message, gems, member, shortcut etc) is altered or created. As part of this change, addedValues is additionally sensitive to message subject and gems title whose builtins variables have been modified in this way; and will extend the protection to pictures (value must be picture shortcut, picture rendering) and gems (value must be gem shortcut, file rendering) uploaded as one element of a form. This solves an old problem for Manila novices of non intuitive behavior when duplicate pictures are created. If you wish to use this technique, change the variable attributes then set the layout of the form, to get the new validation checks. This work was commissioned by WebSanity LLC.

b308 - the logic that allows special validations to be applied to form submissions was expended to allow multiple special tests on submissions.

b308 - A new "special validations" for search forms with variables whose value must be ANY string, now disallows searching for HTML markup. A second test, for variables whose value must be ANY string or no HTML, checks each word in the input against a black list and rejects the submission if any match. The blacklist test is not used if the blacklist does not exist on a server. These measures were added to defeat spammers who have taken to inserting a list of links to their websites in search forms. These validations will be in effect, only after the the rendering for a variable is set anew.

fc6 - an optional 3rd parameter was added to the textbox qualifier in form layouts . It is a string, and its value should be name/value pairs of the form a='b'. The name can be any combination of class, style, lang, dir, id, tabindex, accesskey. The supplied values are used when the form is built.