addedValues Plugin

...Powerful Free! Database Expansion for Manila
logoBottle:

(1 or more words)


Get tropes here!
Click to see internals
Report bug


Hawaiian Hardwoods Direct

sitepic_hhd_screenshot.jpg:
Viewable with Any Browser

Members
Join Now
Login

Queries

A Query is a question with a Yes or No answer. It is asked of messages, members, gems or shortcuts and is composed of one or more asssertions about the values of indexed variables, linked together by boolean operators such as AND and OR.

A query has a name so that it can be used together with reports in searches. A search asks the question of each Message (member, etc.) and returns a Hit List. A hit List is sub-set of messages (members. etc.) for which the answer to a query is yes.

The applies To property of a query determines what type of addedValues entity it can be used with. The applies to and groupname properties determines what variables may be used in the queries defining boolean expression.

About Search

Queries are important because they are the first part of every search processs. Saved queries can be called up repeatedly passing the resulting hit list to any suitable report. In addedValues search forms generate a short lived query based on the actual user submission, which generate the hit list and is discarded.

b228 - a new property for queries has been added "May be accessed by". It accepts the same range of values as the property of variables Editable By, including an manilafixer Message Level Access Control Cohorts. Before a query is evaluated by the query macro, the verbThisPage macro or from an RSS feed URL, the status of the client is checked. If the requester is not from the defined group, a macro error is taken, or for RSS urls a page inaccessible code 403 is returned.

b255 - a new query option was implemented which, if set, deletes the current context from a hitlist when related is used in the query expression.

b270 - a new operator - uniqueIndexVariables - is available in queries. It returns a hit for the first encountered - so essentially random - occurrence of each value indexed. It is useful when you want to know what values are indexed, rather than what hits.

b270 - queries may now have parameters that are specified when the query is invoked from the query macro. Parameters are defined by their appearance in the query text, the addedValues query compiler will accept that name anywhere a string literal constant would be accepted. There is no practical limit to the number of parameters one query may have. The syntax is parameter(pname), where pname is an identifier such as paramater1. E.g. parameter(parameter1. Unless otherwise set, the value of the string at runtime is the empty string. There are two ways of assigning a value to a parameter, one permanent and one when the query is run. To set a permanent value, define the query and click Done to exit that page, there will be a new row in the options listing known parameters and a button to set default values. The query macro has been changed to allow specifying values for each call to the macro.

b272 - the parameters of a query are now accessible in search reports used with that query, using the pseudomacro [[parameter xxxx]] where xxx is the parameter name.

b275 - in queries, it is possible to access current value (here current means, the current message context) of a variable using related(variable name) or equivalently inserting the variable name on the right hand side of a relational expression such as subject = subject
or
description contains related(keyword)

b275 - If the variable on the right of the relation is multiple valued it was undefined what this meant. Now addedValues notices the dimensionality of the variable and uses a new operator isOneOf which returns true if the target value matches any one of the values of the right hand side. The isOneOf operator may also be used explicitly in queries, triggers (e.g. "James" isOneOf ChristianNames, "Film" isOneOf Categories). To make the isOneOf operator available for indexed variables, you must cause the variables methods to be rebuilt, the easiest way to do that is to edit the variable on its own, and click modify.

b290 - testing a query has been improved - you may now specify sorted, the sortdirection and the values of any parameters the query may have at test time. The test query process also handles pagination next and previous links gracefully. Complex queries that change the query, report and sortedBy variable are also handled. The call to the addValueMacros.query that is needed to reproduce the test results is shown in a form suitable for copy and pasting into a message.

b295 - if the default value of a query parameter begins with { and ends with }, then it is computed each time the query is run by neutering illegal macros and processing the macros in the context of the current page. So for example, {sitename} becomes the name of the website, or {whoami} becomes the member key from the current page. This is relatively costly operation, so use with care. Note that the query macro parameter, parameterValues is another way of assigning values at run time - but values set from this are not evaluated in this way and are therefore not so costly.

b304 - logic has been added to implement static rendering of pages with queries. There are 2 issues which make static rendering of such pages problematical. First, the query may return a different hit list each times it is run, for example, if might use randomIndexValues. This problem is resolved by ignoring it; on the basis that if you static render a page, you understand it won't change until the next static render. The second issue that a page whose query returns more hits than fits on one run of the search report will have next and previous page links. But these link use the same url with a different searchargs. Static servers typically do nothing with searchargs, so the 2nd and subsequent report pages are unavailable. One way to deal with this issue is to write the search result 'pages to a reserved directory (addedValues) in the static site and using server side include and conditional directives to render each static page . This technique works well for Apache 1.2 or higher, but does not work for Microsoft IIs, due the lack of conditional directives. So the choice of static server determines whether, and how, addedValues can render pages with queries. For this reason, addedValues can support a range of static renderers and there is a new panel on the preferences page to select the appropriate renderer. No renderer is shipped by default, but one implementing the Apache 1.2 solution described above, is available from the author. There is currently no support for addedValues forms from static pages.