Showing 481 - 490 of 693 Postings (
summary)
Created by OpenACS community, last modified by Gustaf Neumann 07 Jul 2016, at 02:34 PM
Documentation Requirements for Developer Tutorials
By the OpenACS Community. This section is a collection of documentation requirements that have been expressed in the OpenACS forums to 4th July 2003.
OpenACS developer tutorial documentation should meet the following requirements. No significance has been given to the order presented, topic breadth or depth here.
-
list learning prerequisites to customize, fix, and improve OACS modules, and create new ones. You are expected to have read and understand the information [minimum requirements similar to adept at Using OpenACS Administrating Guide] before reading this guide.
-
Refer to development documentation instead of duplicating here
-
List suggestions for installing and setting up a development environment; these can be annotated links to the installation documentation
-
Provide working examples that highlight the various subsystems, tcl environment, OpenACS protocols, aolserver template and ns_* commands, OpenACS templating, sql queries, db triggers, scheduling protocols, how to use the page contract, how to get the accessing user_id etc
-
Show how to construct basic SQL queries using the db API,
-
The life of an http request to a dynamic, templated page
-
General rules to follow for stability, scalability
-
Show the step by step customizing of an existing package that meets current recommended coding styles of OpenACS package development, by referring to developer resources.
-
Use the ArsDigita problem sets and "what Lars produced for ACS Java" as inspiration for a PostgreSQL equivalent tutorial about developing a new OpenACS package including discussion of the significance of the package documentation templates
-
Include a summary of important links used by developers
-
Note any deprecated tools and methods by linking to prior versions instead of describing them in current docs
Created by Michael Aram, last modified by Gustaf Neumann 12 Apr 2016, at 10:39 AM
hstore is a postgresql module, which is used optionally by newer versions of xowiki and xowf (xowiki content flow) to provide quick access to the "instance_attributes" (the per-form or per-workflow attributes not part of the native content repository data model). The supporting functions (creating indices, etc) are currently mostly part of the xowiki sources (earlier: xowf).
Under Ubuntu, you can install hstore via:
psql -d <yourdb> -tAc "create extension hstore"
You can then verify the successful installation on the ds/shell using:
::xo::db::has_hstore
Created by Gustaf Neumann, last modified by Gustaf Neumann 12 Apr 2016, at 10:35 AM
Package Specification Summary for Package: xotcl-request-monitor
| Summary: |
Request Monitor with user tracking functionality |
| Description: |
<pre>
This package provides a Request Monitor for OpenACS applications. It computes performance
summary information such as requests/views per second, average response time, number
of users connected, lists currently active threads, etc. Furthermore, it can block
overactive users (e.g. automated web-bots mirroring the site, users repeating running
queries, etc.). It provides as well some user tracking (such as whos-online) with
activity measures, it blocks repeated requests (impatient reloads), tracks switching
of IP addresses from users, and provides request tracking per user for the monitored
time window. It contains as well overall URL statistics with performance measures.
Updated for circumventing handler calls OpenACS 5.2 for /resources/*.
0.28 provides calls for listing active communities and users active in these communities.
0.30 provides nice graphical charts (many thanks to Nima) and a new interface to the
background thread. In addition, ns_returnfile_background is included;
0.38 using context form xotcl-core
0.39 brings parameterized counter values
0.39 brings optional activity tracking
</pre>
|
| Maturity: |
Mature |
| This package depends on: |
acs-kernel acs-tcl acs-templating highcharts xotcl-core |
| Packages that depend on xotcl-request-monitor: |
None |
| Package parameters: |
- do_double_click_prevention
- Switch double-click-prevention on/off (default on, type string, scope instance)
- do_slowdown_overactive
- Slowdown overactive users (default off) (default off, type string, scope instance)
- do_throttle
- Turn request throttling on or off (default on).
If this parameter is turned off, no user-counts
etc are provided. (default on, type string, scope instance)
- do_track_activity
- Turn activity monitoring on or off (default off) (default off, type string, scope instance)
- hide-requests
- List of glob patterns to be used for hiding entries from request lists. Only requests that do not match any of these patterns are displayed unless all requests are forced. Affected pages: - stat-details (list of all recorded URLs with timings) - last-requests (tracking activity of a user)
(default *.css *.ico, type string, scope instance)
- max-stats-elements
- Number of highest data points in the reporting period. The default of 5 will e.g. show you the top 5 times of requests per minute, hour aso. (default 5, type number, scope instance)
- max-url-stats
- Number of URL entries to be kept in the detailed view of the request statistics (default 100, type number, scope instance)
- monitor_urls
- Monitor performance of the provided URLs (in munin responsetime) (default / /register/ /dotlrn/, type string, scope instance)
- peer-groups
- List of glob patterns for the summary of sites when an admin uses .../whos-online/. These patterns are matched against the domain names of the peer addresses. (default *wlan* *dsl* *.com *.net *.org, type string, scope instance)
- time-window
- Defines the time window in minutes which is used for detailed monitoring (e.g. calculate the number of active uses and the history of the requests of these users, the number of ip switches, etc.) (default 10, type number, scope instance)
- trend-elements
- Number of data points used for displaying the trend graphs. The default will show the trend for the last 48 seconds,minutes,hours. It is also the maximum reporting period possible (default 48, type number, scope instance)
|
Bug Tracker Summary for Package: xotcl-request-monitor
Code Metrics Summary for Package: xotcl-request-monitor
| # Tcl Procs |
8 |
| # Tcl Lines |
2302 |
| # Tcl Blank Lines |
210 |
| # Tcl Comment Lines |
547 |
| # Automated Tests |
1 |
| # Stored Procedures |
PG: 0 ORA: 0 |
| # SQL Lines |
PG: 0 (blank 1 comments 0)
ORA: 0 (blank 1 comments 0) |
| # ADP pages |
17 |
| # ADP lines |
479 |
| # Include pages (xotcl-request-monitor/lib/) |
0 |
| # Documentation pages |
0
|
| # Documentation lines |
0 |
| Browse Source |
API-browser |
| Github Repository: |
https://github.com/openacs/xotcl-request-monitor/tree/oacs-5-10
|
The xotcl--request-monitor depends on xotcl-core and libthread.
Created by Gustaf Neumann, last modified by Gustaf Neumann 08 Apr 2016, at 09:16 AM
The following conventions for severity levels (specified as first argument in ns_log) should be used.
- Notice: Something interesting occurred. A "notice" shows typically a state change, start/end of some jobs, etc. This level can be as well used of temporary debugging, but such messages should be removed after some time.
- Warning: Something that could mean something bad occurred. A "warning" indicates an unexpected situation, which requires attention of an developer and a corrective measure in the not-to-distant future. Usage of deprecated code or code using not following the engineering guidelines are of such type.
- Error: Something bad occurred. An "error" is a malfunction, that must be investigated by a developer. An error is an unhandled exception. The error.log file should be free of errors.
- Bug: Something occurred that implies that there is a bug in the code.
- Debug: This logging level is typically just activated during debugging.
- Dev: This logging level is typically just activated during development to inspect the behavior of new code. Such logging statements are typically removed once development has reached a stable point.
Created by Robert Taylor, last modified by Gustaf Neumann 21 Mar 2016, at 09:48 AM
Define a reasonable set of default CSS classes and ids that can be reused across the toolkit. Remove package specific CSS classes and ids in most cases and replace with site-wide ones. Allow for easy CSS-based themes.
Related pages:
related forum threads:
See also, the OpenACS coding guidelines.
Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 24 Dec 2015, at 10:48 AM
-
Always use Page Contracts:
All Tcl-implemented pages should use page contracts such as e.g.:
ad_page_contract {
... purpose ...
@author ...
@creation-date ...
} {
object_id:naturalnum,notnull
{verbose:boolean false}
{color:word ""}
}
-
Constrain arguments passed via query or form variables as strong as possible
All user provide content is potentially a security thread, since these values might lead to SQL-injection or XSS attacks. Therefore constrain the passed arguments as far as possible (see above), and validate the values further if necesary.
-
Avoid putting in HTML in Tcl scripts
Try to make use of OpenACS Templating or http://your.openacs/doc/acs-templating/. If you can't avoid it try to isolate the HTML into a proc so editing the layout will be easier.
-
Avoid Quoting Hell
If programmatic HTML-code generation is required, make sure that everything is quoted sufficiently and use the Tcl command subst to improve readability:
set href [export_vars -base admin/index -vars {foo bar]
set html [subst {
<a href="[ns_quotehtml $href]">Hello world</a>
}]
-
Read the Tcl Style guide
This is the Tcl styleguide (PDF), try to apply relevant guidelines. In particular chapter 4,5 and 7.
Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 19 Oct 2015, at 08:48 AM
.LRN Project
.LRN Home Page - The Official .LRN Home Page
.LRN bug tracker - Use the Open ACS bug tracker to report and check status on bugs for all sections of .LRN. If you need to report a bug and you are not sure what code is causing it, use the "2-dotLRN General" category. Otherwise select the package. Note that all the dotLRN packages are at the bottom of the list.
Get Involved! - how to participate in the community
.LRN Versions
Last stable release: 2.5.0
Next release: see .LRN 2.5 Release Management
Download from .LRN download page
.LRN Installation
To install .LRN follow the instructions at .LRN_Installation
This .LRN Governance page is a proposal based on a meeting by Carl Blesius, Carlos Kloos, Roceal Hernandez and Caroline Meeks.
Useful Resources
Site Specific Documentation
Official test servers
Page Information
- Last modified: 2015-10-19 08:48:56.668188+02
Created by Gustaf Neumann, last modified by Gustaf Neumann 10 Oct 2015, at 02:42 PM
Munin is a popular web-based tool to monitor several website. Munin provides a simple plugin mechanism for adding new kinds of sources, such as e.g. the NaviServer plugins for monitoring NaviServer.
The monitoring information collected by munin can be placed at different web servers, one finds usually information about apache and friends. In general older versions of munin (before 2.0) supported only static pages, whereas newer version support as well dynamic information (with additional features such as zooming).
For static munin pages, it is the easiest to place in OpenACS sites the output directory either under the main www directory, or under the subsite admin directory (packages/acs-subsite/www/admin/).
For the cgi-setup, one has to make sure to load nscgi in the statup files of NaviServer and to point the urls to the appropriate directories. The sample setup below uses the directories of munin as provided by a standard munin setup on an Ubuntu system.
ns_section ns/server/${server}/modules
ns_param nscgi nscgi.so
ns_section "ns/server/${server}/module/nscgi"
ns_param map "GET /munin-cgi/munin-cgi-graph /var/www/cgi-bin/munin-cgi-graph"
ns_param map "GET /munin-cgi/static /etc/munin/static/"
ns_param map "GET /munin-cgi /var/www/cgi-bin/munin-cgi-html"
Created by OpenACS community, last modified by Monika Andergassen 05 Oct 2015, at 12:45 PM
In vim add the following in your .vimrc will help convert tabs to 4 spaces to meet part of the OpenACS coding standard.
set tabstop=4
set expandtab
set list
set listchars=tab:>.
It's also nice to have syntax highlighting by adding the following line
syntax on
Also useful to use tagging features. In brief - run ctags -R in the root of the install or source tree.
At that point you can edit using vim -t procname or ::package::procname and go to the corresponding place in the code. From within the code, you can lookup functions by having the term highlighted and hit CTL-] - use CTL-T to go back.
Only works if you edit from the top directory, all tags are relative to there.
Created by Gustaf Neumann, last modified by Monika Andergassen 05 Oct 2015, at 12:43 PM
XOTcl is an object oriented extension for Tcl and required part of OpenACS installations since
TIP #87. The OpenACS package xotcl-core provides base functionality and
integration with the OpenACS framework.
The current version of
XOTcl is 1.6.7. Read about XOTcl motivations and feature from
http://media.wu-wien.ac.at/whatIsXOTcl.html.
For more details about XOTcl, see XOTcl Homepage.
INSTALLATION of XOTcl:
One can get XOTcl e.g. in binary form from
debian or it can be complied from source. The following instructions describe, how to compile XOTcl from source.
- Get, compile and install XOTcl
Get xotcl-1.6.7:
cd /usr/local/src
wget http://media.wu-wien.ac.at/download/xotcl-1.6.7.tar.gz
tar zxvf xotcl-1.6.7.tar.gz
The following commands can be used to compile XOTcl and install it into the appropriate places of the specified aolserver. We assume that the aolserver is installed under /usr/local/aolserver:
cd xotcl-1.6.7
CC=gcc;export CC
./configure --enable-threads --enable-symbols --prefix=/usr/local/aolserver --exec-prefix=/usr/local/aolserver --with-tcl=/usr/src/tcl8.4.16/unix
Use appropriate paths for aolserver4 and your tcl version.
make
make install-aol
After the "make install-aol" from the XOTcl sources, a file xotcl.tcl is installed in the directory /usr/local/aolserver/modules/tcl/ that handles .xotcl files and XOTcl serialization in the aolserver.
- Restart your aolserver to load xotcl.
