Hi Antonio,
here is a short intor, how one can use the form fields. Assume, we have a form named en:PageWithDate.form, which has its "Template" set to
@_title@
@_text@
@date@
@count@
and its form constraints set to
date:date
count:number
and one fills out two instances, one with e.g. count set to "1", the other one set to "3".
In order to list the entries, one has end-user options and developers options. The simplest end-user function is to
use the links offered by xowiki when viewing the form, or one can use the includelet form-usages as show here:
Form usages of PageWithDate.form (without filtering):
{{form-usages -form en:PageWithDate.form -field_names {_title date count} }}
Form usages of PageWithDate.form (with filtering):
{{form-usages -form en:PageWithDate.form -field_names {_title date count} -where {count = 1} }}
When this page is rendered, it show two tables, the first one with all entries, the second one only these having count == 1.
From the developers point of view, one has certainly much more options, which are as well different depending on whether hstore is used or not. Without hstore, filtering of solutions based on the extra "instance attributes" happens in memory (in Tcl), which means that all instances matching other criteria are loaded at the first place into memory before these are tested. For a few hundred tuples this is ok.
When hstore is used, one can use expressions based on the instances attributes directly in sql, leading to very more efficient lookups (with millions of entries). Using hstore or not can't be hidden from the developer. When hstore is activated, also the selection criteria from above is mapped directly to sql (so far, not all possible operators of the where clause are mapped to the hstore counterparts, some operators will require casts from PostgreSQL.).
From the developers point of view, one can certainly use this functionality directly in his scripts, where one can lookup the details from the e.g. form-usages includelet. This includelet does much more as needed often (it obtains form-constraints and form variables from the used form, creates the form-fieds based on the types of the form-constraints, etc. If you simple want to list some data in e.g. a multirow, you can use the script below (written for xowiki in OpenACS 5.9.0) as a starting point. It assumes, the data is stored in an xowiki instance named "xowiki" in a folder named "form-usages" and gets the data either via hstore or from the plain xowiki instance attributes. The script contains as well a little recipe how to setup the instance with hstore. Note that with the presented approach, the raw form-field contents are used (similar to everywhere else in OpenACS). In the general case the types are needed to provide cooked values (as done by the support-functions in xowiki).
For more complex applications, you want to show the data in different situations to different users with different forms. For this kind of application is the xowf package built, which is like FormPages on steroids. We use this for all new development in our systems.
Hope this help
-g
::xowiki::Package initialize -ad_doc {
This is sample page using form entries
@author Gustaf Neumann (gustaf.neumann@wu-wien.ac.at)
@creation-date Nov, 2015
} -parameter {
}
set form //xowiki/form-usages/en:PageWithDate.form
set form_item_id [::xowiki::Weblog instantiate_forms \
-forms $form \
-package_id $package_id]
if {$form_item_id eq ""} {
set _ "no such form $form"
} else {
set _ ""
#
# xowiki instance without hstore (probably often the default)
#
if {![::xo::dc has_hstore] && [$package_id get_parameter use_hstore 0] == 0} {
multirow create mytable id name date count
foreach tuple [::xo::dc list_of_lists get_form_entries {
select item_id, name, title, instance_attributes
from xowiki_form_instance_item_view
where page_template = :form_item_id
}] {
lassign $tuple item_id name title d
if {[dict get $d count] ne "1"} continue
multirow append mytable $item_id $name [dict get $d date] [dict get $d count]
}
} else {
#
# xowiki instance with hstore. To setup hstore, one requires:
#
# 1) set xowiki package parameter "use_hstore" for instances to 1
# 2) run in psql: "create extension hstore;"
# 3) run in psql: "drop table xowiki_form_instance_item_index cascade;"
# 4) restart server (will rebuild the dropped table and dependent stuff)
#
# if you want to upgrade later more xowiki instances to use hstore, one can run
# ::xowiki::hstore::update_form_instance_item_index selectively on the certain package_ids
multirow create mytable id name date count
foreach tuple [::xo::dc list_of_lists get_form_entries {
select item_id, name, title, instance_attributes
from xowiki_form_instance_item_view
where page_template = :form_item_id
and (hkey->'count') == 1
}] {
lassign $tuple item_id name title d
multirow append mytable $item_id $name [dict get $d date] [dict get $d count]
}
}
append _ $tuple \n
}
ns_return 200 text/plain $_
