addedValues Plugin

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

(1 or more words)


Get tropes here!
Click to see internals
Report bug


Imperia Winter Regatta

sitepic_iwr.jpg:
Viewable with Any Browser

Members
Join Now
Login

addedValues 1.0.5 Now available

Previous topic: Next topic:
inactiveTopic addedValues 1.0.5 Now available topic started 2007/10/01; 13:42:19
last post 2007/10/01; 13:42:19
user David Bayly - addedValues 1.0.5 Now available  blueArrow
2007/10/01; 11:42:19 (reads: 33686, responses: 0)
It has been 6 months since the last interim version, and most of the
changes are bug fixes. The rate of implementation will likely slow
down even more, so I intend to make posts to this list for each
change separately from now on. As before the way to get these
changes is to do a root update.

New Implementation.

- diagnostic information is now logged if a index operation
(add/delete) fails. This is need to handle message deletions and
un-deletions.

- the delete all method for text variables was amended slightly to
report success or failure.

- the current value of the for Counter is now available within
forEachWhere expressions under the name orderValue.

- the queryRedoLink macro was extended to allow further output to be
directed to another url, specified by means of a shortcut. This
turns out to be useful when doing a query whose hits are another
query.

- search reports can have parameters for use with parameterValues in
the query macro; but previously each parameter name had to also
appear in the query. Now this constraint is removed, however its is
still an error to call the query macro with a parameter name that is
not used by either the report or the query.

- the search reports in nohits text may now include references to
query parameters, using [[parameter ...] or parameter(...) inside
macro expressions.

- a new report option, applicable to search reports, called One Group
per page has been implemented. When set , a break on the sortedBy
variable also forces a page break. That is every group, no matter how
many hits, appears on its own page.

- some internal work to provide an API for shortcuts to the
addedValuesSuite was done.

- RICO search repots presented as a paged table of hits, can now
specify that one or more of the onClick reports/forms for the enabled
variables, will be called as the page is built for the first hit on
the page. In other words, the first hit detail is presented along
with each page of hits. The option is enbaled by clickign the
checkbox (labelled 1st) in the tabel fo onlick handlers.

Bug fixes

- under certain conditions a delete all operation could fail without
an error message. Now the failure is reported.

- [bugz#583] deleting an update form which had non flushed test data
might fail as an attempt was made to de-index the test data. Fixed.

- gems builtin variables were not always indexed correctly if the
standard Manila form were used. Fixed.

- variables whose value must be no HTML were rejecting cr, lf and tab
, now they are accepted .

- a bug in the parsers where the name of an error message rather then
the error string was used to report na error was fixed.

- the form on the view index page sometime used an incorrect ACTION URL.Fixed.

- and error encountered when constructing an error message that
might arise when creating a row detail report was fixed.

- forms using grouped global variables were not initialized
correctly; the layout could not be changed. Fixed.

- there was no method for multiple valued global variables which were
columns of a row placeholder. Fixed.

- the Values builtin function, which returns the number of valse of a
multiple valued variable, may now be used within a forEachWhere
expression. This is most useful for the forEach loop variable

- in a manila ETP form, the check that ensured that subject and body
always appeared in a messages form could fail if subject were present
in the layout, but later deleted. Fixed.

- [bugz#612] the edit control for gems buitlis are now editors only,
not managing editors only.

- the default renderer for character valued variables was incorrect. Fixed.

- when a search form is tested, a small form allows setting which
search report etc. is to be used to display results. This now appears
on a page alone, not at the top of the default forms page.

- a change to Manila broke the logic which decided whether AV wysiwyg
could override Manila wysiwyg. Fied.

- the HTMLArea3 wysiwyg rendering logic did not always insert all
needed javascripts. Fixed.

- cloning or importing a global variable which was a row placeholder
failed. Fixed.

- the button on the variables page which defines member buitlins is
supposed to be visible only when some builtin member variables are
not defined, but it was always visible. Fixed.

- importing a query with parameter blocks did not handle the
parameter blocks correctly. Fixed.

- a security windows in the option to add new members using the
emailForm postprocessor was closed, thanks to Jan Storms for the
alert.

- the validation for gems loaded thru addedValue forms now disallows
fielnames > 31 characters.

- testing a form sometimes failed because the dummy test message did
no have an inResponseTo builtin variable. Fixed.

- a query with computed or external sortedBy generated hit lists with
the ranking , but was not treated as other sorted hit lists by search
reports. Now they act the same , breaking on new values etc.

- when addedvalues finds more than one candidate for the url of a
message, bearing in mind the current page site structure, it will now
always prefer the shorter of the two.

- when a message builtin variable is indexed, addedValues is not
aware that a builtin has changed (its isn't informed by Manila) , so
it detects changes that need to be reflected in the index in the
Manila new message callback. In some cases it was not detecting such
changes. Fixed.

Known issues

- When a story is deleted using the admin box on a story page, or by
deleting from the stories page ; addedValues must update the indexes
of any variables that had values in the story. It uses a new feature
of Manila 9.6, the deleteMessage callback, to do this - its low
overhead makes it perfect for the job. Unfortunately prior to Manila
9.6, there was no reliable way for a plugin to know that a message
had been marked deleted in this way. This leads to indexes that refer
to deleted messages. Messages deleted from the discussion group are
de-indexed correctly. I have found no acceptable way to fix this, in
fact the delete message callback was designed and implemented by me
and inserted into MAnila at my request. The only workaround on pre
Manila 9.6 versions is to reindex the variables concerned manually..

Enjoy!
--

- David Bayly. Programmer and digest reader. dbayly at udena dot ch
Digest Readers do it once a day.