Hi everybody,
here is an update of the various xotcl packages. The following sections describe the changes in the XOTcl pages since the last release.
These packages can be downloaded from:
http://media.wu-wien.ac.at/download/xowiki-doc/xotcl-apm.html
<h3>XOTcl-Core (version 0.27)</h3>
<h4> Object interface to content repository</h4>
This interface provides a simple way to instantiate
and manipulate items from the content repository.
In a very similar way an interface to oacs objects
could be established as well.
The interface is described by examples.
- create an XOTcl object from an arbitrary CR item (type is taken from OACS) provided that the type has a class definition;
CrItem instantiate -item_id 6413
The resulting object has all core attributes of the CR as well as the defined "extra" CR-attributes - do something with the object
6413 append title " - Kilroy was here!"
- and save it with a new revision
6413 save
- ... or make a new item
6413 save_new
- ... or delete it in the database (destroy is for XOTcl object only, delete for db)
6413 delete
- one can perform as well re-classing, e.g. like
CrItem instantiate -item_id 6417
6417 class ::xowiki::Page
6417 set title "en:[6417 set title]"
6417 save_new - create an answer set containing all XoWiki pages (and its subtypes) contained in a specified CR folder; the answer set can be restricted or ordered, etc. via additional attributes.
set r [::xowiki::Page instantiate_all -folder_id 3737]
The result is an ordered composite, suitable for the templating described below. One can iterate over the
children using the method "children". foreach o [$r children] { ......}
<h4>Support for nested Object Structures</h4>
The class OrderedComposite supports object structures similar to XOTcl's aggregations, but where the order of the included elements is preserved by default. The OrderedComposite supports ordering (based on Tcl sort) of the elements as well.
The following example shows how to define complex strucures based on the composite. In this example, we have three different rectangles with different colors nested in each other. The rectangle is a specialization of an OrderedComposite.
Class Rectangle -superclass OrderedComposite -parameter {color}
Class Point -parameter {{x 100} {y 300}}
Rectangle r0 -color pink -contains {
Rectangle r1 -color red -contains {
Point x1 -x 1 -y 20
Point x2 -x 1 -y 2
}
Rectangle r2 -color green -contains {
Point x1 -y 123
Point x2
}
}The sort order of the elements of the OrderedComposite can be optionally determined. When a sort order is defined for an ordered composite the method "children" returns the children nodes in the specified order. Note that when ordered composites are nested, the ordering per composite can be different. This makes it e.g. possible to construct tree tree structures with sort orders. Without "orderby" the order of the insertion is preserved.
r0 orderby color
r0::r1 orderby -order decreasing y
In the example above, the content of rectangle r0 is ordered by color, while the content of r1 in r0 is sorted by the attribute y.
Elements can be added as well to the composite incrementally via the add method. Ordered composite is used by the object interface to the CR and by the templating
<h4>Object Oriented Templating</h4>
XoTcl Core contains a simple templating system that is defined in terms of widgets and decorators (in the design pattern sense) for these widgets determining the rendering.
Widgets define rendering-independent structures such as a Table with different kind of columns. A widget might use several ordered composites (e.g. one for the columns, and one for actions, one for the data)
A Decorator is used as a skin for the widget and might be mixed into widget (realized via mixins). Therefore, with rather little effort, alternative skins can be provided and specified at rendering time.
The current implementation supports a TableWidget with Fields and AnchorFields with two skins, one called TABLE (render TableWidget with a HTML table, exactly like ::template::list::create) and TABLE2 using divs and tables. Per default, TABLE2 is currently activated.
The following example is taken from the request monitor. A table widget with two columns is defined, where the columns have handles for sorting. The url query attribute "orderby" stored in $orderby has the syntax as for ::template::list and is passed to the orderby method of the Ordered Composite. The "add" method is used to add incrementally rows to the composite. Finally, asHTML renders the TableWidget with the default renderer.
Example:
set title "Active Communities"
set context [list "Active Communities"]
TableWidget t1 \
-columns {
AnchorField community -label Community -orderby community
Field count -label Count -orderby count
}
foreach {att order} [split $orderby ,] break
t1 orderby -order [expr {$order eq "asc" ? "increasing" : "decreasing"}] $att
foreach {community_id users} [throttle users active_communities] {
if {$community_id eq ""} continue
t1 add \
-community [dotlrn_community::get_community_name $community_id] \
-community.href [export_vars -base users-in-community {community_id}] \
-count [llength [lsort -unique [eval concat $users]]]
}
set t1 [t1 asHTML] The concept based on mixins can be used as well for individual renderings similar
to the display-template option of ::template::list
Example:
Class CustomField -volatile \
-instproc render-data {row} {
html::div -style {
border: 1px solid #a1a5a9; padding: 0px 5px 0px 5px; background: #e2e2e2} {
html::t [$row set [my name]]
}
}
TableWidget t1 -volatile \
-columns {
Field time -label "Time" -orderby time -mixin ::template::CustomField
AnchorField user -label "Userid" -orderby user
Field ms -label "Ms" -orderby ms
Field url -label "URL" -orderby url
} Currently, only the request monitor uses these widgets. Only a subset of ::template::list is currently supported (optional sort controls on columns, column labels, HTML attributes of columns, anchor fields, csv output). By using the TABLE skin, the TableWidget is rendered exactly like template::list, the client code is slightly shorter than with template list. For rendering large tables (e.g. 2000 rows) i measured a performance win by a factor of 10 (23 seconds on my notebook with template::list vs. 2.5 seconds for the oo templating). The performance difference is esp. relevant for sites with high loads. template::list seems especially bad with large tables.
<h3> XOTcl-note (version 0.5)</h3>
- the more or less minimal example, upgraded to the object interface
<h3> XoWiki (version 0.14)
</h3> - upgraded to the object interface
- less database interaction
- various improvements on the forms
- class names in the ::xowiki namespace
- upgrade script for using the new class names
<h3>XOTcl Request Monitor (version 0.35)
</h3>
