The documentation is not currently up-to-date, since the widget has been changed into a plugin for HtmlArea.
The php-api has changed a bit, but theese changes are mainly renaming of functions etc.
For now - have a look at the examples to get you going.
Indite is a widget (aka control) for use in web-applications. It's main implementation is a mix of html and javascript.
The clientside widget is supported by a wrapper class written in php, that makes using the widget a lot smoother from within php.
Altho' there only exists a wrapper for php, the main widget could easily bee used in conjunction with other serverside languages.
Essentially indite is one among a lot of similar widgets available on the web. It can be used as a replacement for the old <textarea> html tag.
What makes indite stand out from the already existing (and very fine i must add) competitors is it's ability to perform realtime validation of the content.
Roughly speaking the use of wysiwyg-widgets targets two very different types of end-users.
The first type of user is knowledgeable in html, and could most likely hardcode the content, but having a wysiwyg preview assist her in doing so.
The second type is ignorant to technically complicated tasks as html or other programming languages. She knows how to operate a word-processor.
I develop web-applications as a living, and 99% of my customers fit the second type descibed.
The traditional wysiwyg-editors (htmlarea for example) are very feature-rich, and generally quite impressive.
However they all fail at the same point.
The content produced from the widget is to be used in a context, and heavy formatting may break this design.
This well known problem happens because the users are given too many options to choose from, and since she has no knowledge about the inner workings of html, she doesn't understand the problems this implies.
The solution is ofcause to limit the users - and this is precisely what indite does.
So whats the fuzz about this realtime validation anyway ? Glad you asked.
As a developer you want your users to provide content that you can display on your end-medium - Often this would be a website.
When you're dealing with simple widgets like <input> or <textarea> the users are limited to produce semantic content - they have no control over the presentation of the final product.
This is good because it enables you as a programmer to apply theese presentational properties through stylesheets or templates.
Introducing a rich-content widget changes this. Since the widget produces some sort of html, the user also gets control over presentational formatting like <font> and <b> tags.
Putting theese into the hands of your users is troublesome since it breaks the fundamental idea of a content-management system- to keep presentation and content apart.
The answer to this is realtime validation. Indite constantly checks the structure of the document against a strict ruleset. This restricts the user from applying presentational formatting, and from structuring the document wrong. It even transforms the wrong formatted html into legal html. You may see for your self by copy+pasting from MS word into the widget - an operation that would break any other wysiwyg widget.
Indite is crossbrowser. It works on ie 5.5+ and newer versions of mozilla. This covers most of the webs users today.
Indite outputs semantically clean markup. This is a leap forward in that you can now actually provide content for a strict xhtml page, without breaking the validity.
Indite gives the user a semantic aproach to editing text. Logical blocks such as paragraph and header are highlited with colored rulers to emphasize their semantics.
Indite validates as the user types. This approach is much friendlier to the user, than filtering the posted content serverside thorugh htmltidy or similar, since the user can see the actual end-result, while working.
On the clientside, Indite works on internet explorer for windows version 5.5 an up. It may work in ie 5.0, but haven't been tested. It works in newer versions of mozilla.
The serverside wrapper obviously needs php. It works with v. 4.1.0 and up. (hasn't been tested with php5 yet)
The clientside code is relatively performance-heavy. Therefore older machines may run slow, but it will work.
Indite is copyright of Troels Knak-Nielsen 2004. You may use the application freely under the terms of GNU Lesser General Public License (LGPL).
HtmlArea is copyright 2002-2004, interactivetools.com, inc., 2003-2004 dynarch.com. It is available under the open source htmlArea License (based on BSD license)
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; version 2.1 of the License.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Below is shown a "old" type form, that use a <textarea> tag for input (1.a). Next comes the same piece of code, but with the <textarea> replaced by indite (1.b).
<html>
<head>
</head>
<body>
<form method="post">
<textarea name="content"></textarea>
<input type="submit" />
</form>
</body>
</html>
<?php
require_once('htmlarea.class.php');
$i =& new HTMLArea('content');
$i->addPlugin('Indite');
$i->config = 'indite';
?>
<html>
<head>
<?php
echo HTMLArea::getStatic();
?>
</head>
<body>
<form method="post">
<?php
echo $i->get();
?>
<input type="submit" />
</form>
</body>
</html>
As you can see we have added three different php-sections to conjure up indite editor.
Let's look at them step by step.
require_once('htmlarea.class.php');
This line includes the php-code needed to interface with indite. If you have used php before, this is probably not new to you.
$i =& new HTMLArea('content');
The second line instanciates a HtmlArea object. This should also be something you have seen before. Note that you should instanciate one object for each widget you want on your page (provided you want more than one).
As you can see, we pass the name of the widget as an argument to the constructor. For further documentation of parameters etc., you may consult the wrapper api documentation.
$i->addPlugin('Indite');
Since we want to utilize indite, we load the plugin here. You may want to load additional plugins too. Be aware though, that some plugins don't cooperate well with Indite. Theese may include TableOperations and CSS.
$i->config = 'indite';
Using the Indite plugin renders some of the default options of htmlarea useless, and therefore we load up a custom toolbar.
echo HTMLArea::getStatic();
Whereas the first segment of php-code is placed in the top of the document, the next line must be placed in between the <head> tags of the page. The reason for this is that htmlarea need to print out some javascript initiation-code. In fact it's not mandatory to put this in the <head> section, but it's recommended. As a minimum you should print out before the first widget is displayed. You don't need to actually do this, since the wrapper will automagically do it for you, in case you forgot. However this means that the init code end up outside the <head>.
Another equally important thing to note about getStatic is that after calling this, you can't instanciate any more htmlarea-objects. Therefore you must create all needed objects before outputting them.
echo $i->get();
The last segment is placed at the location where the <textarea> tag used to be. It shouldn't need much explanation.