Most of the forms in OpenACS are created using the form builder, see ???. For detailed information on the API take a look here.
The following section shows how you can modify your form to allow WYSIWYG functionalities.
Convert your page to use ad_form (some changes but worth it)
Here an examples. From:
template::form create my_form
template::element create my_form my_form_id -label "The ID" -datatype integer -widget hidden
template::element create my_form my_input_field_1 -html { size 30 } -label "Label 1" -datatype text -optional
template::element create my_form my_input_field_2 -label "Label 2" -datatype text -help_text "Some Help" -after_html {<a name="#">Anchor</a>}
To:
ad_form -name my_form -form {
my_form_id:key(acs_object_id_seq)
{my_input_field_1:text,optional
{label "Label 1"}
{html {size 30}}}
{my_input_field_2:text
{label "Label 2"}
{help_text "Some Help"}
{after_html
{<a name="#">Anchor</a>}}}
} ...
You must not give your your form the same name that your page has. Otherwise HTMLArea won't load.
Convert your textarea widget to a richtext widget and enable htmlarea.
The htmlarea_p-flag can be used to prevent
WYSIWYG functionality. Defaults to true if left away.
From:
{my_input_field_2:text
To:
{my_input_field_2:richtext(richtext)
{htmlarea_p "t"}
The richtext widget presents a list with two elements: text and content type.
To learn more on existing content types search in Google for "MIME-TYPES" or
take a look at the cr_mime_types table.
Make sure that both values are passed as a list to your
ad_form or you will have problems
displaying the content or handling the data manipulation correctly.
Depending on the data model of your package you either support a content format
or don't. If you don't you can assume "text/html" or
"text/richtext" or "text/enhanced".
The relevant parts in your ad_form definition are the
switches -new_data, -edit_data,
-on_request and -on_submit.
To allow your data to display correctly you need to add an -on_request block.
If you have the format stored in the database pass this as well else use "text/html":
set my_input_field_2 [template::util::richtext::create $my_input_field_2 "text/html"]
Now make sure that your SQL queries that do the data manipulation retrieve the correct value.
If you simply use my_input_field_2 you will store a list.
Thus you need to add an -on_submit block:
set my_input_field_2 [ template::util::richtext::get_property contents $my_input_field_2] set format [ template::util::richtext::get_property format $my_input_field_2] #This is optional
Now the correct values for my_input_field_2 and
format are passed to the -new_data and
-edit_data blocks which don't need to get touched.
To make HTMLArea optional per package instance define a string parameter
UseWysiwygP which defaults 0 for your
package using the APM.
In your edit page make the following changes
# Is WYSIWYG enabled?
set use_wysiwyg_p [parameter::get -parameter "UseWysiwygP" -default "f"]
...
{htmlarea_p $use_wysiwyg_p}
The -on_request switch should set this value for your form.
set htmlarea_p $use_wysiwyg_p
All you need now is a configuration page where the user can change this setting. Create a
configure.tcl file:
ad_page_contract {
This page allows a faq admin to change the UseWysiwygP setting
} {
{return_url ""}
}
set title "Should we support WYSIWYG?"
set context [list $title]
set use_wysiwyg_p
ad_form -name categories_mode -form {
{enabled_p:text(radio)
{label "Enable WYSIWYG"}
{options {{Yes t} {No f}}}
{value $use_wysiwyg_p}
}
{return_url:text(hidden) {value $return_url}}
{submit:text(submit) {label "Change"}}
} -on_submit {
parameter::set_value -parameter "UseWysiwygP" -value $enabled_p
if {$return_url ne ""} {
ns_returnredirect $return_url
}
}
In the corresponding ADP file write
<master> <property name="title">@title@</property> <property name="context">@context@</property> <formtemplate id="categories_mode"></formtemplate>
And finally reference this page from your admin page
#TCL:
set return_url [ad_conn url]
#ADP:
<a href=configure?<%=[export_vars -url {return_url}]%>>Configure</a>