[Erw-devel] New features planned for ERW

[Sebastiano Vigna]

This is the first message on the erw-devel list. It describes the
current state of ERW's new features.

In generals, experimental tarballs of ERW are made available on demand.
Sooner or later I'll set up some public CVS access.

The new important features of this release are regex support for content
validation, and form customisation.

I'm going to describe in this message the current status of form
customisation. Since it is still in flux, it is soon for writing actual
documentation. The regex stuff is already documented.

The basic idea is that you express the form in erf, an XML-based
language that is essentially a simplified XHTML + elements INPUT and
LIST that allow to position input controls and list (everything could be
called INPUT--it's just for clarity). An example:

<?xml version="1.0"?>
<!DOCTYPE erf PUBLIC "-//DSI//DTD ERF V1.0//EN" "file://erf.dtd">
<erf>
<fieldset><legend>Basic data</legend>
<input ref="fname" size="20"/>
<input ref="lname" size="30"/>
</fieldset>

</erf>

I think you got the idea (for a more precise description, have a look at
erf.dtd). You put your fully customised form in files (named, say,
<type>.erf). When you call ERtool with the syntax

ertool --forms form1 form2 ...

you get corresponding files .php. The files contain a pre-cooked version
of whatever should be printed for the form. Note that missing attributes
will be added as hidden fields, and that you can (finally!) have
readonly items.

When the run-time environment loads a form for type T, it checks whether
in the directory $_ERW_formsDir there is a form for type T. It tries
T.<locale>.php, then T.<lang>.php, and then T.php.

You can, however, provide your *own* form chooser using the formLoad
hook ($D[<type>]["formLoad"]). It can do whatever it wants (checking the
user, etc.) and must return the name (without ".php"!) of a form in
$formsDir. The name will be used instead of the type name in the
matching process above.

Presently there is no way to customise embedded forms. I must find out a
reasonable way to do this (probably a "form" attribute of the "list"
element would be reasonable).

Note that there is presently NO CONTROL that the form is reasonable,
e.g., that it contains all mandatory attributes.

I wish to work out this form customisation stuff starting from a very
small, clearly fundamental subset and extend gradually, rather than
overfeaturising. For instance, it will be probably useful to be able to
specify style attributes on all items.

Ciao,

                                seba